Apache ShardingSphere 遇上得物“彩虹橋”

Apache ShardingSphere 技術團隊此前應邀到得物上海總部，與得物的技術同學關於 ShardingSphere 的使用經驗進行了交流。

得物 App 是全球領先的集正品潮流電商和潮流生活社群於一體的新一代潮流網購社群。隨著得物 App 使用者開始快速增長，業務線日趨豐富，也對底層資料庫帶來了較大的壓力。得物技術團隊採用了 Apache ShardingSphere 來緩解底層資料庫壓力，並對其進行了深度改造和功能最佳化。

得物基於 Proxy 的改造：彩虹橋

此前，得物在多個業務場景下使用 ShardingSphere-JDBC 來進行資料分片，在使用 ShardingSphere-Proxy 時，也延續了分別部署多套 Proxy 叢集這類的架構模式，並以 Apache ShardingSphere 5.0.0-alpha 版本為基礎，自研了一套得物資料庫代理層中介軟體：彩虹橋。

在與得物技術團隊的交流中，發現了 ShardingSphere 在很多特殊場景下的應用潛力，未來在後續 ShardingSphere 社群版本的迭代中，得物技術團隊也將會作為社群核心成員，參與到未來專案規劃、功能搭建中來。

對於 ShardingSphere-Proxy 的部署方式而言，可以在面向整個集團業務之上部署一套 Proxy 叢集進行統一管理，也可以根據不同業務需要，獨立為每一條業務部署對應的 Proxy 叢集。 目前，在得物的業務場景下，絕大部分核心業務域都配置有 Proxy 叢集，每個業務域下會有很多應用服務，如交易業務域下有商品、訂單等多個服務，這些服務共用同一個 Proxy 叢集。此外如供應鏈等多個業務下，都會有各自對應的模型叢集，以減少其它業務變更對整體平臺所產生的影響，降低業務風險。

同時在 ShardingSphere 的基礎上，得物自研了一套系統，並在這個系統中實現瞭如叢集一鍵切換等能力。如某個叢集有問題的話，就可以將叢集上服務的流量全部都切到另外叢集上面去，實現無損釋出。同時，得物對業務的連線池也做了一些改造。由於底層資料庫與 ShardingSphere-Proxy 之間是長連線，如果要實現無損釋出，就需要對連線池進行改造。首先基於當前連線池的狀態，如果是空閒狀態，可以先把負載均衡流量摘掉，再回到連線池裡做柔性關閉。如果非空閒狀態，就等連線池使用完畢後再關閉掉，進而確保灰度釋出過程中保證資料無損。

Apache ShardingSphere 壓測問題與全鏈路追蹤

得物目前採用了兩種壓測方式，一種是用自定義 Hint 的形式，即 SQL 註釋的方式，傳輸壓測包括一些額外資訊。另外一種方式，透過先發一條 SQL 到 Proxy 確認是否存在 Hint 資訊，然後再發出一條真正的 SQL。但是如此一來會傳送兩條 SQL，導致響應時間升高。目前 ShardingSphere 社群也已經將相關問題納入到未來規劃之中，將與得物技術團隊共同完成相關難題的技術攻堅工作。

與壓測場景伴隨著的是 Tracing 全鏈路追蹤的問題。在得物的業務場景中，由於採用了分庫分表策略，整體架構從上到下相對而言都比較複雜。得物技術團隊透過 Hint 方式實現了全鏈路追蹤，不過對效能卻會不可避免地產生一定影響。

Apache ShardingSphere 推薦的影子庫能力，配合 CyborgFlow，可以實現全鏈路線上壓測。全鏈路線上壓測是⼀項複雜⽽龐⼤的⼯作，需要各個微服務、中介軟體之間配合完成。 藉助於 ShardingSphere 強⼤的 SQL 解析能⼒，對執⾏ SQL 進⾏影⼦判定，同時結合影⼦演算法靈活的配置，滿⾜複雜業務場景的線上壓測需求。壓測流量路由到影⼦庫，線上正常流量路由到⽣產庫，從⽽幫助⽤戶實現壓測資料與生產資料的隔離，解決資料汙染問題。

利用 Database Mesh，與社群共同探索東西流量治理的新方式

得物目前在多個業務域上都分別部署了一套 Proxy 叢集，在上層有很多模組，如訂單、商品、供應鏈等等，因此需要探索一種 Proxy 多叢集之間洞悉流量的治理方式。

Proxy 下可能存在多個節點，如何合理分配節點資源，如訂單、商品、供應鏈等分別只訪問其中兩個節點，底層資料庫是一樣的。得物的做法是透過在多個節點上掛負載均衡，在負載均衡上基於某開源專案自研了一個連線池，透過該連線池選擇負載均衡。進而實現叢集能夠在業務層面的無感動態切換。

這和 ShardingSphere 目前在做的方向不謀而合。ShardingSphere Sidecar 定位為 Kubernetes 的雲原生資料庫代理，以 Sidecar 的形式代理所有對資料庫的訪問，根據演算法規定 SQL 的路徑。透過無中心、零侵入的方案提供與資料庫互動的齧合層，即 Database Mesh，又可稱資料庫網格。

Database Mesh 的關注重點在於如何將分散式的資料訪問應用與資料庫有機串聯起來，它更加關注的是互動，是將雜亂無章的應用與資料庫之間的互動進行有效地梳理。 使用 Database Mesh，訪問資料庫的應用和資料庫終將形成一個巨大的網格體系，應用和資料庫只需在網格體系中對號入座即可，它們都是被齧合層所治理的物件。

在邏輯庫之間實現隔離

在後臺，一個 Proxy 叢集下會掛靠多個邏輯庫，大部分情況下這些多個邏輯庫都是共用一個效能池。那這樣的話其實我們之前也發生過一些事情，比如說某一個邏輯庫下面 RDS 掛了，會導致阻塞，如何實現邏輯庫之間的隔離？

得物這裡採用了基於執行緒池的隔離方案，引入了獨佔&共享執行緒池的概念，優先使用邏輯庫獨佔執行緒池，當獨佔執行緒池出現排隊情況再使用共享執行緒池，共享執行緒池達到一定負載後會在一個時間視窗內強制路由到獨佔執行緒池，在保障隔離性的前提下，最大化利用執行緒資源。

但是每一個邏輯庫對應一個執行緒池，如果邏輯庫很多，執行緒池就會增加。目前在得物的實踐場景中，有百餘個邏輯庫用於真實生產環境，會自然啟動幾千個左右執行緒。雖然目前對於機器的壓力並不大，但隨著邏輯庫的增加，執行緒池的數量也會增加，問題也會逐漸湧現出來。但是可以透過控制單個叢集掛載邏輯庫的數量來避免這一問題。

目前，Apache ShardingSphere 要求所有 RDS 都線上，未來規劃為 RDS 增加多種狀態，使其具備線上狀態、離線狀態、disable 狀態等。透過狀態來分辨 RDS 的情況，根據狀態的不同來進行管理操作，進而實現邏輯庫之間的隔離。

ShardingSphere 是兩套執行邏輯，分別為底層執行執行緒，上層接收執行緒。Proxy-RDS 例項級別的熔斷，目前支援在從庫中利用讀寫分離功能實現熔斷。如果是主庫熔斷，就涉及到高可用的部分，相對更加複雜。

版本迭代所帶來的煩惱

配合自身業務訴求，在功能層面，得物目前已經對 ShardingSphere 進行了比較深度的改造。但與此同時，ShardingSphere 社群版本的更新，也為得物內部的需要帶來了一些複雜性。由於此前是基於 Apache ShardingSphere 5.0.0-alpha 版本所做的改造，加之社群版本變動比較大，對於內部合併來說，還是帶來了一定的困難。因為無法確定社群開源版本更改的內容，會不會對現有業務產生影響，以及目前得物所做的改動如何合併到社群中等。

未來 Apache ShardingSphere 社群團隊也會和得物技術團隊展開密切交流，分別就各自的改動進行升級評估，平衡開源版本對使用者進行改造後的影響。

【聯絡我們】

如果您在業務中有應用 Apache ShardingSphere，想要快速瞭解、接入 Apache ShardingSphere 5.X 新生態，希望藉此機會在團隊內部舉辦一場關於 Apache ShardingSphere 的技術分享， 歡迎在公眾號後臺中留下您的姓名、公司、職位、電話等資訊，或新增官方小助手（ss_assistant_1），備註“走進企業”，會有專人與您對接。

在溝透過後如果雙方認為產品和場景均非常匹配，Apache ShardingSphere 社群的核心團隊將會走進您的企業，與各條研發線的工程師們現場溝通，解答關於 Apache ShardingSphere 的任何疑問。

歡迎點選連結，瞭解更多內容：

Apache ShardingSphere 官網：

Apache ShardingSphere GitHub 地址：

SphereEx 官網：