凌云時刻
三年前，我從淘系業務線轉到阿里云數據庫團隊做MySQL產品。三年過去了，MySQL產品從幾十萬節點規模發展到百萬節點規模，從非云原生的技術架構成功轉型到云原生架構。阿里集團是一個巨大的練兵場，一個新的技術只要能夠帶來價值，會有很多的機會在頂級體量的業務中得到應用，云原生如此，也是如此。
支撐MySQL產品應用的業務場景，體量通常巨大，在支撐大業務體量飛速發展的背后，技術同學一個很重要的價值在于對系統的不斷迭代和重構。之前看到不少分享核心系統架構重構讓業務更快迭代的阿里技術類文章，類似做著”開著飛機換引擎“的工作。這里我也做一個分享，來介紹這幾年深度參與建設MySQL云原生架構的心得和思考。
起源
MySQL是全球最受歡迎的開源數據庫之一，由于LAMP架構趕上了中國互聯網經濟爆發的窗口，也塑造了目前MySQL在國內無人能撼動的市場領導者地位。對于做技術的同學來說，對MySQL再熟悉不過了，快速、簡單、易用也是大多數開發者青睞它的原因。
一般來說，要想去部署一個MySQL數據庫并讓自己的業務去使用，可行的方案和做法有很多。但如果要將數據庫投入到生產環境去使用或者讓核心業務去使用，就需要考慮很多基礎問題，例如：數據庫的可用性角度來看，如何保證7*24小時的不間斷工作；從性能角度來看，如何保障再最優的參數和配置下能獲得最優的性能。如果是更高階一些的需求，需要進一步考慮：如何保障當數據誤刪后能夠快速找回，遇到性能問題如何能夠更快地定位到問題，數據庫規模大了之后成本該如何降低等等。
基于此，我們的工作價值在于從可用性、性能、安全、成本等多維度去給用戶提供一款簡單易用的數據庫服務，讓開發者能夠更專注在業務開發中。
故事的開始
阿里云RDS MySQL數據庫作為數據庫家族中的一款老牌數據庫引擎，擁有龐大的實例和用戶基數，包括阿里集團的內部用戶，公共云的用戶以及專有云的客戶。這里面有很多核心系統使用MySQL數據庫，例如集團的核心交易鏈路的買家庫、交易庫、庫存庫等，以及在互聯網、金融、民生等各個領域頭部企業的核心系統。保障這些數據庫全生命周期穩定運行的背后是一套龐大和復雜的分布式系統架構。
因為多年來的發展，很多應用中有著技術和業務多次迭代的影子。我19年加入數據庫團隊開始接觸這方面的研發工作，深切的感受到很多系統中充滿了年代感，例如有些系統中還在使用10年前很流行的SSH框架等等。正因如此，無論是后續的業務迭代，還是對于存量系統的維護，歷史的負擔也讓我們快不起來。
云原生這個詞前幾年出來的時候很熱，每個人都有自己的理解。有人說這還是個概念，有人說這只是個炒作，上市的那一刻，這些都沒有了。
2019年底，數據庫管控架構就開始推進新的架構演進計劃，全面基于以K8S底座+云基礎設施的云原生架構方向進行演進，我也開始深度參與到了MySQL的架構演進之路。
2020年開始，我正式開始了在數據庫團隊"開著飛機換引擎" 的工作，建設阿里云的MySQL云原生架構。
集團上云——云原生架構第一站
2020年是數據庫上云的元年，核心目標是保障在當年的618、雙11大促能夠將核心交易鏈路全面上云，以云的能力來服務集團的業務，集團數據庫上云的意義不言而喻：
深度融合
簡單來說集團數據庫上云后，對公共云來說只是一個具有大B屬性的用戶，如何去支撐集團大規模的數據庫集群是首先要考慮的問題。另外，集團上云，集團的技術能力不僅可以復用公共云的技術能力，同時給集團定制的技術能力也能反哺給公共云，公共云可以包裝為產品化能力輸出給公共云的客戶。
從集團業務來說：
通過MyBase專屬集群模式的包裝，我們將集團和云上數據庫技術架構完成了深度的融合，把集團用戶當做一個大B用戶來服務，集團擁有和公共云的產品同等體驗。
集團上云的第一個驗證點是2020年的618，這次618我們以一切都是全新的技術架構來度過了第一次大考。這里全新的技術包括：全新的多點寫數據庫內核，云原生管控的第一次大規模接客，ENI網絡架構的首次大規模應用，數據庫定制神龍機型，計算存儲分離架構，全新的OS內核等等。
在2020年618結束后，集團上云團隊成員開始陸續發生了變化。因為項目需要，我屬于第一批補位進入的集團上云項目，參與了給集團定制特性，下面詳細介紹給大家。
集團定制特性
特性一：多點寫架構
集團的多點寫架構是我在集團上云項目中落地的一個重要特性，核心是在大促高峰能夠實現備庫資源可利用，通過引入Multi-技術，有效實現了備庫可讀寫的架構體系，是大大實現了降本增效的一個特性。
特性二：面向跨單元讀寫的全球數據庫
高并發低延時高可用是對數據庫基礎能力的要求，異地讀寫定制調度則是對RDS產品形態的挑戰。云上的RDS以實例為基本的管理對象，主實例和只讀實例在本單元互相可見；RDS在各單元建獨立部署，單元間的實例不相互感知，跨單元的數據同步則需要通過DTS來完成。
集團異地讀寫的場景下要求全球的數據庫作為一個整體，能夠進行分流和切換。我們采用全球數據庫網絡的產品形態來滿足（Global Network, GDN），在RDS單元化的基礎上，通過更高層次的抽象形成跨地域的組網方案，而這種產品形態在以往的RDS產品體系里面是不存在的。
DB采用了張北中心、南通、河源和第四單元的部署方式。集團上云的過程中，核心交易通過張北為中心、南通與河源為單元的三地部署模式組成一張全球數據庫網絡，通過原生的數據復制完成中心與單元的數據同步。云管控在張北和南通河源之間進行了管控的單元化獨立部署，也涉及到跨單元之間的元數據同步問題。
通過這個GDN方案，滿足了集團異地容災、跨單元讀寫低延時的需求。
特性三：資源調度模板
集團業務對于數據庫部署的需求是極為苛刻的，一方面集團的主機資源是有限的，因為成本是每個企業都需要考慮的問題，另一方面數據庫的部署模型也是很有講究，例如相同業務的DB需要部署在同一主機，并且單機不能超過多少個實例 ，這樣做主要也是為了穩定性和性能的考慮。
為了能滿足2020年雙11的峰值考驗，需要在短短一個月內完成集團數據庫達到大促態，當時提供的方案是做了一套調度策略模板，調度策略模板和業務屬性掛鉤，按照不同業務屬性的策略來實現DB間的親和性和反親和性。但是由于前期集團數據庫上云的不規范，導致現有集群的數據庫在主機上的部署已經很混亂了，所以要從一個混亂的部署模型轉變成符合業務需求規范的部署模型結構，并且要保障在有限資源的情況下去完成，我們采用了最為原始且當時認為最有效果的方案來解決，就是后面會講到的“數據庫的華容道”。
人肉運維
由于集團上云采用全新的技術架構，各種基礎設施和技術能力都不完善，以及代碼中還有很多bug，為了能夠支撐集團數據庫上云的業務，數據庫管控團隊到集團上云后期基本是進入了全員人肉運維的階段，下面說幾個故事：
故事1：數據庫的華容道
華容道的起源是，曹操在赤壁大戰中被劉備和孫權的“苦肉計”、“鐵索連舟”打敗，被迫退逃到華容道，又遇上諸葛亮的伏兵，關羽為了報答曹操對他的恩情，明逼實讓，終于幫助曹操逃出了華容道，所以有了一個很有意思的游戲，就是在有限的區域內把曹操挪動出來。
之所以說是數據庫的華容道，原因是上面提到必須在有限的主機資源下，讓數據庫滿足復雜的部署模型。基本上做法是，寫了一個資源計算的腳本來計算每個集群如何達到一個最優解。另一方面是寫了好幾個腳本來下發和監控任務數據庫在主機上的騰挪任務，手段就是通過不斷對數據庫在主機上騰出來挪進去，反復騰挪，就像華容道一般，最后達到部署終態。
由于業務的數據庫不能白天來做資源騰挪，會對業務造成影響，我們只能選擇晚上12點后開始做，那幾周基本上每天是下午3點開始上班，早上6點回家睡覺，生物鐘整個調整為了美東的時區。慶幸的是，云原生架構中存儲計算分離帶來的紅利，數據搬遷不需要時間，整個騰挪效率還是比較高（除了核心的幾個使用本地盤ECS形態資源的數據庫實例）。經過了幾周，最終還是完成了任務，讓數據庫集群達到了大促態，這個時差也算值得了~~
故事2：NUMA配置帶來的影響
集團的全鏈路壓測基本上從9月份就會陸續開始，當時國慶前做的全鏈路壓測沒有通過，最后排查的原因是由于在主機上線的時候NUMA配置存在問題。結果發現當時全網5000+臺主機都有問題，調整NUMA還需要和ECS團隊的同學配合一起來做，全網ECS主機都要進行重啟和變配，所以變更起來非常費勁。
這也意味著我們要在國慶期間完成全網主機重啟和變配，然后10月11日再來接受全鏈路壓測。上千臺主機的重啟是非常痛苦的，因為數據庫是有狀態的服務，主機重啟意味著上面必須全部是備庫，并且由于集團使用的內核，三個節點必須達到多數派，否則就會無法寫入，不僅僅要全部是備庫，還需要保障主機上DB多數派節點是存活的才能重啟這個主機。
當時的做法是，我寫了一個腳本，功能是指定一批主機進行主機上的實例進行主備切換，檢查TDDL，檢查數據庫集群多數派情況，設置雙1參數等等，然后輸出可以重啟的主機列表，這批主機列表上只有備庫。如果是不滿足需求的主機，上面的數據庫實例需要進行備庫修復的工作。國慶期間整個數據庫團隊幾十號人加上ECS團隊的同學，分兩班倒，一班人白天重啟那批可以重啟的主機和修復有問題的DB，另一班人半夜負責通過腳本下發主備切換的任務，保證業務不受影響的同時白天班次的人能夠有主機去重啟和做變更，就這么輪軸轉，最終完成了全網主機的變更。
最終，我們在10月11日通過了全鏈路壓測大考驗。
故事3：惡性循壞帶來的后果
全新的東西必然在開始階段會帶來很多問題和不穩定，再加上批量去大規模的騰挪實例，由于騰挪的任務流代碼缺陷，導致很多問題，例如內核參數不一致或者不符合預期，TDDL配置不對，資源的隔離出問題等等。
這些問題對于業務帶來的影響可大可小，例如內核參數來說xkv沒打開，對于那種流量很高的業務來說，數據庫很容易被打掛。例如，雙11前有一輪全鏈路壓測發現天貓超市有一個DB抖動很嚴重，結果發現是xkv參數沒打開，結果壓測完都快凌晨2點了，又緊急做巡檢和修復，搞到早上6點才解決。
就是這些不斷的小問題，基本上是在集團上云過程中被業務方噴得最慘的。
故事4：巡檢保障下的雙11
集團數據庫集群雙11對于管控的一個很重要的職責，是通過巡檢的手段保證集團數據庫的一個穩定態，例如某個主機是否有宕機的風險，某個參數是否設置正確，是否在高峰存在備份任務等等。
當時的解法是，寫了很多腳本來去掃描數據庫集群的各種保障指標，然后通過每日郵件的方式進行上報。如果存在異常，又要寫一些腳本來修復這些有問題的數據庫實例。
整個雙11下來，累計了很多大大小小不同功能的腳本，這些腳本自然是零散并且不成體系，也沒有什么能沉淀下來的東西，只能說通過這種腳本運維的模式，保障了雙11的平穩度過（當然寫了那么多腳本，個人寫腳本的能力也是得到了突風猛進的進步~）
集團上云的最后
現在回過來看2020年我們做的集團上云，確確實實鍛煉了云的能力，也確確實實鍛煉了經歷了這年集團上云的每一個同學。雖然集團上云帶來的變化和壓力，上云團隊的研發成員換了一波又一波。但是最后堅持下來的也收獲了巨大的經驗寶藏，也讓自己能夠更從容的面對壓力，正是這段經歷，為后續在云原生架構的演進積累了寶貴的經驗，這次經歷也是此生難忘的一段經歷。
混合云——DBStack的一段經歷
2020年雙11后馬不停蹄，一方面維護集團上云，另一方面開始進場混合云的DBStack。
DBStack核心背景是：
DBStack是阿里云數據團隊針對混合云市場推出的集交易、分析、傳輸、治理于一體的企業級數據庫管理平臺。DBStack作為公共云的一個切片，將公共云能力對接到混合云底座上，一方面實現最小化純軟輸出的能力，另一方面可以對接到第三方IAAS的資源部署，實現輕資產、被集成的能力。
我參與DBStack核心工作是讓RDS MySQL進場DBStack，將集團的XDB結合PolarDB-X以兩地三中心的部署模型實現可輸出能力。
當時做了幾個核心的事情：
管控服務組件完全對接了混合云的k8s底座，滿足管控組件和DB混部，實現最小單元輸出能力
將依賴的部分基礎服務做到了完全可插拔弱依賴（例：VPC服務，白名單服務等）
復用集團上云的能力，將XDB三節點模型擴展成符合兩地三中心的部署模型結構
DBStack的經歷到去年2月初收尾，雖然只經歷了短短3個月的時間，但是基于K8S底座的云原生架構帶來的紅利已經逐漸開始顯現出來。
All in公共云
2020年團隊的主要精力都是All in 集團上云，從而也導致公共云的業務迭代停滯了很長一段時間。在2020年雙11后才開始逐步慢慢釋放人力開始在公共云的業務上進行開展，在FY22財年開始，組織架構做了很大的調整，團隊從之前集團上云+混合云+公共云轉變為：All in 公共云。
相較集團上云來說，公共云的整體節奏是自主可控的，留給思考的時間更充足了，想清楚怎么做以及怎么規避之前遇到的問題顯得非常重要。
重新定義云原生架構
再去看如何更好落地MySQL公共云的云原生架構，最開始需要思考在公共云的體系中，云原生能給MySQL帶來什么變化？
MySQL作為一款開源托管的數據庫產品，在這個宏觀的定義下，我們希望是能夠將云的能力最大化去利用，使用云的資源池化的能力，使用好云的能力去做好上層的PAAS產品能力，并服務好客戶。
通過K8S對資源的抽象，讓上層的PAAS能夠更方便地操作IAAS的資源，讓PAAS和IAAS徹底實現解耦，并讓PAAS享受IAAS演進帶來的紅利。
云盤技術架構重構
云盤產品重構第一站：MySQL的基礎版形態
整體背景：基礎版實例往往是客戶體驗云數據庫的第一站。基礎版實例的數量龐大，然而，在多個渠道（NPS、工單、客戶問題等）中，我們聽到很多客戶對這類實例的性價比和穩定性提出質疑。對工單、客戶問題等進一步分析，我們發現基礎版實例給客戶帶來了以下幾大痛點：
實例創建時間長：單實例創建時間長達20分鐘，嚴重影響用戶業務效率；
存在部分穩定性問題：小規格實例經常會發生內存耗盡導致ECS Hang，嚴重影響客戶業務的順暢度。穩定性問題也體現在我們每月服務量上，有些單類問題一直是居高不下，給客戶帶來了很多產品體驗問題；
資源成本高：單租戶架構要為每個RDS實例創建系統盤，使用獨立的管控組件資源，我們不能降成本的同時意味著用戶的價格也沒辦法降低。
之前的架構模型，主要采用單租戶的架構，一個ECS對應一個RDS。
優點：
缺點：
為了能夠解決遇到的這些痛點，在基于云原生架構的底座之上，我們一方面保留了單租戶的架構，給到對有隔離性需求的用戶；另一方面也增加了多租戶的架構模型。
多租戶模型的優點：
基礎版產品的架構重構在2021年S1完成落地后，我們將增量的新購實例全部切流到了云原生架構上，同時也打通了存量的實例可無感遷移到云原生架構的遷移流程，用戶可以通過控制臺內核版本升級就能完成遷移。
整個架構的重構項目做下來，團隊也拿到了阿里云FY22-S1的紅草莓獎。
彈性能力是核心競爭力
云數據庫的一大核心就是彈性能力，彈性能力能給數據庫帶來更多想象的空間，例如：數據庫的，當RDS MySQL全面跑在云原生架構上之后，彈性是最優先需要去提升的能力。
對于外界用戶來說，在MySQL產品上購買本地盤形態是大多數用戶的一個默認行為，其主要原因是本地盤的性能是云盤性能很難去超越的。雖然云盤的技術體系一直在不斷演進，性能也越來越優，但是要在成本+性能上超越本地盤尚且需要時間。
云原生架構主打存計分離的架構，所以彈性能力是一大需要突破的點，也是云盤架構的一大核心競爭力，依托云原生資源池化的技術紅利，到今天為止針對彈性能力我們做了幾大核心優化：
存儲彈性：通過云盤提供的，性能等級熱升級等能力，實現了存儲的彈性；
實例創建提速：引入系統盤快照，鏡像加速，組件預安裝，流程并行化等技術，實現了實例創建的提速，完成了實例拉起提速的突破，多租戶降低到3分鐘內，單租戶降低到5分鐘內；
本地快彈：在多租戶場景下，最大化利用主機資源，解決用戶在高負載下做DB的資源變配由于備庫復制延遲導致經常失敗的問題，我們通過引入Pod變化監聽來動態修改cgroup+內核的BP熱修改來實現DB的熱升級；
只讀實例并行化：引入秒級快照，備份復用等能力，滿足用戶添加多個只讀，做到能夠并行創建，且在3分鐘內完成只讀實例創建；
彈性節點池：多租戶形態下，我們有了二層調度做到MySQL業務的資源池化。同時在ECS資源節點池的管理上，利用ECS帶來資源池化的能力，來保障了持有成本的最大化。
通過這幾個手段大幅提升了彈性能力，一方面提升了云盤架構的核心競爭力，另一方面為RDS on 打下了堅實的基礎。彈性能力的升級給RDS產品帶來了更多的可能。
穩定性是一切的基礎
集團上云那次“開著飛機換引擎”的經歷，給我帶來很大的一個經驗和思考是：如果再去做一次“開著飛機換引擎”的項目，該如何去提升保障的穩定性。公共云的云原生架構升級不僅不比集團上云輕松，反而更困難，用戶使用云數據庫的用法是多樣化但不是標準化的。
我們需要在用戶無感的情況下自動切流到云原生架構上。核心思路還是要去構建一套基于數據驅動的穩定性基礎設施的通路閉環。
核心幾個點：
數據采集：結合DBAAS產品團隊提供的數據中臺能力，通過Agent+中心化體檢，解決了當初集團上云中每天寫腳本去巡檢的方式，同時數據采集異常和事件進入中臺沉淀；
實例體檢：當初在集團上云過程中遇到最大的問題就是，由于代碼發布導致線上的實例發生可能在做變更的時候出現非預期的行為，但是這個時候我們完全沒有感知。吸取了當初的教訓，我們新增了實例變更觸發一次全量的體檢，保證不會再由于代碼發布或者其它因素導致實例出現非預期的行為。
穩定性大盤：基于數據中臺的能力，構建一套穩定性的可視化大盤，讓全局穩定性是可觀測可分析的，通過穩定性大盤解決了當年集團上云對穩定性層面抓瞎的問題；
自愈&治理：基于異常事件數據，通過數據驅動的方式對部分異常做到自動化的自愈，另一部分異常事件成立專項進行單獨治理；
變更規范：事前、事中、事后通過建立變更三板斧的機制來保障云原生架構切流上線的穩定性；
工具化：穩定性和工具體系結合是提升穩定性保障很有效的一個手段，我們將穩定性的能力孵化出了實例一鍵診斷、大客戶重保等工具能力，提供問題排查、日常值班等場景，提升了整個效率和效能。
穩定性是業務發展的基石，也是我們持續在構建的方向，在公共云業務升級云原生架構中，到目前為止，通過構建穩定性基礎能力讓我們沒有產生過故障，也順利達到了之前制定的向云原生架構全面演進的目標。
我們需要工具來提效
在2021年我們專門找了一個同學來做工具平臺，為什么要做工具？
核心思想是：
在2021年下半年開始，我們主要圍繞RDS MySQL的業務屬性，打造了工具平臺的幾個大模塊：
工具平臺的逐步建設，為我們在云原生架構的建設道路上從多個維度實現了提能提效，同時也讓更多同學能夠更容易地參與進來，讓我們在云原生架構的建設道路上能夠跑起來。
現在的公共云
到今天為止，我們已經將RDS MySQL的云盤架構完成了全面向云原生架構的轉型，其中包括基礎版和高可用產品形態。公共云的用戶購買云盤產品形態的數據庫實例，已經完全切換到了云原生的架構中，目前已將近十多萬個RDS MySQL數據庫實例跑在了云原生的架構上。同時我們也做了通過自建用戶備份集一鍵上云的能力，幫助用戶把自建的數據庫實例上到云原生架構，經過在這條道路上不斷的探索，MySQL在云原生架構上逐漸找到了自己的方向。
基于云原生架構，我們目前也在逐漸往極致彈性的技術方向進行演進，RDS on 打造的極致彈性的數據庫產品形態也將會在今年進行發布，敬請期待。
寫在最后
從2020年開始到今天，我們從0到1建立起了MySQL的云原生架構，經歷了兩次“開著飛機換引擎”，一次集團上云，一次公共云架構升級，云原生的技術架構體系逐步走向正軌。我認為，云原生架構的旅程才剛剛開始，接下來我會不斷去結合云原生帶來的紅利提升產品的競爭力，打造更極致的MySQL產品體驗。
當然，RDS產品未來的想象力不僅如此，云原生的技術架構也不是終點。隨著技術的不斷發展迭代，我們也需要不斷和阿里云的ECS、存儲、容器等團隊一起創造更多的可能性。（正文完）
你可能還想看
1.
2.
3.
4.
5.
END
如果喜歡我們的文章請點擊「在看」?