背景
一直以來，大一統(tǒng)還是碎片化，是數(shù)據(jù)庫發(fā)展趨勢的兩種最主流預測。隨著數(shù)字化進程的推進，單一場景無法滿足應用多樣化的需求，數(shù)據(jù)庫碎片化已呈不可逆的趨勢。在當前，市場占有率最高的商用數(shù)據(jù)庫—— Oracle 并沒有明顯短板的情況下，各種全新的數(shù)據(jù)庫依舊如雨后春筍般層出不窮。如今，DB-Engines 上已有超過 300 余種數(shù)據(jù)庫參與排名。
應用場景的不斷擴張，加速了數(shù)據(jù)庫碎片化的進程，數(shù)據(jù)庫的架構、協(xié)議、功能、適用場景也愈加多樣化。在數(shù)據(jù)庫架構方面，基于單機系統(tǒng)演進而來的集中式數(shù)據(jù)庫與原生面向分布式的新一代數(shù)據(jù)庫并存;在數(shù)據(jù)庫協(xié)議方面，MySQL 和 PosrtgreSQL 這兩大主要開源生態(tài)以及周邊廠商所提供的服務生態(tài)也在全球數(shù)據(jù)庫體系中各自占有一席之地;每種數(shù)據(jù)庫的獨特功能和適用場景，也在相關的領域大放異彩。
在企業(yè)的應用現(xiàn)狀中，數(shù)據(jù)庫的多元并存已是常態(tài)。在互聯(lián)網(wǎng)行業(yè)中，以 MySQL + 數(shù)據(jù)分片中間件作為核心業(yè)務存儲的架構模式為主，以 GreenPlum、HBase、Elasticsearch、Clickhouse 等其他大數(shù)據(jù)生態(tài)作為分析型數(shù)據(jù)的計算引擎為輔助。與此同時，一些遺留系統(tǒng)(如：通過 .NET 轉型時遺留的 SQLServer、或通過外采而遺留的 Oracle)的數(shù)據(jù)庫仍在運行;在金融行業(yè)中，核心交易系統(tǒng)仍然大量使用 Oracle 或 DB2，新業(yè)務向 MySQL 或 PostgreSQL 遷移，部分業(yè)務則逐漸嘗試使用自主研發(fā)的數(shù)據(jù)庫。除了交易型數(shù)據(jù)庫，分析型數(shù)據(jù)庫的種類則更加繁多。
因此，碎片化是數(shù)據(jù)庫領域的大勢所趨，單一品類的數(shù)據(jù)庫無法適用于所有場景，只能適用于某一種或某幾種擅長的場景。
數(shù)據(jù)庫碎片化帶來的問題
隨著企業(yè)采用的數(shù)據(jù)庫種類不斷增加，各種問題和痛點也隨之出現(xiàn)。
1.架構選型困難
當應用架構為了適應更加靈活多變的業(yè)務需求，將架構設計從單體式向服務化再到微服務進行轉化之后，用于存儲業(yè)務核心數(shù)據(jù)的數(shù)據(jù)庫則成為分布式系統(tǒng)的下一個焦點。
相對比無狀態(tài)的應用，具有狀態(tài)的數(shù)據(jù)庫的設計難度則有過之而無不及。分而治之是分布式系統(tǒng)的最佳實踐，顯然，數(shù)據(jù)庫體系也不能簡單的用單一產(chǎn)品以及一體化集群來響應所有的服務請求。
首先，單一品類的數(shù)據(jù)庫無法滿足業(yè)務應用的全部需求，在高吞吐量、低延時、分布式無感知、強一致性、運維友好度甚至穩(wěn)定性等方面難以做到面面俱到。一個應用需要多種數(shù)據(jù)庫共存的可能性尚且不高，但多個應用混用多種數(shù)據(jù)庫的可能性則大大提升。
其次，無論是單機數(shù)據(jù)庫，還是 All in One 的分布式數(shù)據(jù)庫集群，都難以成為眾多微服務應用后端的唯一存儲支撐。單機數(shù)據(jù)庫無法承載越來越大的數(shù)據(jù)量和訪問量，所以越來越多的應用選擇采用分布式解決方案。然而，多應用使用統(tǒng)一的數(shù)據(jù)庫集群，在 CPU、內存、磁盤、網(wǎng)絡等方面的負載無法做到完全隔離。一個應用的超額資源使用，可能會導致眾多毫不相干的應用服務質量下降。
如今，大部分分布式數(shù)據(jù)庫的搭建成本相當高，在計算節(jié)點、存儲節(jié)點和治理節(jié)點都需要備份和冗余的獨立服務器。如果要為每一個微服務都搭建一套獨立的分布式數(shù)據(jù)庫，一定會造成非必要的資源消耗，最終導致企業(yè)無法承受。
最后，大量企業(yè)采用單元化架構?；跀?shù)據(jù)分片的解決方案，將數(shù)據(jù)庫的拆分和單元化一并放到應用端解決。隨著數(shù)據(jù)庫數(shù)量的增多，架構設計的復雜度會呈指數(shù)級增長。長此以往，業(yè)務開發(fā)團隊將無法把精力集中在最擅長的業(yè)務研發(fā)層面，反而需要花費大量精力投入到基礎組件的維護。盡管 Apache ShardingSphere 的數(shù)據(jù)分片功能可以較好解決相關問題，但面對更多元的數(shù)據(jù)庫，僅支持單一品類數(shù)據(jù)庫的水平分片能力是遠遠不夠的。
2.技術挑戰(zhàn)眾多
當碎片化數(shù)據(jù)庫共存成為常態(tài)時，研發(fā)人員的學習與開發(fā)成本將不可避免的持續(xù)增長。盡管數(shù)據(jù)庫大多支持 SQL 的操作方式，但各數(shù)據(jù)庫間仍有大量 SQL 方言的差異。除此之外，各數(shù)據(jù)庫間驅動程序的使用方式也或多或少存在不同。
因此如需精細化使用每一種數(shù)據(jù)庫，必定會占用研發(fā)工程師大量的精力，且沉淀下來的知識和經(jīng)驗不易傳承;如果采用粗粒度的標準模式統(tǒng)一使用異構數(shù)據(jù)庫，將會湮沒數(shù)據(jù)庫自身的特點，而無法發(fā)揮其應有的作用。
3.運維復雜度高
掌握各種數(shù)據(jù)庫特征，并結合實際場景制定行之有效的運維規(guī)范，需要大量時間和實踐經(jīng)驗的積累。除了最基本的運維工作，數(shù)據(jù)庫周邊配套工具的差異性也非常大。通過周邊配套工具所組成的監(jiān)控、備份及其他自動化運維等工作，隨著數(shù)據(jù)庫種類的增加將會產(chǎn)生巨大的運維成本。
4.數(shù)據(jù)庫間缺乏協(xié)作和統(tǒng)管能力
站在數(shù)據(jù)庫的角度，其首要目標是完善自身的能力，而非面向其他數(shù)據(jù)庫的在線協(xié)作能力。跨越異構數(shù)據(jù)庫的關聯(lián)查詢、分布式事務等功能，是無法在數(shù)據(jù)庫本身實現(xiàn)的。
與相對標準的 SQL 不同，數(shù)據(jù)庫自身的協(xié)議和周邊生態(tài)工具缺乏統(tǒng)一的標準。對異構數(shù)據(jù)庫的統(tǒng)一管控能力也受到越來越多的關注。但遺憾的是，數(shù)據(jù)庫上層標準的缺失，使得數(shù)據(jù)庫間的協(xié)作和統(tǒng)管能力難以取得有效的推進。
Database Plus 是什么?
Database Plus 是一種分布式數(shù)據(jù)庫系統(tǒng)的設計理念。旨在碎片化的異構數(shù)據(jù)庫上層構建生態(tài)，在最大限度復用數(shù)據(jù)庫原生存算能力的前提下，進一步提供面向全局的擴展和疊加計算能力。使應用與數(shù)據(jù)庫間的交互面向 Database Plus 構建的標準，從而屏蔽數(shù)據(jù)庫碎片化對上層業(yè)務帶來的差異化影響。
『連接、增強、可插拔』是定義 Database Plus 核心價值的三個關鍵詞。
1.連接：打造數(shù)據(jù)庫上層標準
相對于提供一個全新的標準，Database Plus 更傾向于提供一個可以適配于各種數(shù)據(jù)庫 SQL 方言和訪問協(xié)議的中間層，提供開放的接口用于對接各種數(shù)據(jù)庫。
由于數(shù)據(jù)庫訪問協(xié)議的實現(xiàn)，Database Plus 和數(shù)據(jù)庫在使用體驗上并無二致，可以支持任意的開發(fā)語言和數(shù)據(jù)庫訪問客戶端。
除此之外，Database Plus 能夠最大限度支持 SQL 方言間的相互轉換?？梢詫?SQL 解析而成的 AST(抽象語法樹)根據(jù)其他數(shù)據(jù)庫方言的規(guī)則重新生成 SQL。SQL 方言轉換的能力，打通了連接異構數(shù)據(jù)庫之間相互訪問的通道，用戶可以使用任意一種 SQL 方言訪問異構的底層數(shù)據(jù)庫。
『數(shù)據(jù)庫網(wǎng)關』是對連接的最佳詮釋。在數(shù)據(jù)庫上層打造開放對接的通用層，將碎片化數(shù)據(jù)庫的全部訪問流量匯集于此，是 Database Plus 為數(shù)據(jù)庫碎片化提供解決方案的前提條件。
2.增強：數(shù)據(jù)庫計算增強引擎
數(shù)據(jù)庫經(jīng)歷了數(shù)十年的發(fā)展，其自身具備了查詢優(yōu)化器、事務引擎、存儲引擎等久經(jīng)考驗的存算能力和設計模型。在 IT 領域，數(shù)據(jù)庫的設計和使用方式已深入人心，不可動搖。隨著分布式和云原生時代的到來，將數(shù)據(jù)庫原有的計算和存儲能力全部打散，并織入分布式和云原生級別的全新能力，會不可避免的重復造輪子。
因此，Database Plus 采用了既重視傳統(tǒng)數(shù)據(jù)庫的實踐經(jīng)驗，又適配于新一代分布式數(shù)據(jù)庫的設計理念。無論是集中式還是分布式的數(shù)據(jù)庫，Database Plus 都能復用數(shù)據(jù)庫的存儲和原生計算能力，并在其基礎之上提供全局化的能力增強。
全局化的能力增強主要在分布式、數(shù)據(jù)控制和流量控制三個方面。
無論是原生面向分布式的數(shù)據(jù)庫，還是基于集中式數(shù)據(jù)庫作為基石的分布式擴展方案，都離不開分而治之這個分布式系統(tǒng)永恒不變的設計原理。數(shù)據(jù)分片、彈性伸縮、高可用、讀寫分離、分布式事務、以及基于垂直拆分的異構數(shù)據(jù)庫聯(lián)邦查詢等功能，都是 Database Plus 在分布式的異構數(shù)據(jù)庫全局層面下所能夠提供的能力。它的關注點不在于數(shù)據(jù)庫自身，而是站在碎片化的數(shù)據(jù)庫上層，關注于多個數(shù)據(jù)庫之間的全局協(xié)作能力。
除了分布式增強之外，數(shù)據(jù)控制和流量控制的增強能力均處于豎井化范疇。面向數(shù)據(jù)控制的增量能力包括：數(shù)據(jù)加密、數(shù)據(jù)脫敏、數(shù)據(jù)水印、數(shù)據(jù)溯源、SQL 審計等;面向流量控制的增量能力包括：影子庫、灰度發(fā)布、SQL 防火墻、黑白名單、熔斷限流等。這些均屬于數(shù)據(jù)庫生態(tài)層所提供的能力，然而在數(shù)據(jù)庫碎片化的態(tài)勢下，為每一種數(shù)據(jù)庫提供全量的增強能力的工作量十分巨大，且缺失統(tǒng)一的實現(xiàn)標準。Database Plus 通過提供支點，將支持的數(shù)據(jù)庫種類和增強功能相疊加，以排列組合的方式提供給用戶使用。
3.可插拔：構建數(shù)據(jù)庫功能生態(tài)
不斷增加的數(shù)據(jù)庫類型對接和增強功能織入，會使 Database Plus 通用層逐漸趨于臃腫。連接和增強的可插拔化，既是 Database Plus 通用層維持小而美的基石，也是擴展生態(tài)無限化的有效保障?？刹灏蔚捏w系，為 Database Plus 通用層提供了插件生態(tài)無限擴張的可能，使用者只需根據(jù)自身需求裁減插件即可。
通過可插拔體系，Database Plus 將能夠真正的構建面向數(shù)據(jù)庫的功能生態(tài)，將異構數(shù)據(jù)庫的全局能力統(tǒng)一納管。它不僅面向集中式數(shù)據(jù)庫的分布式化，也同時面向分布式數(shù)據(jù)庫的豎井功能一體化。
微內核設計和可插拔架構是 Database Plus 理念的核心價值，它面向通用的平臺層，而非某項具體功能。
ShardingSphere 在 Database Plus 方向的探索
Apache ShardingSphere 項目歷史悠久，從開源伊始的數(shù)據(jù)庫分片中間件，到如今 Database Plus 理念的奠基者和實踐者，它的前進步伐從未放緩。目前，Apache ShardingSphere 遵循 Database Plus 理念，已完成了 Database Plus 三大核心價值下的大部分基礎設施建設。
1.連接層
ShardingSphere 已支持 MySQL、PostgreSQL、openGauss 等數(shù)據(jù)庫協(xié)議，以及 MySQL、PostgreSQL、openGauss、SQL Server、Oracle 和所有支持 SQL92 標準的 SQL 方言。
連接層抽象的頂層接口可供其他數(shù)據(jù)庫開放對接，包括：數(shù)據(jù)庫協(xié)議、SQL 解析和數(shù)據(jù)庫訪問等。
2.增強層
ShardingSphere 的功能增強劃分為內核層和可選功能層。
內核層包含查詢優(yōu)化器、分布式事務、執(zhí)行引擎、權限引擎等與數(shù)據(jù)庫內核強相關的功能，以及調度引擎、分布式治理等與分布式強相關的功能。內核功能的每個模塊都必須存在，但可以切換至不同的實現(xiàn)類型。以查詢優(yōu)化器為例，如果待執(zhí)行 SQL 可以完美下推至后端數(shù)據(jù)庫，則采用基于原始 SQL 與數(shù)據(jù)庫交互的計算下推引擎;如果待執(zhí)行 SQL 需要跨越多數(shù)據(jù)源進行關聯(lián)查詢，則采用基于查詢計劃樹與數(shù)據(jù)庫交互的聯(lián)邦查詢引擎。
可選功能層的功能模塊由開源社區(qū)沉淀而形成。除了最具代表性的數(shù)據(jù)分片和讀寫分離之外，高可用、彈性伸縮、數(shù)據(jù)加密、影子庫等功能模塊，都在逐步的完善之中。
3.可插拔層
從最初的 MySQL + 數(shù)據(jù)分片為核心的架構模型，到如今的微內核 + 可插拔架構，項目進行了徹底的改造。從提供連接的數(shù)據(jù)庫種類和增強功能到內核能力，ShardingSphere 全部面向可插拔。
ShardingSphere 的架構核心外圍，由微內核、可插拔接口、插件實現(xiàn)這三層模型組成，層次之間單項依賴，微內核對插件功能完全無需感知，插件之間也無需相互依賴。對于一個擁有 200+ 模塊的大型項目來說，架構的解耦和隔離，是社區(qū)開放協(xié)作、將錯誤影響范圍降低至最小的有效保障。
小結
Database Plus 是 ShardingSphere 的理論支撐，ShardingSphere 是 Database Plus 理念的最佳實踐。隨著 ShardingSphere 的越來越成熟，Database Plus 的拼圖也會越來越豐滿。
Database Plus 帶來的優(yōu)勢
Database Plus 帶來眾多的優(yōu)勢，受限于篇幅，無法在文中一一列舉。下面僅從影響系統(tǒng)架構設計和技術選型方面進行闡述。
1. 精細化適配靈活多變的應用場景
用戶可以根據(jù)自身需求定制化使用相應功能，數(shù)據(jù)分片不再是使用 ShardingSphere 的必要條件，獨立使用數(shù)據(jù)加密功能的用戶已不在少數(shù)。ShardingSphere 的可插拔能力不僅限于數(shù)據(jù)庫接入層和功能增強模塊本身，每個功能模塊的內部也能夠基于可插拔架構靈活配置。
以數(shù)據(jù)分片為例，作為數(shù)據(jù)分片模塊的可插拔部分，分片算法可以由用戶自定義配置，無論是標準的哈希、范圍、時間等分片算法，還是自定義分片算法，使用者都可以根據(jù)業(yè)務場景需要自由靈活配置，最大限度切合業(yè)務場景。
2.面向架構師的微服務后端支撐能力
Apache ShardingSphere 是微服務后端的數(shù)據(jù)庫單元化最佳方案。正如前文所述，不同的微服務共享一套分布式數(shù)據(jù)庫集群，無論從架構設計的不對稱性，還是資源隔離的不可控性，都不能稱之為完善和優(yōu)雅的解決方案。為每一組微服務搭建一套分布式數(shù)據(jù)庫集群，則又會造成非必要的資源浪費。
相對于重量級的分布式數(shù)據(jù)庫集群，ShardingSphere-Proxy 所占用的資源節(jié)省很多，為每個微服務集群獨享一套數(shù)據(jù)庫集群奠定良好基礎。但如果微服務拆分足夠精細，為每一組微服務搭建一套 ShardingSphere-Proxy 的額外資源占用依舊不可小覷。在這種情況下，可以考慮使用占用資源更少的 ShardingSphere-JDBC，它作為類庫與應用代碼部署在一起，無需額外占用資源。
ShardingSphere-Proxy 和 ShardingSphere-JDBC 不僅可以通過混合使用的方式，來滿足用戶的使用友好度、跨語言適配、高性能、資源節(jié)省等各方面需求;還可以通過 Traffic Rule 讓 ShardingSphere-Proxy 和 ShardingSphere-JDBC 在不同特征的 SQL 請求中相互路由，以最小化應用資源占用所帶來的影響。
Traffic Rule 可以根據(jù)用戶自定義的 SQL 特征(如：聚合計算、無分片鍵的全路由查詢等)，將占用更多計算資源的請求發(fā)送至獨占資源的 ShardingSphere-Proxy，而將交易型的輕量級操作保留在微服務應用端。這與邊緣計算的理念不謀而合，ShardingSphere-JDBC 在微服務應用端的算力和邊緣計算節(jié)點有異曲同工之妙。用于中心計算的 ShardingSphere-Proxy 可以根據(jù)業(yè)務自身需要，部署獨立的集群服務于多組微服務。
通過靈活使用 ShardingSphere-Proxy、ShardingSphere-JDBC 和 Traffic Rule，這套組合將能夠不斷激發(fā)著架構師的設計靈感和創(chuàng)造力。開句玩笑，正確使用 ShardingSphere 進行優(yōu)雅的系統(tǒng)設計，可以被當作優(yōu)秀架構師的準入線。
3.DistSQL 為 DBA 帶來數(shù)據(jù)庫原生操作體驗
面對數(shù)據(jù)分片、數(shù)據(jù)加密等增強功能，Apache ShardingSphere 之前版本主要采用 YAML 的方式進行配置。對于開發(fā)工程師來說，靈活的 YAML 配置使用起來得心應手，但對于 DBA 而言，YAML 的配置方式確存在諸多不便。除了改變了 DBA 的日常 SQL 操作習慣之外，無法對接諸如權限、安全、工單、監(jiān)控、審計等第三方系統(tǒng)，也讓此前的 ShardingSphere 難以適用于生產(chǎn)環(huán)境的運維管控。
全新版本的 Apache ShardingSphere 增加了 DistSQL 的操作方式。使用者可以完全通過 SQL 在任意的數(shù)據(jù)庫終端(如：MySQL Cli、Navicat 等)操作增強功能。數(shù)據(jù)分片、數(shù)據(jù)加密、讀寫分離等所有的強功能都擁有與之相匹配的 DistSQL，使用 DBA 所熟悉的 CREATE/ALTER/DROP/SHOW 等 SQL 語法即可完成全部功能的配置。DistSQL 同樣支持授權語句的管控，也可以通過對接 SQL 審計平臺記錄所有使用者的操作記錄。
數(shù)據(jù)庫表結構是 Database 的元數(shù)據(jù)，增強功能配置是 Database Plus 的元數(shù)據(jù)。DistSQL 的出現(xiàn)，不僅提升了用戶友好度，也補全了 Apache ShardingSphere 上線和運維的最終拼圖。
4.Proxyless 模式提升性能至極致
在 Service Mesh 領域，最為經(jīng)典就是 Istio + Envoy 架構搭配模式。它通過 Sidecar 的部署方式管理 Envoy，做到對應用的無侵入，稱之為 Proxy Service Mesh，降低了開發(fā)、使用和升級的成本，但由于在訪問鏈路中增加了 Proxy/Sidecar 這一層，使得性能有所下降。
而 Proxyless Service Mesh 則采用另一種設計模式，它始于 gRPC 對 xDS 協(xié)議的實現(xiàn)，Istio 新版本通過 gRPC + xDS 的方式，允許應用代碼直接通過 Istio Agent 提供的 SDK 編程，有效提升了通信性能。
在分布式數(shù)據(jù)庫領域，存算分離的架構設計模式已經(jīng)深入人心。計算節(jié)點和存儲節(jié)點分離的設計，與 Proxy Service Mesh 的架構模型有些類似。ShardingSphere-Proxy 的設計完全契合了存算分離的架構模型，它有效降低了用戶的開發(fā)、使用和升級成本，卻不可避免帶來了一定的性能損耗。
對于性能延時敏感的應用而言，與 Proxyless Service Mesh 設計理念不謀而合的ShardingSphere-JDBC 無疑更加合適，其能夠將系統(tǒng)的性能發(fā)揮至極致。在近期使用 ShardingSphere + openGauss 測試 TPC-C 模型的結果中，得到了驚人的 16 臺服務器超過 1000w tpmC 的測試結果，行業(yè)同等規(guī)模下性能最佳。
小結
一直以來，先進的設計理念和創(chuàng)新均源于西方。但 gRPC 的 Proxyless 設計理念是近期才出現(xiàn)的，而 ShardingSphere-JDBC 則是項目在 2016 年開源伊始時就已經(jīng)存在。因此，ShardingSphere-JDBC 并未參考 Proxyless 的設計理念，它是基于當時國內互聯(lián)網(wǎng)業(yè)務對高并發(fā)和低延時的極致性能要求而誕生的。
至于 Database Plus 理念的設計，又何嘗不是如此。伴隨著互聯(lián)網(wǎng)的長期快速發(fā)展，業(yè)務的變化直接推動了技術的積累和成長，ShardingSphere 就是這一過程的最好例證，它的設計方案全部源自于真實業(yè)務場景。中國互聯(lián)網(wǎng)無疑是全球最全面的場景之一，在此類場景下誕生的設計理念，在全球范圍內也一定擁有十分廣闊的生長空間。
未來規(guī)劃
盡管在 Database Plus 理念的實踐道路上越走越遠，但 Apache ShardingSphere 仍然有大量的工作等待完成。數(shù)據(jù)庫網(wǎng)關和異構聯(lián)邦查詢，是完善 Database Plus 理念的重要功能拼圖。
1.數(shù)據(jù)庫網(wǎng)關
Apache ShardingSphere 雖然支持異構數(shù)據(jù)庫的對接，但無法做到數(shù)據(jù)庫之間方言的相互轉換。在 ShardingSphere 的線路規(guī)劃中，SQL 方言轉換是實現(xiàn)數(shù)據(jù)庫網(wǎng)關的重要功能，用戶通過 PostgreSQL 的數(shù)據(jù)庫協(xié)議用 MySQL 方言訪問 MongoDB 將不再是難以實現(xiàn)的任務。
2.異構聯(lián)邦查詢
Apache ShardingSphere 目前僅支持同構數(shù)據(jù)庫間的聯(lián)邦查詢。在 ShardingSphere 的線路規(guī)劃中，異構數(shù)據(jù)庫間的聯(lián)邦查詢也將被提上日程。用戶通過一條 SQL 關聯(lián)查詢 MySQL 和 HBase 的場景將不再遙遠。
寫在最后
Apache ShardingSphere 社區(qū)已在開源領域耕耘了 7 年的時間。長久的堅持，使社區(qū)愈加成熟，已呈開放和多元化的勢態(tài)。我們誠心誠意地歡迎有開源情懷和編碼熱情的朋友一起參與社區(qū)共建。
Apache ShardingSphere 的可插拔架構和數(shù)據(jù)分片哲學已在學術界獲得廣泛認可。在今年的數(shù)據(jù)庫領域頂級的會議 ICDE 中，已成功發(fā)表論文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。
關于作者
張亮，SphereEx 公司創(chuàng)始人 & CEO，歷任多家大型知名互聯(lián)網(wǎng)企業(yè)的架構、數(shù)據(jù)庫團隊負責人。熱愛開源，是 Apache ShardingSphere、ElasticJob 等知名開源項目創(chuàng)始人 & 項目管理委員會主席、現(xiàn)任 Apache 軟件基金會會員、微軟 MVP、騰訊云 TVP、華為云 MVP。擁有超過 10 年的架構和數(shù)據(jù)庫領域探索、實踐經(jīng)驗。擅長分布式架構，推崇優(yōu)雅代碼，在分布式數(shù)據(jù)庫技術和學術等方面均取得重大成果。曾在 ApacheCon、QCon、AWS 峰會、DTCC、SACC、DTC等數(shù)十個國內和國際重大行業(yè)和技術峰會中擔任出品人和分享嘉賓。曾出版書籍《未來架構——從服務化到云原生》，并在數(shù)據(jù)庫行業(yè)頂級會議 ICDE 發(fā)表論文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。
（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
