近十年，隨著云計算帶來的變革，傳統(tǒng)的 IOE 架構(gòu)對于企業(yè)運營成本的影響以及對未來業(yè)務發(fā)展的制約逐漸加劇。

[[226338]]

尤其是互聯(lián)網(wǎng)的大規(guī)模、高并發(fā)、實時在線、大型網(wǎng)絡優(yōu)化等新興需求，使得為傳統(tǒng) IT 環(huán)境設計的 Oracle 數(shù)據(jù)庫越來越難以處理互聯(lián)網(wǎng)公司愈加大規(guī)模的數(shù)據(jù)量。

因此，面向超大規(guī)?；ヂ?lián)網(wǎng)公司的分布式計算環(huán)境而重新開發(fā)的關(guān)系型數(shù)據(jù)庫 OceanBase 應運而生。

作為螞蟻金服自研的分布式關(guān)系型數(shù)據(jù)庫，OceanBase 從 2008 年阿里提出“去IOE”想法，到 2017 年螞蟻金服全面實現(xiàn)“去IOE”，經(jīng)歷過許多難以想象的磨礪，也創(chuàng)下了許多影響國內(nèi)外的成就。

本文將深入 OceanBase，回溯其研發(fā)過程與研發(fā)方法論。

研發(fā)故事：軟件、硬件、業(yè)務一體化

以下僅摘選幾個典型案例作為說明：

結(jié)合業(yè)務，整體優(yōu)化軟硬件

螞蟻金服基礎數(shù)據(jù)部（OceanBase 團隊）負責 SQL 相關(guān)方向開發(fā)工作的陳萌萌介紹說，以前數(shù)據(jù)庫技術(shù)更多偏向軟件層，硬件層有專業(yè)人員、專業(yè)技術(shù)和專業(yè)的公司來解決硬件本身的穩(wěn)定性或容災等問題。

但是在螞蟻金服這邊更多是軟硬結(jié)合的方案，OceanBase 軟件從設計之初就考慮了硬件層面不穩(wěn)定、分布式系統(tǒng)的特征，從而去做以前數(shù)據(jù)庫不會做的優(yōu)化工作。

以前的數(shù)據(jù)庫優(yōu)化根本不會考慮到底層的硬件損壞、機器宕掉、網(wǎng)絡斷網(wǎng)、天災人禍不確定性問題，而今天 OceanBase 無時無刻不在考慮這些問題。

“以前做軟件開發(fā)，先假設底層的硬件沒有問題，而只需要把上層軟件邏輯做好就行了，現(xiàn)在我們是整體的軟硬件考慮。”

以數(shù)據(jù)庫的查詢優(yōu)化技術(shù)來講，比如傳統(tǒng)的銀行柜臺，通過人工窗口提供服務，用戶的主要時間花在與人工窗口打交道等方面，對于數(shù)據(jù)庫的快慢體會不那么敏感。

但螞蟻金服是互聯(lián)網(wǎng)應用，數(shù)據(jù)庫隨時的一個抖動或查詢執(zhí)行時間變慢了一點，用戶馬上就能直接感受到。

這與傳統(tǒng)應用場景差異很大，如果數(shù)據(jù)庫的一個查詢從一毫秒變到了五毫秒，傳統(tǒng)數(shù)據(jù)庫不會認為這是件大事。

但是互聯(lián)網(wǎng)應用下，多出來的四毫秒可能被放大成為幾百毫秒甚至一兩秒，一旦出現(xiàn)這樣的時延，用戶體驗馬上就變差了。

“我們每天都在做特別精細的事情，生怕一毫秒變成五毫秒這種事情出現(xiàn)，因此做了很多精確防御。”

螞蟻金服基礎數(shù)據(jù)部（OceanBase 團隊）研究員楊傳輝進一步解釋：數(shù)據(jù)庫查詢優(yōu)化器本身是近似解，基本上不存在最優(yōu)解，優(yōu)化的目標就是逼近最理想的情況。

在傳統(tǒng)應用場景下可以允許優(yōu)化結(jié)果差幾個毫秒甚至更多，但是在互聯(lián)網(wǎng)場景下就很難接受這么大的差異，所有的優(yōu)化效果都要精確到幾個毫秒以內(nèi)。

例如：每一次在支付寶付款，點擊一下付款按鈕，背后的數(shù)據(jù)庫可能要執(zhí)行一兩百次數(shù)據(jù)庫的 SQL 查詢，優(yōu)化器要為每一個查詢生成一個需要做的優(yōu)化執(zhí)行計劃。

如果優(yōu)化器在某一個場景下犯了一個錯誤，每個查詢多出了 5 毫秒，那么整個鏈路就會多 500 毫秒，用戶在按下付款按鈕的時候發(fā)現(xiàn)交互速度有可能變慢了。

如果再加上可能不止做支付——比如買商品后下單再要支付——這幾個鏈路加在一起就有可能慢幾百毫秒甚至上到秒級，這對用戶來說就已經(jīng)不能接受了。

還有地鐵的刷臉或者刷支付寶進站的場景。如果用戶站在閘機前面半天刷不出來，那就不光是體驗問題了，有可能會引來連鎖麻煩，后面人也會被堵起長龍。這些現(xiàn)實的挑戰(zhàn)都要求 OceanBase 反應精確、迅速。

楊傳輝告訴我們，從關(guān)鍵業(yè)務系統(tǒng)的數(shù)據(jù)鏈路梳理上來看，一兩百條 SQL 是最普通的一次交易了，如果涉及到支付渠道不一樣，SQL 執(zhí)行的次數(shù)就會更多。

因為螞蟻金服本身是分布式的系統(tǒng)，所面臨一個很大的挑戰(zhàn)是對底層的基礎組件包括網(wǎng)絡要求非常高。

如果網(wǎng)絡出現(xiàn)了問題，就會對整個服務產(chǎn)生影響。因此 OceanBase 不僅要對數(shù)據(jù)庫層做優(yōu)化，還對網(wǎng)絡、磁盤、操作系統(tǒng)等軟硬件層都要做很精確的優(yōu)化。

那么 OceanBase 是怎么解決的呢？OceanBase 團隊從業(yè)務的開始階段就會介入到業(yè)務的設計當中：業(yè)務怎么用數(shù)據(jù)庫、怎么用最合理等等，從一開始就會參與整體設計，與業(yè)務方和整個架構(gòu)一起演進。

螞蟻金服基礎數(shù)據(jù)部（OceanBase 團隊）SQL 組負責人蔣志勇從事 SQL 引擎和優(yōu)化器工作，為 OceanBase 從無到有地建立了自己的 SQL 引擎，特別是讓原先的 MySQL 應用不改動任何代碼就能遷移過來。

在數(shù)據(jù)庫的兼容性方面，OceanBase 做到了對 MySQL 的兼容，螞蟻金服的內(nèi)部業(yè)務從 MySQL 數(shù)據(jù)庫遷到 OceanBase，不需要任何改動。

在優(yōu)化器方面，涉及到的系統(tǒng)統(tǒng)計信息收集，是與螞蟻金服的業(yè)務體系架構(gòu)結(jié)合起來，設計了一個動靜分離的架構(gòu)：白天把統(tǒng)計信息都存儲到內(nèi)存中，每天到業(yè)務低谷的時候再從內(nèi)存寫到磁盤上。

而不是像其他數(shù)據(jù)庫那樣直接寫到磁盤上，導致收集系統(tǒng)統(tǒng)計信息慢且不全面；也不像內(nèi)存數(shù)據(jù)庫那樣全采用高成本的內(nèi)存來存儲統(tǒng)計信息。

OceanBase 的這種準內(nèi)存數(shù)據(jù)庫設計方式，既滿足了 SQL 查詢需要實時收集更全面系統(tǒng)統(tǒng)計信息的需求，也讓整體的信息收集成本沒有額外開銷。

OceanBase 還在 SQL 語句搜索優(yōu)化方面進行了精細化的調(diào)節(jié)。由于是完全自研的數(shù)據(jù)庫，對于 Join 連接查詢算法可以靈活適配多種算法，而在其他數(shù)據(jù)庫中則由于已經(jīng)限制可選范圍而無法做到更精細的優(yōu)化。

“我們在搜索條件的改寫上面做了巧妙的設計，結(jié)果就是有更廣的可選擇范圍。而其他數(shù)據(jù)庫則只能在一個很窄的范圍內(nèi)選擇最優(yōu)策略，因此 OceanBase 的搜索結(jié)果更優(yōu)。”蔣志勇說。

因為要兼容 MySQL，OceanBase 團隊也精研了 MySQL，對 MySQL 進行了大量調(diào)優(yōu)工作。

在這個過程中，OceanBase 團隊發(fā)現(xiàn)了 MySQL 的幾百個問題，向 MySQL 開源社區(qū)匯報后得到了確認。

諸如 MySQL 對不同路徑執(zhí)行出來的結(jié)果都不一樣、MySQL 的語義不是非常完整等等，都是 OceanBase 團隊在使用 MySQL 中發(fā)現(xiàn)的問題。

特別是由于阿里巴巴和螞蟻金服的業(yè)務規(guī)模日益擴大，經(jīng)常會踩到各種技術(shù)的極限門檻。

OceanBase 團隊就曾經(jīng)在開發(fā) MySQL 接口驅(qū)動程序時，通過業(yè)務排查發(fā)現(xiàn)某個事務已經(jīng)回滾但數(shù)據(jù)還是被提交進入了數(shù)據(jù)庫，導致會出現(xiàn)轉(zhuǎn)賬已經(jīng)取消，但錢還是被轉(zhuǎn)走了的現(xiàn)象。

團隊排查了很久，終于發(fā)現(xiàn)是由于 MySQL 客戶端的一個變量設置本身有問題，但這種問題只有在極限條件下才有可能出現(xiàn)，屬于小概率事件。

而 OceanBase 團隊就是這樣逐一排除小概率事件，最終走向了通用型產(chǎn)品的道路。

通用型產(chǎn)品與場景化產(chǎn)品最大的區(qū)別在于通用型產(chǎn)品能夠適配絕大多數(shù)場景，而場景化產(chǎn)品則只能適配單一的場景。

螞蟻金服基礎數(shù)據(jù)部（OceanBase 團隊）架構(gòu)師馮柯表示，這就是商業(yè)數(shù)據(jù)庫最強的地方——能夠匹配絕大多數(shù)的場景。

也許商業(yè)數(shù)據(jù)庫的技術(shù)不是最強的，但價格那么貴還能有用戶買，就說明商業(yè)數(shù)據(jù)庫的總體擁有成本更低，一個產(chǎn)品就能適配大多數(shù)場景。

而能夠適配絕大多數(shù)場景，就說明已經(jīng)把能踩的坑幾乎都踩過了，今天 OceanBase 也在經(jīng)歷同樣的過程。

Linux 觸 Bug，團隊險解散

OceanBase 踩過的另一個坑，也是在極限情況下才會出現(xiàn)的 Linux 系統(tǒng) Bug。

OceanBase 本身是在 Linux 和 C 語言基礎上開發(fā)的分布式數(shù)據(jù)庫系統(tǒng)。2010 年到 2011 年，OceanBase 團隊在支持淘寶收藏夾業(yè)務。

在 2011 年雙十一的時候，遇到了穩(wěn)定性的問題：當時的 Linux 有一個直接訪問 IO 的特性，這個特性出現(xiàn)了 Bug，而且是在極限條件下才會被觸發(fā)的 Bug。

楊傳輝回憶，當時距離 2014 年雙十一還有不到一個月的時間，是一個周五出現(xiàn)的問題，導致淘寶收藏夾一天之內(nèi)連續(xù)宕機三次、每次一個小時左右，每次宕機后恢復收藏夾的流量。

一旦訪問量超過一定量就又觸發(fā)了 Linux 內(nèi)核的 Bug，導致再次宕機，直到周五晚上 8、9 點后，淘寶訪問用戶變少，才恢復了運轉(zhuǎn)。

由于當時的開發(fā)團隊主要集中在北京，因此第二天周六一早，所有團隊成員搭第一班飛機從北京飛到杭州來解決問題。

“當時的氣氛很緊張，如果這個問題解決不了， OceanBase 團隊當時就會解散。”楊傳輝回憶當時的情況。

而且在解決問題的時候，負責寫代碼的程序員的壓力也很大，后面有兩三個在盯著到底怎么寫代碼。

“當時也并不確定這么做就一定能解決問題，只是覺得有 70%-80% 的概率能解決問題，后來還真解決了這個問題。”

“阿里巴巴/螞蟻金服的系統(tǒng)發(fā)展太快、一直在變，OceanBase 也一直在開發(fā)新功能，又要支持線上業(yè)務，而雙十一的爆發(fā)可能會是平常流量的十倍。像 Linux 內(nèi)核 Bug 這樣的問題，如果只是平常流量的一兩倍，是根本不會觸發(fā)的，它只有在爆發(fā)十倍的時候才會出現(xiàn)。所以我們特別緊張，也沒有時間讓我們仔細去分析、慢吞吞地解決問題。當問題來的時候，所有人加班解決，就是這樣。”楊傳輝說。

在挫折和失敗中成長

馮柯回憶說，他加入 OceanBase 后第一件事是做診斷監(jiān)控，當時沒有人愿意做這件事，因為最主要是要到系統(tǒng)中埋點。

大家都認可這件事很重要，但沒有人愿意去做，因為它涉及到所有模塊，是一件非常吃力不討好的事情。自己當時選擇做的原因，是因為這對業(yè)務來說非常重要，是必須要做的事情。

在此過程中碰到了很多挫折、出了很多問題。例如：OceanBase 診斷監(jiān)控功能剛上線的時候，有 N 個人去看監(jiān)控就會得出 N 種不同的結(jié)論。

“大家覺得這個功能完全不能用，覺得做得很爛，所以當時參加的同學很沮喪，覺得沒有被承認”。

馮柯當時鼓勵團隊，“別人對你批評最多的時候，其實是你進步最快的時候。你的產(chǎn)品能夠獲得更多資源，能夠被更多的人認識到，這其實是非常好的。那個時候的觸動確實很大。”

OceanBase 是一個一邊在業(yè)務中“討生活”，一邊尋找機會發(fā)展壯大自己的過程。在“討生活”的過程中，OceanBase 也會不得以做出妥協(xié)。

楊傳輝回憶 2010 年的 OceanBase 版本有一個比較大的缺陷，就是設計了單點寫入。

當時所有寫入數(shù)據(jù)全都放在一臺機器上，這個版本可擴展能力比較差，本質(zhì)上只能做垂直擴展而沒有辦法做水平擴展。

另外，因為每個寫入都要經(jīng)過那個節(jié)點，最后整個性能也相對更差，數(shù)據(jù)庫的功能也受限。

這是 OceanBase 早期的版本，當時團隊的數(shù)據(jù)庫經(jīng)驗沒有那么豐富，也沒有時間做長期的開發(fā)。

直到 2015 年重新設計開發(fā)的 1.0 版本才是真正面向云時代的分布式數(shù)據(jù)庫。

這個期間，OceanBase 團隊也從各個渠道引進數(shù)據(jù)庫人才，最終實現(xiàn)了數(shù)據(jù)庫的重構(gòu)。

OceanBase 經(jīng)歷的失敗還有很多。楊傳輝回憶，OceanBase 在 2012 年 11 月份轉(zhuǎn)到螞蟻金服到 2014 年實現(xiàn)了交易系統(tǒng)，這之間的 2013 年其實在從事淘寶的庫存項目而不是交易系統(tǒng)。

當時，OceanBase 團隊看到庫存的數(shù)據(jù)庫問題也是一大挑戰(zhàn)，這就像賣火車票系統(tǒng)的挑戰(zhàn)本質(zhì)上也是減庫存問題——如果有兩人同時并發(fā)減庫存，就會亂掉。

當時淘寶的 MySQL 團隊也在做這個事情，最終業(yè)務部門選擇了 MySQL 的方案，就是因為業(yè)務團隊當時覺得用 MySQL 更放心。

“就這一個原因，也沒有其他的點，最后沒有選擇 OceanBase，我們相當于那一年白干，整個團隊白干。但因為這個鋪墊，我們下一個交易系統(tǒng)真的做成了。”

研發(fā)方法論：發(fā)現(xiàn)問題、定義問題、解決問題

總結(jié) OceanBase 的開發(fā)過程，總會試圖尋找一些研發(fā)方法論，就像微軟的軟件開發(fā)“三駕馬車”那樣的方法論。但我們其實更多的時候是與運維、業(yè)務團隊等一起在定義問題。

我們會看到一些問題、找到真正要解決的問題是什么，然后幫助用戶定義這個問題。

在定義問題時，有時候我們會開一個會，分析某問題是由數(shù)據(jù)庫團隊解決、還是由業(yè)務團隊解決，而在開會之前可能大家都不知道最后要達到什么樣的效果。很多時候我們在做這些不確定的事情。

OceanBase 本身就是一個沒有先例可參考的分布式數(shù)據(jù)庫。團隊的主干成員陽振坤此前在百度帶領(lǐng)分布式技術(shù)團隊時積累了豐富經(jīng)驗，也從谷歌吸收了很多分布式技術(shù)的思想。

但當后來試圖把分布式架構(gòu)與關(guān)系型數(shù)據(jù)庫結(jié)合在一起的時候，就再也沒有先人的經(jīng)驗，而只能靠團隊自己琢磨。

雖然 OceanBase 到目前為止還沒有發(fā)表過論文、還是在做業(yè)務，但楊傳輝回憶 OceanBase 中有很多是別人沒有想過的方法，可能做一個新的方案要想好久，要思考半年到一年后再決定去做。

在具體開發(fā)的執(zhí)行過程中，測試是很重要的工作。分布式系統(tǒng)的異常處理很容易出錯，平常機器不出故障，到上線業(yè)務突然出一個故障時，可能就是一個大故障，而這種異常處理的測試比較難。

OceanBase 有容災模擬框架，就是隨時把一臺機器殺死，而這樣的容災測試隨時在運行。

另外，對于并發(fā)處理的測試，即某個條件的達成可能突然觸發(fā)兩個線程的先后順序或一個變量的訪問順序出錯。OceanBase 也是隨時在模擬這樣的場景，讓這樣的小概率事件盡早出現(xiàn)。

在開發(fā)的過程中，OceanBase 通常是一個人寫出來的代碼，要另外一個人去讀和審查，通過的代碼才會提交。

團隊還寫了很多自動測試用的框架，開發(fā)人員要自己做單元測試和一部分的功能測試，集成測試則由專門的人來完成。OceanBase 的測試人員很少只有幾個人，大部分的測試都是靠自動化完成。

因為 OceanBase 是軟件、硬件和業(yè)務集成在一起的整體優(yōu)化，而當軟件、硬件和業(yè)務碰到一起的時候，經(jīng)常會出現(xiàn)各種碎片化的小場景問題，那么又是怎么解決的呢？

陳萌萌介紹說，當遇到這樣的場景時，就會提前把大家拉到一個群里，把需求丟到群中，技術(shù)團隊根據(jù)需求提供反饋建議，業(yè)務團隊也會反饋在試驗中遇到的問題。

這些碎片化的場景和問題，很難區(qū)分到是軟件、硬件還是業(yè)務的問題，因此群里有運維、開發(fā)、業(yè)務甚至還有負責業(yè)務拓展的 BD 和負責產(chǎn)品的 PD，只要需要關(guān)注的人員都可以進到群里。

每個人有負責的業(yè)務或技術(shù)方向，空閑的時間就會把群里的來龍去脈都過一遍。

有些群是按需找人，在群里被 @ 了就肯定會關(guān)注這些消息，如果沒有被 @，就會找不是特別緊急時候再把群里的消息過一遍。

雖然群很多，但是真正過群消息的時候，幾分鐘時間還是能夠把過去幾天的消息都過一遍。這樣總是能區(qū)分哪些是需要第一時間響應的，哪些可以后續(xù)持續(xù)關(guān)注的。

一般 OceanBase 團隊的工作時間是早 9 點到晚 9 點 12 個小時，但也有大促的“雙十一”、“6.18”、春節(jié)紅包壓測等緊急情況。

當然，隨著 OceanBase 的發(fā)展，需要處理緊急事件的情況在減少。陳萌萌回憶，以前跟著業(yè)務團隊壓測到凌晨，甚至說半夜被揪起來的情況，會經(jīng)常發(fā)生。

“我記得經(jīng)歷過很多故障都挺戲劇化的。因為一旦出現(xiàn)一些問題以后，各方面的人都會被半夜拉起來，大家臨時被拉到一個群里面，誰也不知道當時發(fā)生了什么。但是每個人可能有一部分的信息，大家很快把各自的信息扔到群里面，這樣就對出來到底發(fā)生了什么。每個人都有點膽戰(zhàn)心驚，生怕自己做的那部分導致了什么問題。”

陳萌萌回憶說：“我記得有一次故障，半夜 11 點說有一個問題需要大家上線去看，一幫人包括主管都上線看問題，一直到凌晨四五點。一開始大家都在，慢慢發(fā)現(xiàn)問題越來越聚焦，相關(guān)的人員就上來，一直到凌晨四五點才解決問題。中間大家在群里面各種排查信息分析，提出各種建議，雖然沒有坐在一起，但就像關(guān)在一個屋子里面開了連夜的戰(zhàn)斗會一樣。”

陳萌萌總結(jié)了阿里這種獨特的技術(shù)討論群解決問題的過程：“這是一個不停過濾信息再分析的過程。如果一開始不掌握所有信息，誰也總結(jié)不了。對完信息后，有人發(fā)現(xiàn)說某個地方需要關(guān)注，別的人再把相關(guān)信息加過來，慢慢連成一個邏輯。當你回頭再看群里消息的時候，這個現(xiàn)象特別明顯。信息一開始是散的，然后慢慢才能達成一致，最后走下去。”

當然，群里也會有熟悉各種“疑難雜癥”的“老中醫(yī)”，一般是經(jīng)驗比較豐富的人員，見到的問題也比較多。

所以別人可能還在猜測的時候，“老中醫(yī)”就會給一個很靠譜的可能性，沿著這個可能性去看的話，發(fā)現(xiàn)確實可以通過這個角度去挖掘解決問題的方案。

然而，即使討論出了可能的解決方案，“大家還是挺膽戰(zhàn)心驚的，敲命令都是讓專門負責運維的人員去敲，這個時候的關(guān)鍵在于手不抖、別敲錯，因為萬一敲錯了那就是二次故障。所以我們都會找一個心理素質(zhì)好的同事操作，大家誰也不要吱聲，看著這個同事安靜地把命令敲完。”

因為不管通過群里的討論，選擇一條最保險最靠譜的操作方式，但在系統(tǒng)里面直接敲命令都有可能直接動數(shù)據(jù)，敲錯一個鍵就有可能把所有數(shù)據(jù)都刪了，這是沒法挽回的，“所有人在操作的時候都不敢出氣”。

當然，每次處理完故障后，也會復盤找到以后的解決方案，最后形成知識庫也就是應急預案再固化到程序里，通過程序防止下一個錯誤。

整個 OceanBase 并沒有一個統(tǒng)一的產(chǎn)品經(jīng)理，因為 OceanBase 的功能列表是對標商業(yè)數(shù)據(jù)庫。

但還是會有產(chǎn)品開發(fā)的規(guī)劃，通常以財年為單位、雙十一為重要節(jié)點，比如某個版本必須要在下一個雙十一之前做出來并且穩(wěn)定運行，再通過雙十一檢驗。“保持這樣一個節(jié)奏”，蔣志勇補充。

未來展望：用時間歷練、用現(xiàn)實考驗

蔣志勇強調(diào)，數(shù)據(jù)庫產(chǎn)品化需要時間去歷練，如果抱著投機的心態(tài)參與就很難實現(xiàn)。

螞蟻金服最大的優(yōu)勢是業(yè)務場景非常豐富，讓 OceanBase 在服務外部客戶之前，就在內(nèi)部得到充分鍛煉，而這些鍛煉很難通過外部用戶去獲得。

從 2017 年開始，OceanBase 跟隨整個螞蟻金服的金融科技開放，開始了向傳統(tǒng)金融賦能的實踐過程。

負責 OceanBase 外部業(yè)務的馮柯表示：“分布式是 OceanBase 的亮點，但最重要的是 OceanBase 是按照產(chǎn)品的思維而不是單純解決業(yè)務的問題，未來肯定是要到外部發(fā)展。”

如今，OceanBase 已從金融級分布式關(guān)系數(shù)據(jù)庫服務為起點，邁出了商用的一小步。

承受住時間的歷練和現(xiàn)實的考驗后，團隊有信心將 OceanBase 從一個軟件變成一款通用產(chǎn)品。

作者：吳寧川

簡介：“云科技時代”創(chuàng)始人。職業(yè)生涯起步于《中國計算機報》，曾任副主編一職。采訪過 Oracle 全球 CEO、VMWare 全球 CEO、ARM 全球 CEO、亞馬遜云全球 CTO、微軟全球研究院院長、華為 CIO、京東 CTO、IBM 大中華區(qū)董事長、阿里云 CEO等高管。