一文詳解新一代OceanBase雲平臺

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、場景的變化

1. 基礎設施的變化

阿里集團基礎設施包括了若干自建獨立機房，機房之間經過高帶寬低延時高效骨幹網絡相鏈接，即便跨城的機房之間網絡傳輸丟包率也很低。

構建於高質量基礎設施之上的開源組件，好比zookeeper，可靠性很高。然而，對於大多數企業級客戶，有些是租用第三方機房，有些不具有三機房條件，基礎網絡的可靠性也不高，延時不穩定，開源產品運行故障率很高，OCP的SLA沒法獲得保證。

2. 業務的變化

衆所周知，阿里雙十一所面臨的高併發場景是極端的，須要投入大量的基礎設施資源、人力資源來保障系統的穩定運行。而外部業務因爲其差別性，每每對基礎設施的投入成本比較敏感。OCP的近十個組件的部署成本很高。

阿里集團因爲其業務須要，好比HBase、JStorm等主流的開源產品都有專門的團隊維護，專業的技術力量爲OCP系統提供了強大的後背。而後，在外部輸出的時候，OCP系統顯得孤立無援。

綜上兩點，若干開源組件依賴，對OCP的可靠性帶來了挑戰，也引入了較高的部署成本。

2、OCP 2.0的誕生

OCP做爲直接面嚮應用開發者的在線系統，同時承擔了超大規模OceanBase集羣的監控和運維工做。在對接企業級業務系統的場景下，至少須要具有如下能力：

• 對於在線系統，須要提供持續且穩定的高可用服務
• 對成本敏感的企業用戶，要求OCP在佔用少許機器資源的同時，提供高併發訪問
• 儘量少的運維人員投入，要求系統可以實現無人值守
• 提供可定製、可擴展的產品能力，可在線升級

綜上，OCP 2.0在架構設計上，進行了完全的自我革命，徹底拋棄了1.0時代對若干開源組件的依賴，OCP層面堅持去中心化的設計理念，將全部的狀態信息集中到OceanBase數據庫。

所以，帶來的最直接的收益就是極大的縮短了服務鏈路，在架構層面保證了系統的運行質量，同時，去掉了開源軟件的部署成本。

3、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，咱們等的就是你！