OB君：9月21日，OceanBase 2.0 在雲棲大會上重磅釋出。我們將在接下來的時間裡為大家持續推出 “OceanBase 2.0 技術解析系列” 文章，分別從 可運維性、分散式架構、資料可用性、價效比及相容性 五個方面對OceanBase 2.0的產品新特性及其背後的技術原理進行深入的解析。本文將帶你全面解析新一代的OceanBase雲平臺，更多內容歡迎持續關注本系列！
現任螞蟻金服OceanBase團隊技術專家，2014年加入阿里巴巴，從事領域涉及分散式事務中介軟體、中介軟體高可用，目前主要負責OCP 2.0系統的建設工作。
原文：
OceanBase雲平臺（OceanBase Cloud Platform，以下簡稱OCP）是一款專門用來管理OceanBase資料庫叢集的管控平臺。通過OCP，可以一鍵安裝、部署、升級OceanBase叢集，監控叢集的執行狀態，建立和維護運維任務，並且對應用開發者透明。OCP伴隨著OceanBase而誕生，至今已經從1.0全面進入2.0時代。
OCP 1.0由zookeeper、kafka、Jstorm、Hbase、OTS、OBAgent、obztools等十餘個元件構成，各元件協同，在阿里巴巴集團內部，管控了超過5000個OceanBase服務節點，每秒處理監控指標超過100萬次。
然而，功能和架構如此複雜的系統在向雲轉型的時候遇到了兩個艱難的問題——部署成本高並且運維複雜。這兩個問題對OceanBase的快速輸出造成了巨大的障礙。在照搬集團內部技術架構的過程中，系統的表現甚至不如某些開源系統。
問題總是可以在歷史中找到答案。英特爾公司成立之初主營業務是半導體儲存器晶片，很多年來，英特爾就是“儲存晶片”的同義詞。然而幾年後，英特爾在自己開創的儲存器領域被 5 家來自日本的電子公司甩到了後面。
英特爾的兩個創始人葛洛夫問摩爾，“ 如果我們下臺了，公司再任命一個新CEO，你覺得他會怎麼辦？” 摩爾不假思索地回答，“他會放棄儲存器業務。”，“那我們為什麼不這麼做呢？”。所以，誕生了全球最大的處理器巨頭。
那麼，對於OCP團隊來說，如果讓我們重新來架構OCP 2.0的話，我們該怎麼做呢？
一、場景的變化
1. 基礎設施的變化
阿里集團基礎設施包括了若干自建獨立機房，機房之間通過高頻寬低延時高效骨幹網路相連線，即使跨城的機房之間網路傳輸丟包率也很低。
構建於高質量基礎設施之上的開源元件，比如zookeeper，可靠性很高。然而，對於大多數企業級客戶，有些是租用第三方機房，有些不具備三機房條件，基礎網路的可靠性也不高，延時不穩定，開源產品執行故障率很高，OCP的SLA無法得到保證。
2. 業務的變化
眾所周知，阿里雙十一所面臨的高併發場景是極端的，需要投入大量的基礎設施資源、人力資源來保障系統的穩定執行。而外部業務由於其差異性，往往對基礎設施的投入成本比較敏感。OCP的近十個元件的部署成本很高。
阿里集團由於其業務需要，比如HBase、JStorm等主流的開源產品都有專門的團隊維護，專業的技術力量為OCP系統提供了強大的後背。然後，在外部輸出的時候，OCP系統顯得孤立無援。
綜上兩點，若干開源元件依賴，對OCP的可靠性帶來了挑戰，也引入了較高的部署成本。
二、OCP 2.0的誕生
OCP作為直接面嚮應用開發者的線上系統，同時承擔了超大規模OceanBase叢集的監控和運維工作。在對接企業級業務系統的場景下，至少需要具備以下能力：
- 對於線上系統，需要提供持續且穩定的高可用服務
- 對成本敏感的企業使用者，要求OCP在佔用少量機器資源的同時，提供高併發訪問
- 儘可能少的運維人員投入，要求系統能夠實現無人值守
- 提供可定製、可擴充套件的產品能力，可線上升級
綜上，OCP 2.0在架構設計上，進行了徹底的自我革命，完全拋棄了1.0時代對若干開源元件的依賴，OCP層面堅持去中心化的設計理念，將所有的狀態資訊集中到OceanBase資料庫。
因此，帶來的最直接的收益就是極大的縮短了服務鏈路，在架構層面保證了系統的執行質量，同時，去掉了開源軟體的部署成本。
三、OCP 2.0解決方案
OCP 2.0由運維鏈路、監控鏈路、診斷鏈路、資料鏈路、高可用鏈路、基礎設施等若干子系統。每個子系統又切分成數十個甚至上百個小服務，每個服務實現一個獨立的業務邏輯，服務間弱依賴，帶來了開發語言以及系統框架選擇的靈活性。
1. 基礎設施
考慮到外部場景的基礎硬體多樣性，OCP 2.0提供了統一資源排程層，將物理機、Docker、ECS等納入資源池統一管理，提供標準化介面遮蔽底層差異，並通過規模化來降低總體成本。同時，標準化IT資源，有利於完成應用服務的快速伸縮。
OCP 2.0統一計算平臺提供了標準化的計算能力、任務編排能力，可根據簡單定製完成實時、半實時、週期、定時等各類計算需求。支援各種計算任務，包括shell、python、java、http等，能夠滿足常見的計算需求，還支援將應用自定義的java、python等程式碼投遞到計算平臺，實現按業務需求對系統擴充套件。
2. 高可用鏈路
OCP 2.0對安全問題非常重視，引入了流量控制保證系統執行時安全，引入了租戶隔離保證業務之間資料安全。同時，系統引入全鏈路跟蹤機制，監控完整的服務流轉路徑，儘可能縮短異常診斷路徑，降低運維對人工介入的需求。
3. 運維鏈路
OCP 2.0承擔了OceanBase叢集、例項、租戶、主機等維度的白屏化運維操作。不同於集團內部有DBA團隊承擔所有資料庫運維操作，外部往往按照組織結構或業務部門來劃分資料庫例項，各司其職，因此OCP 2.0劃分了系統管理員、應用管理員、應用開發人員三個角色，每個角色有各自的使用者視角，每個角色承擔部分運維功能，不僅符合使用者行為，更增強了資料庫安全性。
依託於統一計算平臺，做到了運維任務的全程可監控。只要是執行於計算平臺的計算任務，計算平臺會分配一個獨立的程式負責任務執行，同時，把執行時IO流、錯誤流實時推送到瀏覽器端，做到計算過程所見即所得。
4. 監控鏈路
OceanBase的監控物件包含叢集、租戶、服務節點、SQL等多個維度，包含上千個監控項，計算每一個監控項都會記錄若干乃至上百條監控日誌。OCP 2.0將監控資訊儲存到OceanBase資料庫，可使用日誌副本來儘可能降低儲存成本。
OCP 2.0提供了靈活的監控指標定製能力。在以往的儲存模型選型中通常會遇到寬窄表的選擇，如果採用寬表作為監控儲存模型，一旦監控指標發生變化，會造成鎖表；如果採用窄表，可以較好應對指標變化，但是會造成儲存空間的浪費，不夠經濟，並且監控指標變化會引起計算邏輯變化，系統維護成本高。OCP 2.0利用了OceanBase增量資料寫記憶體、定期轉儲的特性，採用寬表作為監控指標儲存模型，同時DDL不鎖表。
5. 診斷鏈路
OCP 2.0將集團內部沉澱已久的智慧資料庫診斷優化產品以及集團DBA的資料庫優化經驗整合，以統一視角展示。提供了資料庫資源的診斷與建議、SQL診斷與優化、慢SQL診斷等常用功能。
6. 資料鏈路
OCP 2.0提供了常用的資料備份、恢復、歷史庫等功能。並與ODC、OMS等系統整合，提供了資料匯入匯出、DDL匯入匯出，以及資料全量、增量遷移等功能，可做到在不停機的情況下，將mysql、oracle等主流關聯式資料庫資料匯入OceanBase。
結語
OCP 2.0的架構思路是去依賴、去狀態，以及儘可能縮短服務請求的執行路徑。在滿足高併發、高效能、高可用的基礎上，能夠快速輸出；並且開放了Open-SDK，給了應用參與到OCP外掛開發、快速適配業務變化的能力。
架構是一種平衡的藝術，而最好的架構一旦脫離了它所適應的場景，一切都是空談。OCP 2.0去掉了kafka、jstorm等計算平臺，實時性相對變差了，但是仍然在可接受範圍內，換來的是大幅降低了資源佔用成本以及提升了系統可用性，總體來說，得遠大於失。
加入我們：
OceanBase 現誠聘雲平臺研發專家/架構師、雲產品研發專家/演算法專家，感興趣的同學可以直接傳送簡歷到 OceanBase-Public@list.alibaba-inc.com，我們等的就是你！
