摘要：本文重點分享了在雙11背景下，OceanBase雲平臺所遇到的挑戰，介紹了針對實時監控和規模運維兩個方面雲平臺所提供的應對策略，並詳細解釋了需要做哪些設計纔可以解決這些挑戰？本文從開發者視角，帶大家瞭解構建大規模分佈式系統要關注的事情。
演講嘉賓簡介：
張松樹（花名：笑言）：現任螞蟻金服 OceanBase 團隊技術專家，2014 年加入阿里巴巴，曾是阿里雲 GTS 產品 Founder，從事領域涉及分佈式事務、中間件高可用，致力於分佈式系統穩定性的建設工作，目前主要負責 OceanBase 雲平臺的建設。
本次直播視頻精彩回顧，戳這裏！https://tech.antfin.com/activities/41/review/54
以下內容根據演講嘉賓視頻分享以及PPT整理而成。
https://tech.antfin.com/activities/41/review
本次的分享主要圍繞以下四個方面：
一、雙11帶來的挑戰
二、實時監控技術點剖析
三、極致運維技術點剖析
四、OceanBase雲平臺
一、雙11帶來的挑戰
剛剛過去的2018年雙11是阿里雙11的第十個年頭。從2009年開始，當時一天的營業額還不到1個億，但是到了2012年，營業額就已經增長到了191億。在這三年當中，除了逐年成倍增長的銷售數字，另外比較重要的事情就是OceanBase誕生了。2014年，OceanBase開始應用於支付寶的核心交易系統，當時OceanBase的版本是0.5版本，一個開源版本，大家最開始瞭解OceanBase就是從0.5版本開始的。到了2015年，將近1000億的日營收，螞蟻交易支付鏈路百分之百的流量都已經切到OceanBase上了。2016年雙11，支付寶的每秒支付峯值創造了12萬筆/秒的世界記錄。全世界比較大的交易系統有Visa和Master。Visa的支付峯值大概是5萬筆/秒，Master比Visa略少一些，所以12萬筆/秒是非常有紀念意義的。2017年雙11，誕生了數據庫處理峯值4200萬/秒世界紀錄，2018年，OceanBase在存儲成本以及性能方面有了重大突破。
下面的漫畫生動地描繪了雙11前阿里技術人員的工作狀態。在雙11將要開始的一段時間，對於技術人員心臟的挑戰是非常大的。普遍來說，每年雙11從零點時刻開始，交易曲線會在很短的時間內衝到峯值，在峯值處很平穩的運行10分鐘左右，然後再掉下來。大家可以思考一下，爲什麼會存在那段10分鐘左右的平穩期？這是因爲系統容量不足以承載瞬時流入的海量請求，這時系統會採取一些自我保護手段來保證系統不被壓垮，這也是分佈式高可用的一些特徵，做互聯網應用的人會比較熟悉這一點。這些策略包括限流、預付、當天無法退貨等，這是都是爲了保證系統的高可用而採取的措施。但是沒有用戶請求被限流，纔是最理想的購物體驗，這要求我們的技術人員需要通過技術手段來不斷提升用戶的購物體驗。
雙11具體會給OceanBase帶來什麼挑戰呢？
首先看系統高可用，簡單來說，高可用就是能夠時時刻刻提供一個持續穩定的服務。如果只有幾百幾千人使用系統，高可用是很容易實現的。但是對於數十億用戶同時併發請求的情況，如何維持如此大規模分佈式系統的高可用是一個非常挑戰技術深度的事情。來看OceanBase，目前OceanBase有數萬個的服務節點，這些服務節點分佈在阿里巴巴不同的數據中心。服務器部署在不同的地域會衍生出一系列問題，比如不同地域之間存在網絡延遲，北京到上海，大概有30-50毫秒的延遲。那麼我們的數據庫需要儘可能的保證事務操作不跨地域，以保證數據庫服務穩定。
還有實時計算和監控能力的問題，前面所提到的，4200萬條SQL在同一秒產生，每條SQL背後有大量、多維度的監控數據，監控信息散落到分佈式系統中，要給不同業務視角的同學提供滿足業務需求的數據，需要把這些散落在數萬個服務節點上數據快速發現、聚合、實時計算並且展示出來。這也是極具挑戰的。
另外，怎麼能做到全方位的安全？數據安全是系統的底線，無論是數據庫服務，還是數據庫平臺都會將數據安全作爲系統建設的基本原則。
還有，如何做到極低的資源佔用？在做分佈式系統時，需要考慮資源問題。由於幾萬臺服務器本身的成本是非常龐大的數字，我們的用戶在進行技術選型的時候，成本是很重要的考慮因素，所以將系統資源發揮到它的極限對於工程師來說是極具挑戰的。
最後一個挑戰是系統要做到可定製可擴展。做業務系統時所能提供的功能非常有限，無法預設到百分之百，也不可能匹配到所有用戶的需求，只能儘可能的把系統做到用戶可自定義，站在用戶的視角來，把他們的問題解決掉。對於OceanBase來說，可定製可擴展是非常重要的問題，它需要給每一個用戶提供專屬的數據庫操作體驗，用戶可以通過接口或者服務，通過數據庫雲平臺做一些定製化的操作。
二、實時監控技術點剖析
一條SQL的一生
一個數據庫能夠正確的執行SQL是最基本的功能。而對於OCP來說，這只是開始。分佈式系統與單機系統最大的區別是分佈式系統由多個服務器組成，那麼數據究竟在哪個服務器節點上？一條SQL由哪臺服務器承擔執行任務？如果發生了問題，應該到哪一臺機器說查找數據，並解決問題？這些都是OCP關注的問題。OCP對租戶級和會話級的監控數據進行採集，包括監控項，等待事件和鎖事件。採集完之後對採集的數據從不同的視角進行聚合，給不同的業務人員提供滿足他們視角的視圖。之後對數據進行分析，包括分析SQL性能，執行路徑等等，給用戶提供實際的建議。根據預設規則或者自定義規則，實時告警。這些流程是整個分佈式系統能夠提供更好更穩定服務的必備環節。
實時監控-海量數據處理
下圖左邊是蜂窩狀的數據庫服務器，它會分佈在全國各地多個機房內。那麼該如何集中化處理這些數據？最簡單的方法是把他們採集到集中式的數據庫裏面，但隨之而來的問題就是不同地方的數據所經歷的延時不一樣。數據採集到數據庫裏面後，對於這些不是同一個時間段的數據如何提供統一的視圖？數據進行集中處理後，要做相應的加工，如果加工的鏈路足夠的長，足夠的耗時，那麼數據實時性就會遇到問題。而且對於數據所給出的建議功效也會大打折扣。所以需要採用高質量的算法和並行計算的策略解決這個問題。同樣，通過聚合的鏈路把數據進行分類，如建議事件，警告事件，普通事件等。採用不同事件處理流程解決不同的數據。
實時監控-監控信息
每一條SQL都會產生N個監控項，比如，4200萬條SQL背後的數據量是N*4200萬監控信息。在這種量級下，分佈式系統的開發人員重點關注哪些問題？如下圖，在系統級別下包括集羣，實例，主機，事務，IO，鎖和臨界區等指標。在SQL級別下由延時，返回行，CPU時間佔用，邏輯讀行數，物理讀的行數，內部等待和外部等待花費的時間等。如此多的數據就僅僅只是一條SQL下來所產生的數據。
作爲分佈式系統的構建者，面對如此多的數據，該採用什麼存儲方式？通常來說，主要有兩種存儲模型，一種是窄表模型，另一種是寬表模型。對於窄表來說，一行信息裏面有兩個或三個字段，一條信息所包含的屬性比較少。寬表則相反，一行裏有比較多的屬性，少則幾十個，多則上百個。窄表典型的代表是HBase，寬表就是MySQL。他們的問題和優缺點也是顯而易見的。
比如說要統計一臺機器在某一個時間點的所有的信息，要在程序裏實現，在窄表模型下想要對這些信息做擴展，開發者說需要改代碼，而這種操作對於分佈式系統構建者是非常不友好的事情。最理想的是通過一條SQL或修者改一個列就可以做到信息擴展，所以寬表模型對於維護成本相對較低。
但是在另外的問題上，寬表模型的擴展性並沒有那麼好，比如想要加一個屬性，可能還需要考慮加到哪張表，字段需要什麼描述方式。這時窄表就具備擴展性的優勢。在表結構變更時，比如1個TB數據的表，加一個字段是很難想像的。
OceanBase是一款準內存數據庫，中間數據保存在內存中，週期性和基線數據做合併，因此DDL不會產生鎖表問題；OceanBase採用了高效的壓縮算法，儘可能的很好的解決了經濟性的問題。同時，使用OceanBase不需要額外部署資源，對於提升構建系統的效率無疑是重大利好。
三、極致運維技術點剖析
近幾年分佈式系統發展特別快，包括阿里、AWS都已經有了成熟的全鏈路監控跟蹤系統，OCP也一樣。
每一條SQL或者事務都會有個全局唯一的Transaction ID，可以幫助DBA和運維人員根據Transaction ID到數據庫的服務器中抓日誌、查問題；DBA和運維人員還利用OCP上提供的一系列服務做運維相關的工作，包括集羣管理、計算邏輯編排、流程控制等。OCP對每一次的操作都會有一個全局的Request ID來全鏈路跟蹤該操作所經過的每一個環節；Transaction ID表現在數據庫層面，Request ID表現在平臺服務層面，作爲開發者，能夠結合業務，做完整業務的全鏈路是我們下一步要關心的事情。
數據庫的使用者比較關心的是數據庫的增刪改查，而對於OCP實現者來說，還需要對數據庫進行監控、運維、調度，提供數據服務、數據管理、數據庫診斷等。OCP提供了Open-SDK的方式，讓每個人都可以根據自己的需求以及喜好來定製自己的數據庫。
四、OceanBase雲平臺
下面看看Oracle雲是怎麼做的。最底層，Oracle數據庫服務跑在雲主機上，有可能是公有云（如阿里雲，AWS、騰訊雲）；可能是專有云，大型的企業用戶可能會自建機房，將數據庫服務部署在自建機房裏；也可能是混合雲，將自建機房和公有云做打通，數據在專有云裏面，然後管控和服務在公有云上。中間層，Oracle會把數據管理，應用集成等基礎的能力包裝成服務發佈給開發者。最上層，將會有不同的業務視角提供給不同角色。
下圖是阿里內部的OCP的構建模式。底層是由物理機，ECS，Docker等組成的基礎設施層;上面是OceanBase數據庫；OceanBase之上構建了OCP平臺以及各類平臺服務。OCP從功能上來說包括監控、運維、診斷、資源調度等基礎應用，另外還有數據遷移、備份恢復、歷史庫等數據管理類應用。服務之上，構建了Open-SDK，將服務能力通過SDK的方式發佈出去，SDK能夠幫助大家跟自己的業務系統做結合。最上面提供了不同的業務視角，比如開發人員會關心一個數據庫實例的狀態，用戶DBA會關注自己的集羣運行狀態，系統的DBA要從更宏觀的層面關心所有系統之間負載是否均衡，穩定性是否好。
現狀
下圖是目前OceanBase雲平臺所應用的場景，客戶包括螞蟻金服，網商銀行，南京銀行，浙商銀行等等。右邊是阿里巴巴內部應用的場景，OceanBase在集團內得到了廣泛的應用。OceanBase是經過了8年的驗證磨練出來的成熟的產品。然而云平臺成長的時間並不長，還處於初級的階段。我們的初級目標是系統變得更穩定，功能更友好。對比Oracle，內核研發人員是幾千人，但是Oracle公司其實有幾萬人。他們有大量的人都投入到了工具，平臺，致力於怎能讓數據庫從使用的感知更友好，這是我們OceanBase雲平臺所關注的事情。
點擊閱讀更多，查看更多詳情