為了讓你搞定資料庫選型，這些工程師重寫了 26 萬行程式碼

SphereEx發表於2021-10-11
資料庫工程師行程
以下文章來源於InfoQ 架構頭條 作者 | 王一鵬
無論多麼有主見的架構師，在做資料庫選型的時候，也可能會犯難。
傳統 SOL、NoSQL 還是 NewSQL？架構風格是以久經考驗的關係型資料庫為主，還是偏向所謂原生的分散式架構？如果提及具體產品，那選擇就更多了，TiDB、OceanBase、PolarDB、TDSQL、GaussDB、MongoDB…… 現在還有許多服務於新場景的產品，比如處理時序資料的 TDengine，處理圖資料的 Nebula Graph……以及最老派又最完善的 Oracle。
如果從業務場景或即將面臨的遷移成本來看，問題會更加複雜。牽扯到底層資料的選型和架構設計，有時更像一錘子買賣，一旦定了某種方案，再想替換代價可不是一般的大。
差不多在 10 年前，這事兒還沒有那麼棘手。Oracle、IBM Db2，二選一而已。但今時不同往日，這是一個資料量急速膨脹、業務高度複雜的時代，真正讓人焦慮的不是單純的選型問題，而是將“降本提效”推向極致的數字化轉型問題。
那麼，除了咬牙硬選一個資料庫，或者基於現有資料庫的基礎上自研一套儲存方案，真的沒有其他路可走了嗎？其實也有，只不過在分散式資料庫熱度越來越高的當下，顯得有些“透明”，那就是中介軟體 + 多商業資料庫的解決方案。
看到這個答案，你可能會有些失望。中介軟體方案出現的時間，尚在分散式資料庫成熟之前。因此在業內很多架構師看來，這種方案在技術上不夠超前，只能算是某種“過渡策略”，本質上是 NewSQL 資料庫成熟前的無奈之舉。
但來自金融等行業的諸多落地實踐證明，事實可能並非如此。
我們為此特別採訪了全球頂級開源專案 Apache ShardingSphere 的作者，以及背後商業公司 SphereEx 的 CEO 張亮，他一直對分散式架構設計保持關注， 關於整個資料庫行業的選型和架構設計問題，張亮有著特別的思考。

1、可插拔架構，或許是答案

“需求是多元化的，一部分使用者適合分散式資料庫，一部分使用者適合用資料庫中介軟體，甚至還有一部分適合兩種都用，沒有太絕對的答案”，張亮說。
這是個無錯的答案，但也可以得出一個推論： 如果場景是多元化的，資料庫是多元化的，那麼架構師應該儘量規避擴充套件性、相容性不好的資料庫解決方案。
無獨有偶，Oracle ACE、資料庫專家韓鋒也在其個人公眾號裡發表過類似的觀點：“（關於資料庫選型）為了規避路線選擇、廠商繫結的風險，比較現實的方法是選擇一款相容通用性協議的產品，並且在應用中僅使用標準資料庫的用法。”
二者結合起來，我們能抽離出一些關鍵詞：中立、相容、標準，對於很多在選型問題上難以抉擇的架構師來說，這讓中介軟體路線看起來更加實際。
與資料庫行業不同，以 ShardingSphere 為代表的中介軟體層由於不涉及儲存引擎，如今已將目光從單純的水平擴充套件問題轉向業務支援和靈活性問題，也因此得以實現對異構資料庫的統一管理。
靈活性、相容性，是資料庫中介軟體產品的核心，也是解決“資料庫選型”問題的關鍵。據張亮透露，近兩年的主要研發重點一直是可插拔架構，以將靈活性和相容性推向極致。好訊息是，ShardingSphere 的可插拔架構預計將在未來一段時間內正式上線。
所謂的可插拔架構，是指在架構層面，將整個系統分為基座和外掛兩部分，外掛部分互相隔離、互不影響，基座可以自由接入多個外掛。可插拔架構多見於相對輕量級的前端領域，屬於微前端體系的一部分，但在基礎軟體部分則相當少見。
張亮認為，可插拔架構形式是未來資料庫中介軟體的主要趨勢之一，一則產品需要高度的靈活性，二則還有大量的能力需要被構建，比如資料安全、異構資料閘道器等功能，可插拔架構自然成為了產品核心。
話雖如此，但可插拔架構的設計難度卻很大，讓人望而生畏。這種設計難度，大致可分為兩部分來談：
第一，可插拔架構是對 OCP（Open-Closed Principle）原則的一次徹底執行，力圖僅透過增加新模組來滿足新需求，舊有模組完全保持 0 修改。這意味著，可插拔架構要清晰地定義出，什麼是基座，什麼是外掛。它對上層、下層都無感知，一切面向介面。用張亮的話說，就是：“完全面向一個抽象的、虛無的東西，不涉及任何的業務細節”。
比如，ShardingSphere 轉向可插拔架構後，其核心流程裡已經沒有分片功能了，分片會作為可插拔能力的一部分接入到服務中。對於資料庫中介軟體來說，幾乎屬於產品重定義。與許多人對資料庫中介軟體的固有認知相悖，因為在許多人的理解中，資料庫中介軟體不就是為了分庫分表而存在的嗎？
但實際情況是， 單體資料庫的覆蓋場景依然很多，分庫分表並不是 0 級功能。這是在架構層面，必須具備的關鍵洞察。
第二，與微服務相似，只要涉及服務拆分，就會涉及顆粒度問題。對於可插拔架構來說，需要外掛化的不一定只是產品功能，比如兩階段強一致事務和柔性事務，也是能夠實現可插拔的。
基於這些拆分問題，ShardingSphere 把可插拔架構分為三層，分別是核心層、功能層、生態層，分別面向資料庫核心、企業功能、資料庫生態進行可插拔設計。其中，查詢最佳化器、分散式事務引擎、排程引擎等是核心層的可插拔模組；資料分片、讀寫分離、資料庫高可用、資料加密、影子庫都是功能層的可插拔模組；資料庫協議、SQL 方言等則是生態層的可插拔模組。
要實現可插拔架構，除了設計難度和顆粒度拆分，其工作量也令人歎為觀止。ShardingSphere 有 190 多個模組，近 43 萬行程式碼，核心 Java 程式碼 29 萬行，張亮回憶道：“為了做可插拔架構，老程式碼留了不到 1/10。”這意味著，有近 26 萬行的核心程式碼被重寫了。
可插拔架構是 ShardingSphere 追求靈活性最重要的標誌之一，但它對靈活性的追求又不僅限於可插拔架構。
比如，ShardingSphere 還額外提供了兩種部署形態，分別為 JDBC 和 Proxy。JDBC 是 Java 訪問資料庫的標準介面，Proxy 是中介軟體最常見的服務形式，且兩者能夠在同一開發環境下進行組合使用，以滿足多使用者下多型別訪問的需求。
這樣多種型別的服務介面，一方面服務了不同型別的開發人員，另一方面也實現了效能層面的可定製化，工程師可以結合場景調整資料庫分片的鍵值，實現不同場景下，效能的最大化提升；反之，“全包式”資料庫方案，則往往需要放棄部分靈活性，以相對中庸的方案來換取無感知、低侵入的使用體驗，體現了與資料庫中介軟體方案的差異性。

2、真正的開源專案，是社群說了算

如果我們要做技術選型，需要注意的另外一點是，備選產品的維護主體是誰，備選產品的基因是什麼，是開源，還是閉源？這與搞清楚產品的技術方案、技術理念同樣重要。
當下，無論開源的熱度如何，大部分分散式中介軟體、分散式儲存、資料庫都是閉源的，這是不爭的事實。
看到的是，大量的開源創業公司正在出現，資本也在快速進入，比如 SphereEx、歐若數網、Neo4j，以及大家熟知的 PingCAP。同時也有許多資料庫宣佈開放原始碼，比如 OceanBase、Tendis、openGauss。
為什麼在資料儲存領域，開源這麼引人關注？
一個可能的答案是，開源在技術層面的想象空間更大，對開發者更友好。就像 ShardingSphere 的可插拔架構，架構設計完成只是第一步，後續還有海量的不同模組的開發工作。對於創業公司來說，如果不借助社群的力量，美好的可插拔架構也可能成為公司的研發黑洞。
產品的中立性，也是導致開源專案集中迎來爆發的另一個要素。尤其是在資料儲存領域，最美好的答案可能是無依賴、跨多雲，最差的答案才是被單一產品強繫結。
當然，開源再好，也抵不過現實的骨感。開源兩年，Star 幾百，花錢不少，效果為零，這恐怕是眾多開源專案的常態。社群的健康程度，往往直接定義了開源專案的生死，這導致即便架構師想做選型，也沒有太多的好選擇。
在張亮看來，一個開源專案能不能成功，大致可以分為三個維度來考察：
第一，能否耐住寂寞，團隊是真的相信開源，還是拿開源當做商業上的捷徑。一個最簡單的考核指標便是運營時間，“開源專案一定要度過‘靜默期’才會迎來爆發，只做了半年、一年，是沒法預估專案未來的”，張亮說。
第二，一些必備的運營技巧。張亮一方面把 ShardingSphere 捐獻給 Apache 基金會，另一方面也帶著專案參與了許多活動，比如谷歌舉辦的駭客馬拉松、程式設計夏令營，除國內使用者以外，也吸引了大批的海外開發者、學生參與到社群建設中來。
第三，觀念的轉變，也是最關鍵的部分。從小處著眼，是從“自己開發”到“社群開發”；從大處著眼，就是在真正意義上擁抱開源，而不只是嘴上說說。
“ShardingSphere 的專案發展是受社群的引導。比如說，社群認為 ShardingSphere 該做基於影子庫的壓測和可觀察性，ShardingSphere 就真的做了。這些都不是專案自上而下的設計，只要需求爆發，且在專案的 Scope 內，就可以實現。但如果一個公司在運營開源專案時，遇見所謂的偏離主線設計的社群訴求，就拒掉它，那麼大機率也會影響這個專案的成長，因為它不算真正紮根社群的開源專案。”

3、未來的發展方向

目前相關的中介軟體產品，還是把核心聚焦在水平分片、彈性遷移和 MySQL 例項管理上。
但某種程度上，ShardingSphere 可能代表了未來資料庫中介軟體發展的核心方向之一，即 0 級功能是可插拔，1 級功能才是資料分片。開源和可插拔架構結合在一起，等於開啟了資料庫中介軟體在技術和產品維度的想象空間。張亮透露，SQL 審計、基於資料的許可權引擎、多租戶、TTL（Time To Live）都會被提上開發日程。
除此之外，ShardingSphere 還有一個正在開發中的構想，叫做 Database Mesh，力爭實現資料庫上雲的原生體驗，但還需要一定的開發週期。
Database Mesh 會在資料庫叢集之上，封裝一層代理，做智慧的負載均衡。傳統的負載層無法識別 SQL 特徵，只能用輪詢或權重的方式透傳。但 Database Mesh 會根據不同的 SQL，匹配計算例項的標籤，更加智慧選擇要訪問的資料庫計算或儲存節點。
對於架構師而言，最重要的是開啟技術選型的眼界與想象力。分散式資料庫對業務的侵入性更低，但中介軟體方案規避了對廠商的依賴問題，究竟如何選擇，要以實際場景為判斷依據。但這並不妨礙我們給出階段性的推論：
很可能，在未來的 5 - 10 年間，資料庫中介軟體都是底層架構最重要的解決方案之一，值得每一個架構師認真調研。

歡迎大家關注我們的公眾號

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70001955/viewspace-2795422/，如需轉載，請註明出處，否則將追究法律責任。

相關文章