《MySQL雲資料庫架構設計與實踐》主題分享
導讀：
本文根據愛可生洪斌在第九屆中國資料庫技術大會（DTCC）的現場演講內容整理而成。小編閱讀全文需要 15分鐘。
愛可生技術服務總監
洪斌
愛可生技術服務總監，負責MySQL資料庫在傳統行業客戶的應用推廣與技術諮詢，曾為運營商、銀行、證券、保險、航空等行業內數家大型企業提供MySQL技術諮詢服務。
《MySQL雲資料庫架構設計與實踐》
《MySQL雲資料庫架構的設計與實踐》，主要分享愛可生在架構設計過程中的技術選型，跟大家做一個交流。
大綱
MySQL 8.0
為什麼需要DBaaS
架構設計演進
服務可用性設計
數據可用性設計
監控設計
DTS設計
未來規劃
1.MySQL 8.0
MySQL是一個有二十多年歷史的開源資料庫，也是時下互聯網最流行的開源資料庫。愛可生大概從2006年開始做面向各類傳統行業客戶的MySQL應用推廣和技術服務工作，到現在大概十二年的時間了。
MySQL 8.0在4月19號剛剛發布有非常多的新的特性，在此挑選了比較重要的幾點來跟大家分享。
首先是 MySQL SQL + NOSQL的新架構。近幾年互聯網的蓬勃發展，新興的許多NOSQL數據，比如文檔型資料庫MongoDB。考慮到此類業務場景的需求，MySQL 5.7版本中也支持了Json的數據類型，便於操作Json格式的用戶函數。MySQL 8.0在此基礎上做了更多的優化並且開放了新的X 協議，用來支持NoSQL的API介面。在MySQL系統內既能使用SQL查詢，也能使用NoSQL API方式，並且Java、Python、.NET等官方連接器都已加入了X協議的支持，X 協議默認是開啟的33060埠。這也體現了MySQL在持續優化，廣泛吸納開源社區的建議。
關於SQL支持，以往MySQL給大家的印象是SQL支持簡單，不支持複雜類查詢比如說窗口函數，CTE等。MySQL 8.0 在SQL支持上也做了較多改進，在這些方面目前已基本上和其他的開源資料庫甚至一線的商業資料庫不相上下，甚至有一些地方支持的更好，比如Json部分，這部分MariaDB和PG都沒有完全支持，這個地址有更詳細的介紹：
鏈接：
https://modern-sql.com/blog/2018-04/mysql-8.0
2.為什麼需要DBaaS
接下來主要介紹DBaaS 平台的架構演進以及我們的技術選型。為什麼需要DBaaS，主要是基於以下三點原因：
降低開源資料庫使用門檻
手工->自動化->自助化
服務標準化
這屆DTCC的總體感受有大量和NewSQL資料庫相關的主題，各個大廠都在做自己的基於開源資料庫的分支。愛可生還是以支持原生MySQL版本為主，這個也是大家使用最多的，也可以解決大部分業務場景，我們希望幫助更多傳統企業，沒有太多自研能力的客戶更好的使用它。
自動化運維發展的越來越成熟，隨著資料庫實例的快速增長，運維方式在從手工到自動化，再到自助化的過程，將資料庫服務化更快更便捷的提供服務能力給業務方，支持業務的快速發展，不讓資料庫成為業務發展的瓶頸。
服務的標準化，業務方不需要關心資料庫的底層架構，只提需求，平台自動分配資源提供可靠的資料庫服務，將資料庫服務做成一種標準服務，這些是DBaaS的重要意義。
大概在2011年，我們開始了第一代設計，那時在幫移動研究院做一個MySQL RDS平台，就是把MySQL包裝成標準服務提供給移動企業客戶。這代架構比較簡單，在控制平面的Manager端負責接受用戶服務請求，下髮指令給Agent端；MySQL用來存管理信息，DBA通過Manager操作管理資料庫實例。每個資料庫伺服器部署的Agent管理該主機的MySQL服務。
第一代的設計主要是通過shell腳本去完成資料庫的基本自動化工作，Manager和Agent用Java來開發，Java調用shell腳本。DBA來開發腳本，開發來開發調度框架。
第二代設計我們改良了一代基礎上的一些問題，比如高可用，第一代設計通過腳本的方式只能做到一些簡單的Failover切換，但無法做到MySQL快速failover。第二代的設計基本架構不變，將Manager做了拆分，它拆分出來web服務層和調度層。增加了額外的HaServer組件，來解決MySQL主從Failover切換。
存在的問題：
環境依賴，測試覆蓋不足
沒有擴展性，功能全部耦合
Failover無法保證數據一致性
配置管理存在單點
監控、告警依賴第三方監控平台
備份計劃依靠定時任務，缺失恢復演練
3.設計考量
為了解決這些問題，在第三代設計上我們對架構做較大的調整和重構，包括這些設計上的考量。
開發語言
Golang/Python/Java
架構設計
按功能進行微服務拆分
故障域小
可按功能獨立升級
可降級運行
逐級守護
自檢告警
反向告警
支持VPC網路
安全性
RPC鏈路加密GRPC with TLS, 每個伺服器生成私鑰
日誌無明文密碼，落地加密保存
審計日誌
Linux capabilities機制許可權細分，避免使用root和sudo
三代的架構中，我們把很多功能拆成多個微服務組件，增加了中間件部分。在組件的命名上里都以U打頭，因為MySQL是My，我們就取Your諧音。哈哈。
控制層面：
Ucore是用來做配置管理的，原來是MySQL單點，如果要解決它的高可用意味著需要給它掛備節點去冗餘它，Ucore是一個分散式KV存儲，自帶的高可用特性，leader節點掛了會自動選舉新的leader節點。整個集群的配置信息的保存在這裡，其餘組件註冊後會看到全局配置信息。
UMC是面向DBA的管理入口，集群管理操作是從UMC進入，而URDS是面向開發者提供自服務的入口，開發可以通過該入口申請需要的資料庫服務，並管理自己的資料庫。
Urman 組件是負責資料庫備份調度管理，所有資料庫實例的備份任務調度都是通過Urman服務去控制，其對應的Agent接收Urman發出的請求和指令，Agent執行備份操作。
Umonitor是用來做監控數據匯總和展示，它從Ustat中拉去監控數據。
Ustat負責性能數據的採集，包括資料庫服務的性能指標及系統層面的資源監控。
Uguard負責MySQL服務的高可用切換，Uguard-mgr做切換決策，Uguard Agent負責決策的執行。
數據層面：
在物理機上部署多個MySQL實例，實例間採用Cgroup方式做資源隔離，包括CPU、內存以及磁碟IOPS，用磁碟配額方式管理磁碟空間，資源的規格由管理員來設定。
Proxy層面：
Uproxy，解決需要讀寫分離的業務場景，它是一個透明的讀寫分離中間件，所謂透明就是業務不需要改造，不需要劃分讀地址，寫地址，只提供一個入口，業務直接訪問中間件。它會自動做讀寫分離，事務發往主節點，非顯式事務的查詢語句發往從節點，我們做了大量優化儘可能減少中間件的性能損耗。
Ushard，解決數據需要水平擴展的業務場景，使用數據分片方式，根據業務場景選擇合適的拆分欄位和拆分函數將數據分散到多個數據節點。
Proxy層面也有高可用守護，這樣整個集群都沒有單點的風險。
我們的目標是把這幾種架構全部在一個平台管理起來，建議一套統一的運維管理體系，當然現在已經實現了這個目標。
4.服務可用性設計
關於服務可用性，主要通過以下幾個維度來介紹。
不只是切換
Slave 寫了數據怎麼辦
Slave的可用性
複製鏈路的可用性
決策者的可用性
切換
首先，MySQL切換隻是其中一個環節，影響業務連續性的因素我們都要考慮到。比如從機實例的服務狀態，從機不能被寫數據，複製鏈路的狀態、降低這些因素的影響才能保障較高的可用性。
我梳理了下MySQL的切換流程大概有11個步驟
逐層守護
逐層守護的意思是指，每層服務都會有它的上層服務負責可用性守護，最外層是資料庫服務，然後是守護資料庫的客戶端層，再是管理端層，最後是核心層Ucore。
SLA
SLA是一種輔助切換決策的量化機制。不同業務類型的資料庫對可用性和數據一致性的要求是不一樣的，比如說日誌系統，對可用性訴求大於數據一致性; 而交易類系統，數據一致性是必須的。因此我們定義了兩種協議，一種是RPO協議，一種是RTO協議。RPO協議保障數據的RPO級別，包含P和PE兩類級別，P類是主從日誌無差異，存在一定延遲級別就告警，PE類是日誌有差異時不做切換由人工干預。
RTO是保障服務連續性需求，也分為兩類級別T和TE，T類是切換前如果日誌有差異最多允許補償多久。TE類是日誌差異較大超過所允許的丟失的極限，這時需要人工干預。設置好SLA協議，故障時會根據協議決策切換邏輯。
5.數據可用性
數據可用性包括了兩部分，數據的備份和數據恢復演練。
定義一個運維時間窗口，備份調度器會根據備份策略編排任務，如果設置了轉儲設備，再自動將備份集轉儲。
除了備份以外還有演練，如果只是做完備份就不管了。當需要恢復時也不知道是否一定可恢復，這就需要定期進行演練。我們可以在平台中設置恢復演練任務，自動幫你做恢復演練，把恢復演練做到日常中除了有備份的，也有演練的任務，這個演練的任務會對你的備份集進行一個恢復的演練。備份產生了以後我們就會在一台演練機上來做恢復，檢測這個備份是否能夠恢復出來。能恢復出來我們就會認為這個備份機是OK的，其實就是把演練做到了日常中。
6.監控設計
監控我們原來用的zabbix，現在的選型是Prometheus監控框架，它是時序型存儲數據比較緊湊也便於查詢，用Grafana展現監控數據，數據採集我們做成單進程模式，利用go channel並行採集多個服務數據。
7.DTS設計
數據傳輸服務主要我們解決數據遷移的應用場景，比如 分散式集群里分片遷移。它的設計要點包括以下內容：
l 分散式架構
l 窄帶寬下傳輸效率高於原生
l 全量+增量傳輸
l 支持GTID
l 支持並行回放
l 輸出端支持kafka
l 支持 multi-master, star, fan-in 多種拓撲
l 兼容阿里雲、微軟雲、原生MySQL
它還可以用於上雲,下雲，雲間的數據遷移。這個是DTS的架構和設計圖。
Manager是Leader+Follower架構，自動選主，它負責遷移任務下發。Agent既可以作為數據的提取端，也可以作為數據的回放端。通過提取端可以從MySQL的Binlog里提取日誌信息，傳遞給回放端，回放端並行回放日誌。一個DTS集群可以管理多套的資料庫服務，界面設計如下：
8.未來規劃
1）支持更豐富的開源資料庫
根據用戶的需求支持更多類型的資料庫服務。
2）容器化
探索適合資料庫的容器化管理方式
3）混合雲
公有雲+私有雲
在一個中心統一管理私有雲和公有雲的資料庫服務。
PPT分享-百度雲盤鏈接：
https://pan.baidu.com/s/189KKunYleueUnt7RVD8q5A
密碼：zitp
愛可生（證券代碼：832768）依託於融合、開放、創新的數據處理技術和服務能力，為大型行業用戶的特定場景提供深度挖掘數據價值的解決方案。公司持續積累的核心關鍵技術，覆蓋到分散式資料庫集群、雲資料庫平台、資料庫大體量運管平台、海量數據集成與存儲、清洗與治理、人工智慧分析挖掘、可視化展現、安全與隱私保護等多個領域。公司已與多個行業內的專業公司建立了長期夥伴關係，不斷促進新技術與行業知識相結合，為用戶尋求新的數據驅動的價值增長點。公司已在金融、能源電力、電信、廣電、政府等行業取得了多個大型用戶典型成功案例，獲得了市場的廣泛認可和業務持續的增長。
TAG:愛可生雲資料庫 |