这篇文章是由两部分组成的系列文章的第1部分，讲述组织如何使用azurecosmosdb来满足现实世界的需求，以及它给他们带来的不同。在第1部分中，我们将探讨导致microsoftofficelicensingservice团队从azuretablestorage迁移到azurecosmosdb的挑战，以及它是如何将生产工作负载迁移到新服务上的。在第2部分中，我们将研究团队努力的结果。挑战：有限的吞吐量和其他能力在微软，Office授权服务（OLS）支持在全球数百万台设备上激活Microsoft Office客户端，包括Windows、Mac、平板电脑和移动设备。它存储诸如机器ID、产品ID、激活计数、过期日期等信息。世界各地的用户每天通过Office客户端访问OLS的次数超过2.4亿次，激活许可证后，第一次呼叫来自客户端，此后每隔2-3天，客户端会检查以确保许可证仍然有效。直到最近，OLS的后端数据存储都依赖于Azure表存储，其中包含了大约5tb的数据，分布在18个表中，这些表分别用于不同的许可类别，如消费者、企业和OEM预安装。2018年初，经过多年的工作负载持续增长，OLS服务开始接近它需要的吞吐量超过表存储所能提供的吞吐量。如果不解决这个问题，表存储固有的吞吐量限制将开始威胁整体服务质量，从而损害全球数百万用户的利益。微软软件工程师Danny Cheng领导OLS开发团队，他解释道："每个表存储帐户都有一个固定的最大吞吐量，并且不会超过这个值。到2018年，OLS的可用存储吞吐量很低，而且，鉴于我们已经在其自己的表存储帐户中维护每个表，我们无法获得更多的吞吐量来满足客户的更多请求。我们在OLS服务的使用高峰时段受到限制，因此我们必须尽快找到一个更具可扩展性的存储后端。在寻找长期解决方案来满足其存储需求时，OLS团队需要的不仅仅是额外的吞吐量。我们希望能够在世界各地的不同地区部署OLS，作为一种将服务副本放在离用户更近的地方来最小化延迟的方法。但使用表存储，地域复制功能相当有限。"OLS团队还希望得到更好的灾难恢复。有了表存储，他们将所有数据存储在美国多个地区。所有的读写操作都转到了主区域，而且没有为复制到两个备份区域制定SLA，这可能需要60分钟。如果主区域不可用，则需要人为干预，数据可能会丢失。"如果一个地区出现故障，那将是一个真正的恐慌局面，有30到60分钟的停机时间和类似的数据丢失窗口，"Cheng说。解决方案：迁移到azurecosmos数据库OLS团队选择了迁移到azurecosmos数据库，它提供了一个从表存储迁移到另一个迁移路径，这使得在一个高级后端服务中交换变得非常容易，这种服务具有全包式全局分发、低延迟、几乎无限的可扩展性、有保证的高可用性等等。"一开始，当我们意识到我们需要一个新的存储后端时，我们不知道需要多少新代码，这让人感到害怕，"Cheng说我们研究了Azure上的几个存储选项，azurecosmosdb是唯一满足我们所有需求的存储选项。使用它的表API，我们甚至不需要编写太多新代码。在许多方面，这是一个理想的提升和转换，它提供了我们所需的可扩展性和许多其他好处，只需很少的工作。"设计决策在准备部署Azure Cosmos DB时，OLS团队必须做出一些基本的设计决策：一致性级别，为团队提供了解决读一致性与延迟、可用性和吞吐量之间的基本权衡的选项。"我们选择了强一致性，因为我们的一些业务逻辑要求在写入存储后立即从存储器中读取数据，"Cheng解释道。分区键，它指示azurecosmosdb容器中的项如何划分为逻辑分区，并决定数据存储的最终可伸缩性。"有了azurecosmosdb Table API，分区键自然映射到表存储中的内容，因此我们能够重用相同的分区键，"Cheng说。迁移过程虽然azurecosmosdb提供了一个数据迁移工具，但它在当时的使用会导致OLS服务的一些停机时间，这不是一个选择。（注意：今天您可以在不停机的情况下进行实时迁移。）为了解决这个问题，OLS团队构建了一个数据迁移解决方案，它由三个组件组成：将当前数据从表存储移动到azurecosmos数据库的数据迁移器。一个双写程序，它同时向表存储和azurecosmos数据库写入新的数据库更改。一个一致性检查程序，用于捕捉表存储和azurecosmos数据库之间的任何不匹配。datamigrator组件基于azurecosmosdb团队提供给微软客户的相同组件。"为了解决宕机问题，我们添加了双重Writer和一致性检查器组件，它们与OLS服务本身运行在同一个生产服务器上，"Cheng解释道。OLS团队在2019年末完成了迁移过程。今天，azurecosmosdb被部署到与表存储相同的三个区域，团队在迁移过程中尽可能地模拟表存储拓扑。同样，美国中北部是主要（读/写）地区，而其他两个地区目前是只读的。azurecosmosdb环境有18个表，其中包含5tb的数据，每秒消耗大约一百万个请求单位（RU/s），这些单位用于在azurecosmosdb中保留有保证的数据库吞吐量。现在迁移已经完成，团队计划启用多主功能，这将启用所有区域，而不仅仅是主区域。与此相关的是，该团队还计划在全球范围内进行扩展，将其后端存储复制到世界各地的其他地区，通过将OLS数据的副本放在离用户更近的位置，从而从Office客户端的角度改进延迟。在本系列的第2部分中，我们将研究团队在azurecosmosdb上构建新的Office许可服务的结果。立即开始使用Azure Cosmos DB访问Azure宇宙数据库。请参阅Azure Cosmos DB Table API简介。