通過 Azure SQL 實現(xiàn)蓬勃發(fā)展
非常感謝來自Microsoft Dynamics 團隊的同事 Mahesh Sreenivas蹄梢、Pranab Mazumdar搔啊、Karthick Pakirisamy Krishnamurthy、Mayank
Mehta 和 Shovan Kar 為本文所做的貢獻巨缘。
概述
Dynamics 365 是一組智能的SaaS 業(yè)務應用程序尿赚，可幫助來自各個行業(yè)的各種規(guī)模的公司運行其整個業(yè)務买决，并通過預測性的、由 AI 驅動的見解來提供更好的結果吼畏。Dynamics 365應用程序構建于 Microsoft Power Platform 之上督赤，該平臺提供了可擴展的基礎，不僅可以運行 Dynamics應用程序本身泻蚊，還可以讓客戶躲舌、系統(tǒng)集成商和 ISV 創(chuàng)建針對特定行業(yè)的自定義內容，并將其業(yè)務流程連接到利用無代碼/低代碼方法的數(shù)百個現(xiàn)有連接器的其他解決方案和系統(tǒng)性雄。
Microsoft PowerPlatform（還提供 Power Apps没卸、Power Automate羹奉、Power Virtual Agents 和 PowerBI 等服務）建立在Azure SQL 數(shù)據(jù)庫等 Microsoft Azure 服務基礎上，這些服務提供可擴展且可靠的底層計算约计、數(shù)據(jù)诀拭、管理和安全服務，為上圖中表示的整個堆棧提供支持煤蚌。
歷史背景
Microsoft Dynamics 365的根是一套打包的業(yè)務解決方案耕挨，例如 Dynamics AX、NAV 和 CRM尉桩，它們在全球各地的客戶數(shù)據(jù)中心的多個 Windows Server 和 SQL Server 版本上運行筒占。
當軟件即服務范例開始在商業(yè)應用程序行業(yè)中占主導地位時，Dynamics CRM 使得該產(chǎn)品包成為 Microsoft 最早的在線服務之一蜘犁。在向 SaaS 方式轉變的初期翰苫，Dynamics 服務在 Microsoft 本地數(shù)據(jù)中心中的裸機服務器上運行。隨著每天數(shù)百萬計的活動用戶所帶來的使用增長这橙，部署和運行所有這些服務器奏窑、管理容量需求以及及時響應不斷增長的客戶數(shù)據(jù)量（對于最大規(guī)模的租戶而言，數(shù)據(jù)庫大小分布從100 MB 增加到超過 4 TB）所帶來的工作量最終將變得難以管理屈扎。
Dynamics 是最早采用Microsoft SQL Server 2012 AlwaysOn來實現(xiàn)業(yè)務連續(xù)性平臺之一埃唯，它還通過創(chuàng)建額外副本以重新平衡利用率的方式提供了一種靈活的方法來將客戶數(shù)據(jù)庫移動到新的群集。
大規(guī)模管理如此眾多的數(shù)據(jù)庫顯然是一項復雜的任務助隧，它涉及從初始資源配置到監(jiān)控筑凫、修補和運行這一龐大的系統(tǒng)的整個數(shù)據(jù)庫生命周期滑沧，同時還要保證可用性并村。團隊還學會了如何處理不在故障轉移-就緒狀態(tài)的仲裁丟失和副本等問題。從性能的角度來看滓技，在共享基礎節(jié)點上運行的數(shù)據(jù)庫實例使得我們很難隔離性能問題哩牍，并且除了將單個實例移至新節(jié)點之外，它提供的擴展或適應突發(fā)工作負載的選項也很有限令漂。
由于最終客戶可以在其環(huán)境中運行（高度定制的）應用程序的多個版本膝昆，導致產(chǎn)生明顯不同的工作負載，因此叠必，聽到通用數(shù)據(jù)服務團隊的合作伙伴組工程經(jīng)理Mahesh Sreenivas 說在傳統(tǒng)平臺上管理和維護所有這些組件“對工程師和最終客戶都非常痛苦”也就不足為奇了荚孵。
轉向 Azure 和 Azure SQL數(shù)據(jù)庫
Dynamics 365團隊決定將其平臺遷移到 MicrosoftAzure，以解決這些管理和運營難題纬朝，同時滿足客戶需求并確保平臺基礎性能（如可用性和可靠性）收叶，并讓工程團隊專注于添加創(chuàng)新功能。
從最初的設計到生產(chǎn)的工程工作花好幾年的時間共苛，其中包括將客戶遷移到新的基于Azure 的平臺判没，從在本地運行的整體代碼庫遷移到在 Azure 上運行的世界一流的行星級大規(guī)模服務蜓萄。
Azure SQL 數(shù)據(jù)庫中的常用數(shù)據(jù)服務
第一個關鍵決定是從一組異構應用程序（每個應用程序都有自己的歷史和技術特點）轉移到一個通用的基礎平臺，在該平臺上澄峰，Dynamics應用程序成為常規(guī)應用程序嫉沽，就像其他 ISV 公司可以構建和運行的應用程序一樣：因此引入了 Microsoft Power Platform及其公共數(shù)據(jù)服務層。本質上俏竞，基于基礎 Azure 功能（如計算绸硕、存儲、網(wǎng)絡和 Azure SQL 數(shù)據(jù)庫等其他專門服務）構建的新的無代碼或低代碼平臺是一種從基礎平臺提取Dynamics 應用程序的方法胞此，讓 Dynamics 開發(fā)人員可以專注于向平臺轉移而無需管理數(shù)據(jù)庫實例等單個資源臣咖。
現(xiàn)在，該平臺還托管著PowerApps漱牵、Power Automate夺蛇、Power Virtual Agents 或 PowerBI 等其他服務，其他公司可以基于該平臺構建自己的SaaS 應用程序酣胀，從無代碼的簡單解決方案到全代碼專用 ISV 應用程序都可以刁赦，且無需擔心如何管理計算和各種存儲設施等基礎資源。
通過將一個大約可管理 100萬個數(shù)據(jù)庫實例的平臺遷移到 Azure（截至 2020 年 7 月）闻镶，Dynamics 團隊學習了很多有關基礎服務工作原理的知識甚脉，還互惠互利地向其他Microsoft 團隊提供了大量反饋，以使其服務更好铆农。
從架構的角度來看牺氨，通用數(shù)據(jù)服務以邏輯戳（或規(guī)模組）進行組織，邏輯戳具有計算和數(shù)據(jù)兩層墩剖，其中關系數(shù)據(jù)存儲基于?Azure SQL 數(shù)據(jù)庫構建猴凹，因為團隊以前對 SQL Server 2012 和 2016 很熟悉。它提供了具有 3（或更多）個 9 的 SLA 的經(jīng)過預先配置的現(xiàn)成高可用性岭皂，具體取決于選擇的服務層郊霎。業(yè)務連續(xù)性也通過 Geo-restore、ActiveGeo-replication 和 Auto Failover Groups 等功能得到了保證爷绘。
與在共享的單個 SQL Server實例本地運行多個數(shù)據(jù)庫相比书劝，Azure SQL數(shù)據(jù)庫通過減少表、索引或備份級別的數(shù)據(jù)庫損壞事件而為團隊提供了很大的幫助土至。同樣购对，在物理計算機上的固件、操作系統(tǒng)和 SQL Server上打補丁所需的若干工時已減少到僅需管理應用程序層及其數(shù)據(jù)陶因。
Azure SQL 數(shù)據(jù)庫彈性池
登錄 Azure SQL數(shù)據(jù)庫后骡苞，第二個關鍵決策是采用彈性池來托管其數(shù)據(jù)庫。Azure SQL 數(shù)據(jù)庫彈性池是一款簡單且經(jīng)濟高效的解決方案，可以管理和擴展多個具有不斷變化且無法預測的使用需求的數(shù)據(jù)庫烙如。彈性池中的數(shù)據(jù)庫位于單個邏輯服務器上么抗，并以固定價格共享給定數(shù)量的資源。SaaS應用程序開發(fā)人員可以在擬定的資源預算內優(yōu)化數(shù)百個數(shù)據(jù)庫的性價比亚铁，同時為每個數(shù)據(jù)庫提供性能彈性并通過為每個租戶設置最小-最大利用率閾值來控制多租戶蝇刀。同時，它們通過為每個數(shù)據(jù)庫提供單獨的訪問控制策略來加強安全性和隔離徘溢⊥趟觯“通過遷移到Azure SQL 數(shù)據(jù)庫彈性池，我們的團隊不需要在管理復制這方面進行過多投資然爆，因為它由 Azure SQL 數(shù)據(jù)庫服務負責處理”站粟，Mahesh 解釋說。
Microsoft PowerPlatform 為使用其產(chǎn)品組合中給定服務的每個租戶使用一個單獨的帳戶曾雕。
“Spartan”資源管理層
考慮到廣泛的客戶行業(yè)奴烙、規(guī)模和（定制的）工作負載，關鍵要求之一是能夠在一組彈性池中高效地分配和管理這些數(shù)據(jù)庫剖张，從而最大程度地利用和管理資源切诀。要實現(xiàn)此目的，必須滿足以下三點：
1. 規(guī)模和容量規(guī)劃方面的靈活性
2. 為單個租戶擴展資源的敏捷性
3. 優(yōu)化的性價比
在 Azure SQL數(shù)據(jù)庫平臺為全面管理這些方面提供了基礎（例如搔弄，在線服務層擴展幅虑、在池之間移動數(shù)據(jù)庫的能力、從單個數(shù)據(jù)庫移至池的能力或反之顾犹、多種性價比選擇等）的同時倒庵，Dynamics團隊還創(chuàng)建了一個專用管理層，以根據(jù)應用程序定義的條件和策略自動執(zhí)行這些操作炫刷∏姹Γ“Spartan”就是這個管理層，其設計目的就是為了最大程度地減少手動操作柬唯。它具有可擴展的微服務平臺（以ARM 資源提供程序方式實現(xiàn)）认臊，后者負責其數(shù)據(jù)庫的整哥生命周期圃庭。
Spartan 是一個 API層锄奢，不僅負責數(shù)據(jù)庫 CRUD操作（創(chuàng)建、讀取剧腻、更新和刪除）拘央，還負責所有其他操作，例如在彈性池之間移動數(shù)據(jù)庫以最大程度地利用資源书在，在池和邏輯服務器之間實現(xiàn)客戶工作負載的平衡灰伟，管理備份保留以及將數(shù)據(jù)庫還原到先前的時間點。平臺還自動管理分配給數(shù)據(jù)庫和池的底層存儲，以避免效率低下并最大化密度栏账。在生產(chǎn)中收縮數(shù)據(jù)庫這樣的操作似乎很少見帖族，但對于需要操作超過100 萬個數(shù)據(jù)庫并優(yōu)化成本的平臺而言，卻是一項很常見的任務挡爵。
彈性池按“層”進行組織竖般，其中每個層根據(jù)所使用的基礎服務層（通用、關鍵業(yè)務）和分配的計算大小提供不同的配置茶鹃，以便最終客戶數(shù)據(jù)庫始終以最佳性價比運行涣雕。除防火墻設置等其他詳細信息外，每個層還控制關聯(lián)數(shù)據(jù)庫的最小-最大設置闭翩，并定義每個池的最佳數(shù)據(jù)庫密度挣郭。
上圖將彈性池這種邏輯組織表示為多個層，并顯示了Dynamics 團隊用來在粒度資源分配和成本優(yōu)化之間找到最佳折衷的 DTU 和 vCore 購買模型的組合疗韵。
對于非常大的客戶兑障，該平臺還可以將這些數(shù)據(jù)庫從共享池移到專用的Azure SQL 單一數(shù)據(jù)庫中，并能夠擴展到最大的計算大薪锻簟（例如旺垒，具有 128 個 vCore 實例的 M 系列）。
如果您認為 Dynamics 團隊有兩名專門的工程師來管理整個平臺肤无，而這兩名工程師專注于操作和改進Spartan 平臺先蒋，而不是管理單個的數(shù)據(jù)庫，那么該平臺的效率水平是令人難以置信的宛渐。
Dynamics 365 與 AzureSQL 數(shù)據(jù)庫相結合竞漾，功能更加強大！
如前所述窥翩，在此過程中业岁，來自 Dynamics和 Azure 團隊的工程師們共同努力改進了底層平臺。Dynamics 團隊大力倡導一些平臺范圍的改進（例如加速網(wǎng)絡）以顯著減少計算節(jié)點與其他 Azure服務之間的網(wǎng)絡延遲寇蚊，該團隊以數(shù)據(jù)為中心的數(shù)據(jù)密集型應用程序從這些改進中受益匪淺笔时。
在 Azure SQL數(shù)據(jù)庫中，Dynamics 團隊影響了 vCore 模型的引入仗岸，從而找到了計算內核與數(shù)據(jù)庫存儲之間的正確比例允耿，現(xiàn)在它們可以獨立擴展并優(yōu)化成本和性能。
為了更充分地利用 Common Data Service 中的關系數(shù)據(jù)庫資源扒怖，該團隊實施了讀取擴展较锡，該服務通過通過分擔主要讀寫數(shù)據(jù)庫副本上的部分工作負載來幫助提高性能。像大多數(shù)以數(shù)據(jù)為中心的服務一樣盗痒，CommonData Service 中的工作負載是讀取密集型的 — 這意味著它獲得的讀取比寫入要多很多蚂蕴。借助讀取擴展，如果對 Common Data Service的調用會導致選擇與更新，我們可以將該請求路由到只讀副本骡楼，并擴展讀取工作量熔号。
在考慮各種各樣的客戶工作負載和規(guī)模方面，Dynamics365 應用程序一直是一個出色的陪練伙伴鸟整，它通過自動計劃校正跨嘉、自動索引管理和智能查詢處理功能集來調整和改進自動調整等功能。
想象一下吃嘿，在一百萬個數(shù)據(jù)庫中出現(xiàn)查詢超時情況：是因為缺少正確的索引策略嗎祠乃？是查詢計劃回歸？還是其他原因兑燥？
為了在故障排除和維護事件期間幫助Dynamics 工程師和支持組織亮瓷，我們開發(fā)了另一個名為數(shù)據(jù)管理服務（DAMS）的微服務來計劃和執(zhí)行維護任務和工作，例如創(chuàng)建或重建索引以動態(tài)優(yōu)化客戶工作負載的變化降瞳。這些任務可以涵蓋性能改進嘱支、事務管理、診斷數(shù)據(jù)收集和查詢計劃管理等領域挣饥。
在 Microsoft Research(MSR) 的幫助下除师，Dynamics 團隊已將 SQL Server 的 Database Tuning Advisor (DTA) 移植到 AzureSQL，并將其集成到了微服務中扔枫。DTA 是一個用于評估查詢并生成索引和統(tǒng)計建議以調整最關鍵數(shù)據(jù)庫工作負載的查詢性能的平臺汛聚。
與 Azure SQL數(shù)據(jù)庫中的任何其他客戶數(shù)據(jù)庫一樣，Dynamics 365 數(shù)據(jù)庫也具有默認處于啟用狀態(tài)的查詢存儲等功能短荐。此功能提供有關查詢計劃選擇和性能的見解倚舀，并通過幫助它們快速發(fā)現(xiàn)由查詢計劃更改引起的性能差異來簡化性能故障排除。
除了這些功能忍宋，Dynamics團隊還創(chuàng)建了一個與最終用戶共享的優(yōu)化工具痕貌，以驗證他們的自定義設置是否正確實施，檢測諸如以可視化形式放置多少數(shù)據(jù)控件之類的內容糠排，并提供符合其最佳做法的建議舵稠。
他們還主動監(jiān)視客戶的工作負載，以了解關鍵的用例并檢測客戶可能引入的新模式入宦，并確保平臺可以有效地運行這些新模式哺徊。
Dynamics 團隊與 Azure SQL數(shù)據(jù)庫工程師并肩工作，幫助改進了數(shù)據(jù)庫引擎的許多方面云石。其中有一個與超大型查詢計劃緩存（超過 10 萬個計劃）相關的示例唉工，這是復雜 OLTP工作負載的常見問題研乒，其中計劃重新編譯中的自旋鎖爭用導致較高的 CPU 利用率和很低的效率汹忠。此問題的解決為在同一平臺上運行的數(shù)以千計的其他 Azure SQL數(shù)據(jù)庫客戶提供了很大的幫助。
他們幫助改進的其他領域還包括恒定時間恢復，使得數(shù)百萬個數(shù)據(jù)庫的故障轉移過程的效率大大提高宽菜，以及設定管理鎖定優(yōu)先級以減少自動索引創(chuàng)建期間的阻塞谣膳。
除了 Azure SQL數(shù)據(jù)庫提供的現(xiàn)成功能外，Dynamics 團隊還開發(fā)了針對客戶不斷升級的性能問題的特定故障排除工作流铅乡。例如继谚，Dynamics支持工程師可以在有問題的客戶工作負載上運行 Database Tuning Advisor，并了解可以用于減輕客戶問題的特定建議阵幸。
展望未來
就某些最大型的最終客戶的規(guī)模而言花履，Dynamics 365 是將 Azure SQL 數(shù)據(jù)庫最大實例大小從 1TB 增加到 4TB 的主要影響因素之一。也就是說挚赊，即使現(xiàn)在的 4TB容量在擴展能力方面也是一個限制因素诡壁，因此 Dynamics 團隊正在將 Azure SQL Database Hyperscale作為其服務的下一代關系存儲。團隊正在研究的最關鍵特性是：幾乎無限制的數(shù)據(jù)庫大小荠割，結合計算和存儲大小之間的分隔以及利用只讀副本來擴展客戶工作負載的能力妹卿。
Dynamics 團隊與 Azure SQL團隊并肩合作，在前面提到的所有具有挑戰(zhàn)性的方案上測試和驗證 Azure SQL DatabaseHyperscale蔑鹦，這種協(xié)作不僅將分別在兩個團隊中繼續(xù)取得成功夺克，而且對在平臺上運行的所有其他客戶也將繼續(xù)取得成功。
