Office许可服务和Azure Cosmos DB第1部分：迁移生产工

小提示：您能找到这篇{Office许可服务和Azure Cosmos DB第1部分：迁移生产工}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Office许可服务和Azure Cosmos DB第1部分：迁移生产工内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">挑战：有限的吞吐量

< font-size: 16px;">在Microsoft，Office许可服务（OLS）支持在全球数百万个设备（包括Windows，Mac，平板电脑和移动设备）上激活Microsoft Office客户端。它存储诸如机器ID，产品ID，激活计数，到期日期等信息。Office客户端每天被全球用户访问OLS的次数超过2.4亿次，其中第一个呼叫是在激活许可证后从客户端发出的，然后每2-3天从客户端进行一次检查，以确保客户端检查许可证仍然有效。

< font-size: 16px;">直到最近，OLS的后端数据存储都依赖于Azure Table存储，该存储包含分布在18个表中的约5 TB数据，其中单独的表用于不同的许可证类别，例如消费者，企业和OEM预安装。

< font-size: 16px;">在经历了数年持续的工作负载增长之后，2018年初，OLS服务开始接近需要比表存储所提供的吞吐量更多的点。如果不解决该问题，表存储的固有吞吐量限制将开始威胁到整体服务质量，从而损害全球数百万用户。

< font-size: 16px;">Microsoft的软件工程师Danny电商运营是干嘛的 Cheng领导OLS开发团队，他解释说：

< font-size: 16px;">“每个表存储帐户都具有固定的最大吞吐量，并且不会超出该范围。到2018年，OLS的可用存储吞吐量已不足，并且由于我们已经将每个表维护在其自己的表存储帐户中，因此我们无法获得更多的吞吐量来满足客户的更多请求。OLS服务在高峰使用时间受到限制，因此我们必须尽快找到更具扩展性的存储后端。

< font-size: 16px;">在寻找长期的存储解决方案时，OLS团队不仅需要额外的吞吐量。我们希望能够在全球不同地区部署OLS，以通过将服务副本更靠近用户所在的位置来最大程度地减少延迟。但是使用表存储时，地理复制功能相当有限。”

< font-size: 16px;">OLS团队还希望更好的灾难恢复。使用表存储，他们将所有数据存储在美国的多个区域中。所有读取和写入都到达主区域，并且没有用于复制到两个备份区域的SLA，这可能需要60分钟。如果主要区域不可用，则需要人工干预，并且很可能会丢失数据。

< font-size: 16px;">“如果一个地区要宕机，那将是一个真正的恐慌情况，将有30到60分钟的停机时间以及类似的数据丢失窗口，”Cheng说。

< font-size: 16px;">解决方案：迁移到Azure Cosmos DB

< font-size: 16px;">OLS团队选择迁移到Azure Cosmos DB，后者提供了从表存储的一举一迁移的迁移路径，从而可以轻松交换具有交钥匙式全局分发，低延迟，几乎无限的可伸缩性，保证高价的高级后端服务。可用性等等。

< font-size: 16px;">“最初，当我们意识到我们需要一个新的存储后端时，这令人感到恐惧，因为我们不知道需要多少新代码。”Cheng说。“我们在Azure上研究了几种存储选项，Azure Cosmos DB是满足我们所有需求的唯一存储选项。借助其Table API，我们甚至不需要编写很多新代码。从许多方面来说，这都是理想的升降选择，只需很少的工作即可提供我们所需的可伸缩性和许多其他好处。”

< font-size: 16px;">设计决策

< font-size: 16px;">在准备部署Azure Cosmos DB时，OLS团队必须做出一些基本的设计决策：

< font-size: 16px;">一致性级别，为团队提供了解决读取一致性与延迟，可用性和吞吐量之间的基本权衡的选项。

< font-size: 16px;">“我们之所以选择强一致性，是因为我们的某些业务逻辑需要在写入存储后立即从存储中读取信息，”Cheng解释说。

< font-size: 16px;">分区键，它指示Azure Cosmos DB容器中的项目如何划分为逻辑分区-并确定数据存储的最终可伸缩性。

< font-size: 16px;">“使用Azure Cosmos DB Table API，分区键自然可以映射到我们在Table存储中的映射，因此我们能够重用相同的分区键，”Cheng说。

< font-size: 16px;">迁移过程

< font-size: 16px;">尽管Azure Cosmos DB提供了数据迁移工具，但那时使用它会导致OLS服务停机，这不是一个选择。（注意：今天，您可以在不停机的情况下进行实时迁移。）为了解决这个问题，OLS团队构建了一个数据迁移解决方案，该解决方案包含三个组件：

< font-size: 16px;">将当前数据从表存储移动到Azure Cosmos DB的数据迁移器。

< font-size: 16px;">一个Dual Writer，它将新的数据库更改写入表存储和Azure Cosmos DB。

< font-size: 16px;">一致性检查器，用于捕获表存储和Azure Cosmos DB之间的任何不匹配情况。

< font-size: 16px;">数据迁移器组件基于Azure Cosmos DB团队提供给Microsoft客户的组件。

< font-size: 16px;">“为了解决停机问题，我们添加了Dual Writer和Consistency Checker组件，它们与OLS服务本身在同一台生产服务器上运行，推广软文写作”Cheng解释说。

< font-size: 16px;">OLS团队于2019年末完成了迁移过程。如今，Azure Cosmos DB已部署到与表存储相同的三个区域，该团队在迁移过程中尽可能地模仿了表存储拓扑。同样，美国中北部是主要（读/写）区域，而其他两个区域当前是只读的。Azure Cosmos DB环境具有18个表，这些表包含5 TB数据，每秒消耗约100万个请求单位（RU/s），这是用于在Azure Cosmos DB中保留保证的数据库吞吐量的单位。

< font-size: 16px;">既然迁移已经完成，该团队计划启用多主机功能，该功能将对所有区域（而不是主要区域）进行写操作。为此，该团队还计划通过将其后端存储复制到全球其他区域来进行全球扩展，以此作为从Office客户端角度通过将OLS数据副本更靠近其用户所在位置来改善延迟的一种方法。