本文由張亮原創，首發於京東數科技術說微信公眾號
「摘要」張亮，數據庫管理部資深架構師，Apache ShardingSphere發起人 & PPMC熱愛開源，目前主導開源項目ShardingSphere(原名Sharding-JDBC)和Elastic-Job。擅長以java為主分佈式架構以及以Kubernetes和Mesos為主的雲平臺方向，推崇優雅代碼，對如何寫出具有展現力的代碼有較多研究。
目前主要精力投入在將ShardingSphere打造為業界一流的金融級數據解決方案之上。ShardingSphere已經進入Apache孵化器，是京東集團首個進入Apache基金會的開源項目，也是Apache基金會首個分佈式數據庫中間件。
在過去的2018年，我所負責的ShardingSphere，有幸成為京東集團首個進入Apache基金會的孵化項目，很榮幸地入圍集團技術金項獎提名。我是2018年初入職，時間過得真快，不知不覺已經整整一年。2019年的2月5日恰逢正月初一，寫下此文記錄我這一年的所聞、所見、所感與所得。
契機 —— 加入京東
加入之前，我在另一家互聯網公司負責架構部，並傾力於開源。任職期間，我開源了兩個項目：分佈式調度框架Elastic-Job和數據庫分庫分表中間件Sharding-JDBC。對這兩個項目，我投入了相當大的精力，也由此在開源界收穫了較為良好的口碑。
除了自己的開源，我非常願意幫助其他開源項目成長和進步。我曾經主導將架構團隊開發的由Dubbo fork而來的分支DubboX捐獻回Apache Dubbo；也曾經為公司的重點項目的基石——Apache Mesos進行本地化宣傳，並獲得了由mesosphere官方認可的DOCS宣傳大使的榮譽；也曾在Apache Skywalking的推廣初期幫助它在公司落地等等。在我的認知中，我願意將開源當做是面向全世界技術人員的禮物，它應該可以跨越公司、跨越種族、跨越信仰，讓對技術本身感興趣的人建立連接。
為了尋求更廣闊的天地，一年前我決定出來看看機會。因為能夠做的方向比較多，所以我反而覺得舉棋不定。有公司想邀請我去主導Kubernetes平臺的搭建，也有公司願意讓我去幫助他們做有意向進入Apache的開源項目。但對於我來說，心裡種下的種子始終難以捨棄，投入巨大精力的Elastic-Job和Sharding-JDBC，我非常希望將它們的其中之一推向Apache，成為世界頂級項目。因此，當京東的領導和同事跟我溝通時，我意識到了讓Sharding-JDBC在京東集團生根發芽，並推向Apache國際舞臺，不僅可以讓其對公司基礎設施建設貢獻力量，也可以讓它在國際化舞臺上大展拳腳。這正是我心之所向，因此我放下猶豫，義無反顧的決定加入這個團隊。
擴張 —— 野蠻生長
來到這裡之後，我所面對的是全新的挑戰。Sharding-JDBC還遠未達到京東對分佈式數據庫中間件的需求。從部署架構來講，它是一個jar包，即smart client形態，並不具備上雲的能力；從功能來講，它僅僅是一個分庫分表中間件，缺乏對分佈式事務的處理能力，難以形成功能上的閉環。為了讓Sharding-JDBC快速成長，我決定擴充Sharding-JDBC的範圍，將它升級為一個生態圈，為不同的用戶提供更加多樣化的選擇。
在與領導溝通和交流後，擴展的方向定位到了接入端的擴充以及功能閉環這兩塊。首先要完成的是讓Sharding-JDBC具備在雲上部署的能力，即提供代理端。但是我之前有過使用Netty的經驗，但並沒有開發MySQL協議的經驗，為了能夠儘快驗證這條技術路線的可行性，我全身心投入到MySQL代理端的開發工作中，披星戴月回家已成常態。
在開發過程中遇到了各種問題，例如：對MySQL協議的不熟悉、MySQL面向開發者的官方文檔的部分不完善、缺乏調試經驗等，都使得開發進展步履維艱。經過了無數的嘗試與努力，終於迎來了階段性成果。在一個多星期的全天候的努力付出之後，於2018年春節前夕將基本功能跑通。同時，我利用春節休假的期間將後端的數據分片能力完全掛接到代理端架構中，完全驗證了這條技術路徑的可能性，並提供了初始可用的版本。實際上，開發一個產品的原型，並不需要花費太久的時間，Sharding-JDBC的原型用了兩週的時間就開發完畢，而這次代理端的原型也基本就是兩週，其後續工作更多的是完善。
我一直對Service Mesh架構以及Sidecar模式青睞有加，希望能將Sharding-JDBC
完美的融入Service Mesh中，因此早就有了研究一個數據庫中間層sidecar的想法。春節過後，我將思路梳理成文，並在InfoQ發表《Service Mesh是大方向,那DatabaseMesh呢?》[https://www.infoq.cn/article/database-mesh-sharding-JDBC]。它就像是一塊石子投入平靜的湖面，激起了各種關於Mesh的討論。
在Smart Client、代理端以及Sidecar這三駕馬車的想法漸漸成型之後，Sharding-JDBC這個項目名稱已經不再適合。顧名思義，Sharding-JDBC的寓意是在JDBC
層進行數據分片的產品，隨著接入端的擴展，JDBC已經無法涵蓋它的全部範圍。由於Sharding-JDBC在開源的兩年中，累積了不少群眾基礎，因此，我也很難放棄原有的全部積累，轉而完全從零開始。我曾經想過將Sharding-JDBC作為品牌保留，而將原有的JDBC接入端改名為Sharding-JDBC-Driver，將代理端命名為Sharding-JDBC-Server，並增加Sharding-JDBC-Sidecar模塊，但名稱略有牽強。經過考慮權衡，決定保留Sharding-JDBC這個項目，將其作為整體項目的一個子項目，將代理端的接入端命名為Sharding-Proxy，Sidecar接入端則順其自然地命名為Sharding-Sidecar，由它們共同組成一個生態圈，名字就叫做ShardingSphere，意為分片生態圈。由此，ShardingSphere的全景圖如下：
追尋 —— 厚積薄發
ShardingSphere規劃確定之後，我開始緊鑼密鼓的籌備將它推向Apache基金會孵化器的事宜。在Apache Skywalking發起人吳晟的幫助下，我完成了進入Apache基金會的準備，將
Proposal[https://wiki.apache.org/incubator/ShardingSphereProposal]早早的完成，滿心期待的希望將ShardingSphere一蹴而就地推向Apache。很快，我們聯繫到了一位Apache的導師，Apache Cassandra的Michael。看完Proposal以及項目在GitHub的提交記錄之後，Michael給我的反饋是：我個人在項目中的提交比重過多，超過了80%，Apache項目的社區目標是希望即使項目的初創者休假兩個月，項目也能夠不受影響地持續前行。
這則反饋使我深切地意識到了團隊的重要性。藉此契機，我便開始著手團隊的組建。非常幸運的是，在京東這樣優秀的平臺，有著足夠多對技術充滿熱情的同學。在團隊組建之初就收穫了來自其他各部門的同學的青睞。再加上社招的給力，一個來之能戰的團隊以出人意料的速度組建完成。在團隊成員的共同努力下，ShardingSphere在分片核心、接入端、分佈式事務這幾方面齊頭並進，很快便取得了驚人的成績。在團隊越來越多的發揮協同作戰的力量之後，我更加進一步的理解那句話：一個人前進可以走的很快；大家一起前進才能走的更遠。
在分佈式事務開發的過程中，我們與Apache Servicecomb項目負責人姜寧一拍即合。Apache Servicecomb中的柔性事務Saga非常適合於ShardingSphere，因此我們達成戰略合作，以更好的發揮各自優勢。再加上之前和Apache Skywalking的良好合作關係，APM的集成也完全交由其完成。快速的將資源整合，使得ShardingSphere的進展更加迅速。
收穫 —— 水到渠成
之前短暫的挫折反而讓ShardingSphere迎來了全新的發展。它迅速的完成了與兩個起源於中國的Apache項目的高度整合，在事實上融入了Apache項目的生態圈。隨著團隊不斷的磨合，ShardingSphere對Apache Way的理解也愈加深入，隨著社區越來越開放和成熟，進入Apache基金會孵化器的想法又開始躁動起來。
2018年10月，恰逢Apache基金會的三位導師Roman、Craig、Justin訪華，他們分別在上海和深圳呆一週。懷著對最初夢想的執著，我忐忑的踏上了旅程，希望能說服其中幾人，幫助ShardingSphere推向Apache基金會。
所幸經過了之前的經歷，對於Apache基金會的規則我已基本瞭然於心，與導師們的交流十分愉快。他們三人均對ShardingSphere的評價非常高，並認為ShardingSphere無論是社區，Apache way，項目的規範度，甚至是Proposal的細節，都已經日臻完善，已經無需導師花費額外的精力去輔導。在他們回國後的一週，通過郵件決定由Roman擔任ShardingSphere的Champion，Craig、姜寧以及一直以來與我保持良好關係的來自Mesosphere的創始人Benjamin共同擔任項目的導師。在2018年的雙十一之前一天，11月10日，ShardingSphere正式通過Apache基金會的投票
[https://lists.apache.org/thread.html/88beebeec1aec8c32d331a3957b9eaec5aeee3e4e1bb23664731d048@%3Cgeneral.incubator.apache.org%3E]，成為Apache孵化器的一員。
新的挑戰 —— 知難而進
進入Apache基金會並非結束，而是一個全新的開始。從進入孵化器的那一天開始，ShardingSphere便進入了一個全新的領域，在這個領域中，充滿了未知和挑戰。而面向這些全新的挑戰，ShardingSphere團隊已經打起十二分精神，隨時準備面對困難的洗禮。
如京東某業務由於業務體量巨大，數據庫不可避免地進行了水平拆分。拆分之後的數據節點規模達到了十萬級別，是極度少見的金融級、高併發、海量數據並存的應用系統。為了追求性能極致以及代碼的可控性，它之前是在業務框架中，根據分片鍵替換數據庫和表名稱進行分片的。
隨著業務的發展，通過業務框架進行分片的方式，使得代碼的維護成本不斷攀升。ShardingSphere在經過了大量系統的驗證之後，理所當然的成為了這一業務的數據分片中間件的首選方案，ShardingSphere團隊也非常願意幫助業務團隊解耦業務和底層技術代碼，緩解開發工程師肩上的重擔。
雖然經歷了大量系統的檢驗，ShardingSphere已經相對成熟，但面對其體量在全國乃至世界上均屈指可數的王牌級產品，仍將是一次嚴峻的考驗。而事實上，對接工作也確實不是一帆風順，遇到了很多在以往系統中不曾遇到的深層次問題。在經過一個個不眠之夜後，ShardingSphere已經平穩的在其生產環境運行了幾周，性能與原生JDBC幾乎一致，GC次數與資源消耗也未見異常。
在已經到來的2019年，ShardingSphere將迎接更大的挑戰，對內更加全面的服務於公司，對外則致力於打造業界一流的解決方案，成為國際化技術產品翹楚而努力。
結語
在一年的前進歷程中，ShardingSphere經歷過挫折，也獲取了短暫的成功，但我們不會站在歷史的功勞簿上，而是要不斷前進。獲得金項獎提名是對ShardingSphere團隊以及社區的巨大認同。我們會將它當做前進的動力，繼續不斷的精進自己。謹以此文記錄並感謝ShardingSphere團隊和社區在過去一年來的努力和付出，並希望它能在今後為京東貢獻更大力量，並在業界和國際化舞臺上綻放風采。
