通过 Azure SQL 实现蓬勃发展
非常感谢来自Microsoft Dynamics 团队的同事 Mahesh Sreenivas、Pranab Mazumdar、Karthick Pakirisamy Krishnamurthy、Mayank
Mehta 和 Shovan Kar 为本文所做的贡献。
概述
Dynamics 365 是一组智能的SaaS 业务应用程序，可帮助来自各个行业的各种规模的公司运行其整个业务，并通过预测性的、由 AI 驱动的见解来提供更好的结果。Dynamics 365应用程序构建于 Microsoft Power Platform 之上，该平台提供了可扩展的基础，不仅可以运行 Dynamics应用程序本身，还可以让客户、系统集成商和 ISV 创建针对特定行业的自定义内容，并将其业务流程连接到利用无代码/低代码方法的数百个现有连接器的其他解决方案和系统。
Microsoft PowerPlatform（还提供 Power Apps、Power Automate、Power Virtual Agents 和 PowerBI 等服务）建立在Azure SQL 数据库等 Microsoft Azure 服务基础上，这些服务提供可扩展且可靠的底层计算、数据、管理和安全服务，为上图中表示的整个堆栈提供支持。
历史背景
Microsoft Dynamics 365的根是一套打包的业务解决方案，例如 Dynamics AX、NAV 和 CRM，它们在全球各地的客户数据中心的多个 Windows Server 和 SQL Server 版本上运行。
当软件即服务范例开始在商业应用程序行业中占主导地位时，Dynamics CRM 使得该产品包成为 Microsoft 最早的在线服务之一。在向 SaaS 方式转变的初期，Dynamics 服务在 Microsoft 本地数据中心中的裸机服务器上运行。随着每天数百万计的活动用户所带来的使用增长，部署和运行所有这些服务器、管理容量需求以及及时响应不断增长的客户数据量（对于最大规模的租户而言，数据库大小分布从100 MB 增加到超过 4 TB）所带来的工作量最终将变得难以管理。
Dynamics 是最早采用Microsoft SQL Server 2012 AlwaysOn来实现业务连续性平台之一，它还通过创建额外副本以重新平衡利用率的方式提供了一种灵活的方法来将客户数据库移动到新的群集。
大规模管理如此众多的数据库显然是一项复杂的任务，它涉及从初始资源配置到监控、修补和运行这一庞大的系统的整个数据库生命周期，同时还要保证可用性。团队还学会了如何处理不在故障转移-就绪状态的仲裁丢失和副本等问题。从性能的角度来看，在共享基础节点上运行的数据库实例使得我们很难隔离性能问题，并且除了将单个实例移至新节点之外，它提供的扩展或适应突发工作负载的选项也很有限。
由于最终客户可以在其环境中运行（高度定制的）应用程序的多个版本，导致产生明显不同的工作负载，因此，听到通用数据服务团队的合作伙伴组工程经理Mahesh Sreenivas 说在传统平台上管理和维护所有这些组件“对工程师和最终客户都非常痛苦”也就不足为奇了。
转向 Azure 和 Azure SQL数据库
Dynamics 365团队决定将其平台迁移到 MicrosoftAzure，以解决这些管理和运营难题，同时满足客户需求并确保平台基础性能（如可用性和可靠性），并让工程团队专注于添加创新功能。
从最初的设计到生产的工程工作花好几年的时间，其中包括将客户迁移到新的基于Azure 的平台，从在本地运行的整体代码库迁移到在 Azure 上运行的世界一流的行星级大规模服务。
Azure SQL 数据库中的常用数据服务
第一个关键决定是从一组异构应用程序（每个应用程序都有自己的历史和技术特点）转移到一个通用的基础平台，在该平台上，Dynamics应用程序成为常规应用程序，就像其他 ISV 公司可以构建和运行的应用程序一样：因此引入了 Microsoft Power Platform及其公共数据服务层。本质上，基于基础 Azure 功能（如计算、存储、网络和 Azure SQL 数据库等其他专门服务）构建的新的无代码或低代码平台是一种从基础平台提取Dynamics 应用程序的方法，让 Dynamics 开发人员可以专注于向平台转移而无需管理数据库实例等单个资源。
现在，该平台还托管着PowerApps、Power Automate、Power Virtual Agents 或 PowerBI 等其他服务，其他公司可以基于该平台构建自己的SaaS 应用程序，从无代码的简单解决方案到全代码专用 ISV 应用程序都可以，且无需担心如何管理计算和各种存储设施等基础资源。
通过将一个大约可管理 100万个数据库实例的平台迁移到 Azure（截至 2020 年 7 月），Dynamics 团队学习了很多有关基础服务工作原理的知识，还互惠互利地向其他Microsoft 团队提供了大量反馈，以使其服务更好。
从架构的角度来看，通用数据服务以逻辑戳（或规模组）进行组织，逻辑戳具有计算和数据两层，其中关系数据存储基于 Azure SQL 数据库构建，因为团队以前对 SQL Server 2012 和 2016 很熟悉。它提供了具有 3（或更多）个 9 的 SLA 的经过预先配置的现成高可用性，具体取决于选择的服务层。业务连续性也通过 Geo-restore、ActiveGeo-replication 和 Auto Failover Groups 等功能得到了保证。
与在共享的单个 SQL Server实例本地运行多个数据库相比，Azure SQL数据库通过减少表、索引或备份级别的数据库损坏事件而为团队提供了很大的帮助。同样，在物理计算机上的固件、操作系统和 SQL Server上打补丁所需的若干工时已减少到仅需管理应用程序层及其数据。
Azure SQL 数据库弹性池
登录 Azure SQL数据库后，第二个关键决策是采用弹性池来托管其数据库。Azure SQL 数据库弹性池是一款简单且经济高效的解决方案，可以管理和扩展多个具有不断变化且无法预测的使用需求的数据库。弹性池中的数据库位于单个逻辑服务器上，并以固定价格共享给定数量的资源。SaaS应用程序开发人员可以在拟定的资源预算内优化数百个数据库的性价比，同时为每个数据库提供性能弹性并通过为每个租户设置最小-最大利用率阈值来控制多租户。同时，它们通过为每个数据库提供单独的访问控制策略来加强安全性和隔离。“通过迁移到Azure SQL 数据库弹性池，我们的团队不需要在管理复制这方面进行过多投资，因为它由 Azure SQL 数据库服务负责处理”，Mahesh 解释说。
Microsoft PowerPlatform 为使用其产品组合中给定服务的每个租户使用一个单独的帐户。
“Spartan”资源管理层
考虑到广泛的客户行业、规模和（定制的）工作负载，关键要求之一是能够在一组弹性池中高效地分配和管理这些数据库，从而最大程度地利用和管理资源。要实现此目的，必须满足以下三点：
1. 规模和容量规划方面的灵活性
2. 为单个租户扩展资源的敏捷性
3. 优化的性价比
在 Azure SQL数据库平台为全面管理这些方面提供了基础（例如，在线服务层扩展、在池之间移动数据库的能力、从单个数据库移至池的能力或反之、多种性价比选择等）的同时，Dynamics团队还创建了一个专用管理层，以根据应用程序定义的条件和策略自动执行这些操作。“Spartan”就是这个管理层，其设计目的就是为了最大程度地减少手动操作。它具有可扩展的微服务平台（以ARM 资源提供程序方式实现），后者负责其数据库的整哥生命周期。
Spartan 是一个 API层，不仅负责数据库 CRUD操作（创建、读取、更新和删除），还负责所有其他操作，例如在弹性池之间移动数据库以最大程度地利用资源，在池和逻辑服务器之间实现客户工作负载的平衡，管理备份保留以及将数据库还原到先前的时间点。平台还自动管理分配给数据库和池的底层存储，以避免效率低下并最大化密度。在生产中收缩数据库这样的操作似乎很少见，但对于需要操作超过100 万个数据库并优化成本的平台而言，却是一项很常见的任务。
弹性池按“层”进行组织，其中每个层根据所使用的基础服务层（通用、关键业务）和分配的计算大小提供不同的配置，以便最终客户数据库始终以最佳性价比运行。除防火墙设置等其他详细信息外，每个层还控制关联数据库的最小-最大设置，并定义每个池的最佳数据库密度。
上图将弹性池这种逻辑组织表示为多个层，并显示了Dynamics 团队用来在粒度资源分配和成本优化之间找到最佳折衷的 DTU 和 vCore 购买模型的组合。
对于非常大的客户，该平台还可以将这些数据库从共享池移到专用的Azure SQL 单一数据库中，并能够扩展到最大的计算大小（例如，具有 128 个 vCore 实例的 M 系列）。
如果您认为 Dynamics 团队有两名专门的工程师来管理整个平台，而这两名工程师专注于操作和改进Spartan 平台，而不是管理单个的数据库，那么该平台的效率水平是令人难以置信的。
Dynamics 365 与 AzureSQL 数据库相结合，功能更加强大！
如前所述，在此过程中，来自 Dynamics和 Azure 团队的工程师们共同努力改进了底层平台。Dynamics 团队大力倡导一些平台范围的改进（例如加速网络）以显著减少计算节点与其他 Azure服务之间的网络延迟，该团队以数据为中心的数据密集型应用程序从这些改进中受益匪浅。
在 Azure SQL数据库中，Dynamics 团队影响了 vCore 模型的引入，从而找到了计算内核与数据库存储之间的正确比例，现在它们可以独立扩展并优化成本和性能。
为了更充分地利用 Common Data Service 中的关系数据库资源，该团队实施了读取扩展，该服务通过通过分担主要读写数据库副本上的部分工作负载来帮助提高性能。像大多数以数据为中心的服务一样，CommonData Service 中的工作负载是读取密集型的 — 这意味着它获得的读取比写入要多很多。借助读取扩展，如果对 Common Data Service的调用会导致选择与更新，我们可以将该请求路由到只读副本，并扩展读取工作量。
在考虑各种各样的客户工作负载和规模方面，Dynamics365 应用程序一直是一个出色的陪练伙伴，它通过自动计划校正、自动索引管理和智能查询处理功能集来调整和改进自动调整等功能。
想象一下，在一百万个数据库中出现查询超时情况：是因为缺少正确的索引策略吗？是查询计划回归？还是其他原因？
为了在故障排除和维护事件期间帮助Dynamics 工程师和支持组织，我们开发了另一个名为数据管理服务（DAMS）的微服务来计划和执行维护任务和工作，例如创建或重建索引以动态优化客户工作负载的变化。这些任务可以涵盖性能改进、事务管理、诊断数据收集和查询计划管理等领域。
在 Microsoft Research(MSR) 的帮助下，Dynamics 团队已将 SQL Server 的 Database Tuning Advisor (DTA) 移植到 AzureSQL，并将其集成到了微服务中。DTA 是一个用于评估查询并生成索引和统计建议以调整最关键数据库工作负载的查询性能的平台。
与 Azure SQL数据库中的任何其他客户数据库一样，Dynamics 365 数据库也具有默认处于启用状态的查询存储等功能。此功能提供有关查询计划选择和性能的见解，并通过帮助它们快速发现由查询计划更改引起的性能差异来简化性能故障排除。
除了这些功能，Dynamics团队还创建了一个与最终用户共享的优化工具，以验证他们的自定义设置是否正确实施，检测诸如以可视化形式放置多少数据控件之类的内容，并提供符合其最佳做法的建议。
他们还主动监视客户的工作负载，以了解关键的用例并检测客户可能引入的新模式，并确保平台可以有效地运行这些新模式。
Dynamics 团队与 Azure SQL数据库工程师并肩工作，帮助改进了数据库引擎的许多方面。其中有一个与超大型查询计划缓存（超过 10 万个计划）相关的示例，这是复杂 OLTP工作负载的常见问题，其中计划重新编译中的自旋锁争用导致较高的 CPU 利用率和很低的效率。此问题的解决为在同一平台上运行的数以千计的其他 Azure SQL数据库客户提供了很大的帮助。
他们帮助改进的其他领域还包括恒定时间恢复，使得数百万个数据库的故障转移过程的效率大大提高，以及设定管理锁定优先级以减少自动索引创建期间的阻塞。
除了 Azure SQL数据库提供的现成功能外，Dynamics 团队还开发了针对客户不断升级的性能问题的特定故障排除工作流。例如，Dynamics支持工程师可以在有问题的客户工作负载上运行 Database Tuning Advisor，并了解可以用于减轻客户问题的特定建议。
展望未来
就某些最大型的最终客户的规模而言，Dynamics 365 是将 Azure SQL 数据库最大实例大小从 1TB 增加到 4TB 的主要影响因素之一。也就是说，即使现在的 4TB容量在扩展能力方面也是一个限制因素，因此 Dynamics 团队正在将 Azure SQL Database Hyperscale作为其服务的下一代关系存储。团队正在研究的最关键特性是：几乎无限制的数据库大小，结合计算和存储大小之间的分隔以及利用只读副本来扩展客户工作负载的能力。
Dynamics 团队与 Azure SQL团队并肩合作，在前面提到的所有具有挑战性的方案上测试和验证 Azure SQL DatabaseHyperscale，这种协作不仅将分别在两个团队中继续取得成功，而且对在平台上运行的所有其他客户也将继续取得成功。