內容來源：2017 年 08 月 24 日，微軟中國首席產品經理宋青見在“ODF 2017開源數據庫論壇（北京）”進行《雲原生的MySQL託管服務架構及讀寫分離的優化》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：4055 | 11分鐘閱讀
嘉賓演講視頻及PPT，請複製：http://t.cn/RDcDoMv，粘貼至瀏覽器即可。
摘要
在私有數據中心運維MySQL的方式是單機運行、一主一備，甚至是多主複製的集群，為了保證高可用，成本是比較高的。而基於雲計算，託管運維大量的用戶MySQL實例，如何用Cloud Native的原則，通過沙箱隔離、計算和數據的完全分離，實現低成本和高擴展的高可用方案？通過開篇分享，使大家更好的理解Cloud RDS的架構精髓。進而通過基於Azure storage的針對MySQL讀寫分離的優化，比較深入的分享了一種可以借鑑的主從分離優化技術。
雲原生的託管服務架構
雲原生的MySQL PaaS服務
我們的MySQL託管運維並非直接將數據存儲在本地SSD，而是所有的連接都需要經過一層代理（可以理解為無狀態的外部服務器），然後由代理將用戶的連接轉發到某一個虛擬機中的MySQL實例上。每個虛擬機上有一個Agent用來監控運行的MySQL服務狀態，如果其中某個數據庫出現問題，就會在其他的虛擬機上恢復該數據庫。這種情況下Proxy的好處就顯現出來了，因為用戶連接是在proxy上，所以當後方數據庫出現問題，proxy會將連接重新定位到已恢復的數據庫上。
另外我們將所有數據庫的讀寫操作都從本地移到了網絡上，真正做到了計算和存儲的分離。所有MySQL的數據文件不是保存在本地硬盤，而是存儲在分佈式的基於網絡的存儲框架上，數據在網絡上被保存多份，同時嚴格監控用戶的帶寬資源消耗。
從節點的管理上來看本地的數據中心如果有上千臺的節點就已經算是不小的網絡了，而公有云在全球有超過百萬的物理節點。面對如此多的節點運維的思路和架構會完全不同，我們在網絡和存儲方面實際上是花費了很大的精力才做到了不同租戶或用戶之間的隔離。
如果是單一線程的任務，本地存儲肯定是比網絡要快的，因為網絡有著延時，但實際上雲計算可以通過高併發來回避在延遲方面的不足。
MySQL PaaS的好處
MySQL PaaS帶來了更方便快速的部署，高性價比，高可用性，以及高安全性的全託管服務。缺點在於限制了用戶對數據庫操作的權力，因為我們是將多個用戶的數據放在一起運維，所以對整個環境的安全性要求比較高。
平臺支持
我們當前的架構下只是將MySQL作為一個進程，更多的重點是在MySQL任務監控、快速恢復上。由於架構中有代理、計算和分離，所以可以很容易的做到單點的高可用。這種情況下我們後臺用的DB Engine是MySQL社區版本，支持現有的MySQL客戶端和工具。
啟動備用庫
當前架構下計算和數據分離之後，數據是被存儲在Azure storage上，這時雖然單點就可以達到高可用，但是在數據文件較大的時候，由於網絡原因恢復起來需要一定的時間，經過監控發現基本上在3分鐘以內。如果用戶對時間有要求的話，一般是建議用戶再建一個讀寫分離的從庫，主庫出現問題的時候手動將從庫提升為主庫。不過我們提供了更方便的啟用備用庫功能，可以將從庫自動的提升為主庫，從而節省時間，此時故障恢復時間通常在分鐘級別（一般在60秒內）。
一體化的數據庫運維平臺
這是我們於2017年5月份在全球推出的一體化數據運維平臺，MySQL、SQL Database、SQL Database warehouse 、PostgreSQL被統一的放在該平臺中。它可以對運維數據進行優化監測並給出建議，能夠按需彈性放縮，資源管理。
讀寫分離的優化
支持基於副本的橫向擴展
正常情況下主庫和從庫之間通過網絡建立連接，然後將binlog從主庫傳輸到從庫，接著從庫將binlog作為一個Relay插入到數據庫中。如果主從庫都是在MySQL PaaS上，那麼MySQL實際就沒有打開Replication開關，此時從庫會另起一個進程，從Azure Storage上讀取主庫的binlog，然後解析插入到數據庫中。這種架構下支持基於副本的橫向擴展，適用於讀取壓力較大，或讀遠大於寫的業務，從屬實例不受限制，不過一般5個足夠了。
支持混合雲的數據庫同步
由於目前混合雲的應用還是比較多的，所以我們也支持混合雲的數據庫同步。比如從本地同步數據到Azure上以滿足Azure上的應用需要，或者應用平滑遷移到Azure。可以通過管理門戶配置同步和查看同步狀態。
新一代的架構框架技術
Stateless Services Pattern
我們這裡來回顧下基於雲架構開發後臺程序的兩個Patter，首先是無狀態模式。這個模式下存儲和前端服務器可以很容易的彈性放縮，問題於中間的業務層，因為業務之間是相互依賴，且用戶的數據代表某種狀態，要訪問這些狀態就不可避免的引入排隊機制、入鎖機制等。面對這些問題常見的做法是使用蓄水池方法，將用戶的請求放在queues中，降低無狀態服務的複雜度同時還可以達到無線擴展隊列的需求。
Stateful Services Pattern
在實際的應用中其實大部分還是採用有狀態模式，這種模式下依賴於有狀態中間件，有狀態中間件通過分區的方式解決高併發，在分區內使用傳統方式保證數據一致性。這種情況下數據的傳輸過程相對較少，延遲得到了保障。
Traditional Application
傳統應用程序的API、UI、引擎等都是整合在一起，在編譯的時候就能確定相互之間的依賴關係並能夠方便的發現問題。不過由於所有的模塊都被整合在一起，牽一髮而動全身，所以在水平擴展服務能力的時候要付出相當大的代價。
Application composed of microservices
不同於傳統應用，微服務框架中所有的模塊都是一個獨立的進程，模塊之間通過HTTP或者RPC等協議進行溝通。相當於應用中包含多個服務，服務之間通過標準協議調用，不過只有在運行時才能發現錯誤，而非編譯的時候。由於是完全基於網絡的框架，所以必須要考慮到網絡延遲的問題。微服務所帶來的好處在於能夠很方便的升級，模塊數據相對來說容易監控，模塊升級也已經可持續。
Service Fabric
Service Fabric是微軟的微服務框架。該框架中有一個ApplicationType用來定義App類型，類似於編程中的class。App創建後的實例可以有不同的名字，可以通過不同的名字來管理同一個實例。它同時支持有狀態和無狀態兩種服務。其中有狀態服務可以聲明式的支持多個分區，每個分區中實例可以創建多個副本，相當於通過分區提高高併發能力，通過副本提供高可用。在多個分區的情況下，每個有狀態的服務本身就可以創建一個狀態機，這個狀態機可以複製到其他幾點的副本中。由於副本的複製可配置，所以可以讓對有狀態數據的訪問基於本地節點，以此來降低延遲。
Service Fabric的另一個特點是對集群上運行的所有任務的自動部署，比如原來有5個節點10個分區，這不同的應用分區在這5個節點上會被自動分配，當節點擴大的時候，整個任務又會重新分配。這些部分都是自動完成，因此不用程序去顯示的關注。
整個Service Fabric提供了一個更好的底層框架，能夠實現高可用、可測試、可管理、可縮放。可測試指的是在服務升級的時候可以支持灰度發佈，還可以設定某個條件判斷升級版本是否有問題，一旦發現問題就會自動的回滾。可管理指的是基於內核級的檢查和管理，當某個節點出現問題的時候，該節點上的運行的任務會在其他的節點上被自動的管理恢復。可縮放指的是增加節點的時候，整個任務會被重新分配。
SQL Azure Service architecture
SQL Azure架構中的SQL Server數據庫被分解成很多的Service Fabric應用程序。物理集群被分成兩部分，一部分作為控制管理的節點集群叫做Control Plane，它更多的做數據庫的運維服務，另一部分用戶的數據庫任務運行在Data Plane上。他們之間有嚴格的安全發送機制，用來保證用戶和數據庫之間的運行環境。
Drawbridge
Drawbridge是微軟應用的新的容器技術，它既有虛擬機技術的強隔離性，又具有容器技術的高計算密度。核心是傳統的NT Process，有1200多個API，顯然這麼多API是很難做到嚴格意義上的絕對安全，因此後續進行了優化。首先是將NT kernel運行在用戶態，第二是讓用戶態的操作系統和真正的操作系統之間只允許不超過15個系統調用。基於這兩步NT上出現了一個特殊的進程Picoprocess，它從外部看就是一個空進程，唯一與它有交互的是一個很小的系統內核庫。
SQL Server for Linux也應用了Drawbridge技術，這樣就可以將原先windows上的SQL Server通過SQLPAL層移植到Linux上。
以上為今天的全部分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
