無論多么有主見的架構(gòu)師，在做數(shù)據(jù)庫選型的時候，也可能會犯難。

傳統(tǒng) SOL、NoSQL 還是 NewSQL？架構(gòu)風格是以 久經(jīng)考驗的關(guān)系型數(shù)據(jù)庫為主，還是偏向所謂原生的分布式架構(gòu)？如果提及具體產(chǎn)品，那選擇就更多了，TiDB、OceanBase、PolarDB、TDSQL、GaussDB、MongoDB…… 現(xiàn)在還有許多服務于新場景的產(chǎn)品，比如處理時序數(shù)據(jù)的 TDengine，處理圖數(shù)據(jù)的 Nebula Graph……以及最老派又最完善的 Oracle。

如果從業(yè)務場景或即將面臨的遷移成本來看，問題會更加復雜。牽扯到底層數(shù)據(jù)的選型和架構(gòu)設計，有時更像一錘子買賣，一旦定了某種方案，再想替換代價可不是一般的大。

差不多在 10 年前，這事兒還沒有那么棘手。Oracle、IBM Db2，二選一而已。但今時不同往日，這是一個數(shù)據(jù)量急速膨脹、業(yè)務高度復雜的時代，真正讓人焦慮的不是單純的選型問題，而是將“降本提效”推向極致的數(shù)字化轉(zhuǎn)型問題。

那么，除了咬牙硬選一個數(shù)據(jù)庫，或者基于現(xiàn)有數(shù)據(jù)庫的基礎上自研一套存儲方案，真的沒有其他路可走了嗎？其實也有，只不過在分布式數(shù)據(jù)庫熱度越來越高的當下，顯得有些“透明”，那就是中間件 多商業(yè)數(shù)據(jù)庫的解決方案。

看到這個答案，你可能會有些失望。中間件方案出現(xiàn)的時間，尚在分布式數(shù)據(jù)庫成熟之前。因此在業(yè)內(nèi)很多架構(gòu)師看來，這種方案在技術(shù)上不夠超前，只能算是某種“過渡策略”，本質(zhì)上是 NewSQL 數(shù)據(jù)庫成熟前的無奈之舉。

但來自金融等行業(yè)的諸多落地實踐證明，事實可能并非如此。

我們?yōu)榇颂貏e采訪了 全球頂級開源項目、數(shù)據(jù)庫中間件產(chǎn)品 Apache ShardingSphere 的作者，以及背后商業(yè)公司 SphereEx 的 CEO 張亮，他一直對分布式架構(gòu)設計保持關(guān)注，曾是京東科技架構(gòu)專家、當當架構(gòu)部總監(jiān)。關(guān)于整個數(shù)據(jù)庫行業(yè)的選型和架構(gòu)設計問題，張亮有著特別的思考。

可插拔架構(gòu)，或許是答案

“需求是多元化的，一部分用戶適合分布式數(shù)據(jù)庫，一部分用戶適合用數(shù)據(jù)庫中間件，甚至還有一部分適合兩種都用，沒有太絕對的答案”，張亮說。

這是個無錯的答案，但也可以得出一個推論：如果場景是多元化的，數(shù)據(jù)庫是多元化的，那么架構(gòu)師應該盡量規(guī)避擴展性、兼容性不好的數(shù)據(jù)庫解決方案。

無獨有偶，Oracle ACE、數(shù)據(jù)庫專家韓鋒也在其個人公眾號里發(fā)表過類似的觀點：“（關(guān)于數(shù)據(jù)庫選型）為了規(guī)避路線選擇、廠商綁定的風險，比較現(xiàn)實的方法是選擇一款兼容通用性協(xié)議的產(chǎn)品，并且在應用中僅使用標準數(shù)據(jù)庫的用法?！?/span>

二者結(jié)合起來，我們能抽離出一些關(guān)鍵詞：中立、兼容、標準，對于很多在選型問題上難以抉擇的架構(gòu)師來說，這讓中間件路線看起來更加實際。

與數(shù)據(jù)庫行業(yè)不同，以 ShardingSphere 為代表的中間件層由于不涉及存儲引擎，如今已將目光從單純的水平擴展問題轉(zhuǎn)向業(yè)務支持和靈活性問題，也因此得以實現(xiàn)對異構(gòu)數(shù)據(jù)庫的統(tǒng)一管理。

靈活性、兼容性，是數(shù)據(jù)庫中間件產(chǎn)品的核心，也是解決“數(shù)據(jù)庫選型”問題的關(guān)鍵。據(jù)張亮透露，近兩年的主要研發(fā)重點一直是可插拔架構(gòu)，以將靈活性和兼容性推向極致。好消息是，ShardingSphere 的可插拔架構(gòu)預計將在未來一段時間內(nèi)正式上線。

所謂的可插拔架構(gòu)，是指在架構(gòu)層面，將整個系統(tǒng)分為基座和插件兩部分，插件部分互相隔離、互不影響，基座可以自由接入多個插件。可插拔架構(gòu)多見于相對輕量級的前端領域，屬于微前端體系的一部分，但在基礎軟件部分則相當少見。

張亮認為，可插拔架構(gòu)形式是未來數(shù)據(jù)庫中間件的主要趨勢之一，一則產(chǎn)品需要高度的靈活性，二則還有大量的能力需要被構(gòu)建，比如數(shù)據(jù)安全、異構(gòu)數(shù)據(jù)網(wǎng)關(guān)等功能，可插拔架構(gòu)自然成為了產(chǎn)品核心。

話雖如此，但可插拔架構(gòu)的設計難度卻很大，讓人望而生畏。這種設計難度，大致分可為兩部分來談：

第一，可插拔架構(gòu)是對 OCP（Open-Closed Principle）原則的一次徹底執(zhí)行，力圖僅通過增加新模塊來滿足新需求，舊有模塊完全保持 0 修改。這意味著，可插拔架構(gòu)要清晰地定義出，什么是基座，什么是插件。它對上層、下層都無感知，一切面向接口。用張亮的話說，就是：“完全面向一個抽象的、虛無的東西，不涉及任何的業(yè)務細節(jié)”。

比如，ShardingSphere 轉(zhuǎn)向可插拔架構(gòu)后，其核心流程里已經(jīng)沒有分片功能了，分片會作為可插拔能力的一部分接入到服務中。對于數(shù)據(jù)庫中間件來說，幾乎屬于產(chǎn)品重定義。與許多人對數(shù)據(jù)庫中間件的固有認知相悖，因為在許多人的理解中，數(shù)據(jù)庫中間件不就是為了分庫分表而存在的嗎？

但實際情況是，單體數(shù)據(jù)庫的覆蓋場景依然很多，分庫分表并不是 0 級功能。這是在架構(gòu)層面，必須具備的關(guān)鍵洞察。

第二，與微服務相似，只要涉及服務拆分，就會涉及顆粒度問題。對于可插拔架構(gòu)來說，需要插件化的不一定只是產(chǎn)品功能，比如兩階段強一致事務和柔性事務，也是能夠?qū)崿F(xiàn)可插拔的。

基于這些拆分問題，ShardingSphere 把可插拔架構(gòu)分為三層，分別是內(nèi)核層、功能層、生態(tài)層，分別面向數(shù)據(jù)庫內(nèi)核、企業(yè)功能、數(shù)據(jù)庫生態(tài)進行可插拔設計。其中，查詢優(yōu)化器、分布式事務引擎、調(diào)度引擎等是內(nèi)核層的可插拔模塊；數(shù)據(jù)分片、讀寫分離、數(shù)據(jù)庫高可用、數(shù)據(jù)加密、影子庫都是功能層的可插拔模塊；數(shù)據(jù)庫協(xié)議、SQL 方言等則是生態(tài)層的可插拔模塊。

要實現(xiàn)可插拔架構(gòu)，除了設計難度和顆粒度拆分，其工作量也令人嘆為觀止。ShardingSphere 有 190 多個模塊，近 43 萬行代碼，核心 Java 代碼 29 萬行，張亮回憶道：“為了做可插拔架構(gòu)，老代碼留了不到 1/10?！边@意味著，有近 26 萬行的核心代碼被重寫了。

可插拔架構(gòu)是 ShardingSphere 追求靈活性最重要的標志之一，但它對靈活性的追求又不僅限于可插拔架構(gòu)。

比如，ShardingSphere 還額外提供了兩種部署形態(tài)，分別為 JDBC 和 Proxy。JDBC 是 Java 訪問數(shù)據(jù)庫的標準接口，Proxy 是中間件最常見的服務形式，且兩者經(jīng)常能夠在同一環(huán)境下進行混用，以滿足多用戶下多類型訪問的需求。

這樣多種類型的服務接口，一方面服務了不同類型的開發(fā)人員，另一方面也實現(xiàn)了性能層面的可定制化，工程師可以結(jié)合場景調(diào)整數(shù)據(jù)庫分片的鍵值，實現(xiàn)不同場景下，性能的最大化提升；反之，“全包式”數(shù)據(jù)庫方案，則往往需要放棄部分靈活性，以相對中庸的方案來換取無感知、低侵入的使用體驗，體現(xiàn)了與數(shù)據(jù)庫中間件方案的差異性。

真正的開源項目，是社區(qū)說了算

如果我們要做技術(shù)選型，需要注意的另外一點是，備選產(chǎn)品的維護主體是誰，備選產(chǎn)品的基因是什么，是開源，還是閉源？這與搞清楚產(chǎn)品的技術(shù)方案、技術(shù)理念同樣重要。

當下，無論開源的熱度如何，大部分分布式中間件、分布式存儲、數(shù)據(jù)庫都是閉源的，這是不爭的事實。

看到的是，大量的開源創(chuàng)業(yè)公司正在出現(xiàn)，資本也在快速進入，比如 SphereEx、歐若數(shù)網(wǎng)、Neo4j，以及大家熟知的 PingCAP。同時也有許多數(shù)據(jù)庫宣布開放源代碼，比如 OceanBase、Tendis、openGauss。

為什么在數(shù)據(jù)存儲領域，開源這么引人關(guān)注？

一個可能的答案是，開源在技術(shù)層面的想象空間更大，對開發(fā)者更友好。就像 ShardingSphere 的可插拔架構(gòu)，架構(gòu)設計完成只是第一步，后續(xù)還有海量的不同模塊的開發(fā)工作。對于創(chuàng)業(yè)公司來說，如果不借助社區(qū)的力量，美好的可插拔架構(gòu)也可能成為公司的研發(fā)黑洞。

產(chǎn)品的中立性，也是導致開源項目集中迎來爆發(fā)的另一個要素。尤其是在數(shù)據(jù)存儲領域，最美好的答案可能是無依賴、跨多云，最差的答案才是被單一產(chǎn)品強綁定。

當然，開源再好，也抵不過現(xiàn)實的骨感。開源兩年，Star 幾百，花錢不少，效果為零，這恐怕是眾多開源項目的常態(tài)。社區(qū)的健康程度，往往直接定義了開源項目的生死，這導致即便架構(gòu)師想做選型，也沒有太多的好選擇。

在張亮看來，一個開源項目能不能成功，大致可以分為三個維度來考察：

第一，能否耐的住寂寞，團隊是真的相信開源，還是拿開源當做商業(yè)上的捷徑。一個最簡單的考核指標便是運營時間，“開源項目一定要度過‘靜默期’才會迎來爆發(fā)，只做了半年、一年，是沒法預估項目未來的”，張亮說。

第二，一些必備的運營技巧。張亮一方面把 ShardingSphere 捐獻給 Apache 基金會，另一方面也帶著項目參與了許多活動，比如谷歌舉辦的黑客馬拉松、編程夏令營，除國內(nèi)用戶以外，也吸引了大批的海外開發(fā)者、學生參與到社區(qū)建設中來。

第三，觀念的轉(zhuǎn)變，也是最關(guān)鍵的部分。從小處著眼，是從“自己開發(fā)”到“社區(qū)開發(fā)”；從大處著眼，就是在真正意義上擁抱開源，而不只是嘴上說說。

“ShardingSphere 的項目發(fā)展是受社區(qū)的引導。比如說，社區(qū)認為 ShardingSphere 該做基于影子庫的壓測和可觀察性，ShardingSphere 就真的做了。這些都不是項目自上而下的設計，只要需求爆發(fā)，且在項目的 Scope 內(nèi)，就可以實現(xiàn)。但如果一個公司在運營開源項目時，遇見所謂的偏離主線設計的社區(qū)訴求，就拒掉它，那么大概率也會影響這個項目的成長，因為它不算真正扎根社區(qū)的開源項目。”

未來的發(fā)展方向

目前相關(guān)的中間件產(chǎn)品，還是把核心聚焦在水平分片、彈性遷移和 MySQL 實例管理上。

但某種程度上，ShardingSphere 可能代表了未來數(shù)據(jù)庫中間件發(fā)展的核心方向之一，即 0 級功能是可插拔，1 級功能才是數(shù)據(jù)分片。開源和可插拔架構(gòu)結(jié)合在一起，等于打開了數(shù)據(jù)庫中間件在技術(shù)和產(chǎn)品維度的想象空間。張亮透露，SQL 審計、基于數(shù)據(jù)的權(quán)限引擎、多租戶、TTL（Time To Live）都會被提上開發(fā)日程。

除此之外，ShardingSphere 還有一個正在開發(fā)中的構(gòu)想，叫做 Database Mesh，力爭實現(xiàn)數(shù)據(jù)庫上云的原生體驗，但還需要一定的開發(fā)周期。

Database Mesh 會在數(shù)據(jù)庫集群之上，封裝一層代理，做智能的負載均衡。傳統(tǒng)的負載層無法識別 SQL 特征，只能用輪詢或權(quán)重的方式透傳。但 Database Mesh 會根據(jù)不同的 SQL，匹配計算實例的標簽，更加智能選擇要訪問的數(shù)據(jù)庫計算或存儲節(jié)點。

對于架構(gòu)師而言，最重要的是打開技術(shù)選型的眼界與想象力。分布式數(shù)據(jù)庫對業(yè)務的侵入性更低，但中間件方案規(guī)避了對廠商的依賴問題，究竟如何選擇，要以實際場景為判斷依據(jù)。但這并不妨礙我們給出階段性的推論：

很可能，在未來的 5 – 10 年間，數(shù)據(jù)庫中間件都是底層架構(gòu)最重要的解決方案之一，值得每一個架構(gòu)師認真調(diào)研。