數據技術嘉年華等你來
潘娟，京東金融高級DBA，主要負責京東金融生產數據庫運維及數據庫平臺、中間件開發工作。多次參與京東金融6.18、11.11大促活動的護航工作。曾負責京東金融數據庫自動化平臺設計與開發項目，現專注於Sharding-Sphere分佈式數據庫中間件開發。樂於在數據庫、自動化、分佈式、中間件等相關領域進行學習和探索。
本文分爲兩部分。第一部分是美少女戰士潘娟的成長曆程自述，如何從一個小白成長爲一顆技術新星，這個歷程值得將入和初入職場的大家學習；第二部分是 Sharding-Sphere 的創始人 張亮 先生的撰文，闡述了這一開源中間件的前世今生。
潘娟將於2018數據技術嘉年華爲大家分享“Sharding-Sphere 分佈式數據庫中間件雲架構演化”主題，敬請期待。
起於DBA
- 契機
誠實講，我一直不清楚自己想做什麼。於是，研究生臨近畢業，麻木遊離在各大公司的面試中。感謝和啓榮 (劉啓榮，現京東金融運維副總監)的相遇，讓我開啓了DBA的航程。啓榮老大是個高情商、接地氣的老闆。我是第一次遇到面試談人生問題，不告訴面試結果，一言不合就讓我來聽他講課的面試官。當時他講到的數據庫與DBA的世界，以及那種自由又充滿生機的互聯網交流氛圍，讓我意識到有些人是與衆不同的，有些地方是心之所向的。
- 日常
DBA的工作是嚴謹、有趣、辛苦的。一個初出茅廬的丫頭，突然闖入一個全新數據庫世界，又空降在京東這樣量級的平臺上，所謂的數據庫技術、業務架構、系統的視野與互聯網的眼界，就像山呼海嘯一樣奔騰而來，以至於產生了一種真的扛不住的無力感。但是，爲我抉擇的負責，爲大家給予我信任的回報，持有這樣心理的我，開始瘋狂地像海綿一樣吸收着這海洋般的知識，並不斷提升着自己的認知。一整年的週末都躲到公司無人的會議室啃着《MySQL技術內幕:innodb存儲引擎》、《高性能MySQL》、工作筆記、Shell編程技術，去培養自己的數據庫知識及運維技能。因爲我知道，當一個人沒有足夠實力的時候，只有時間和努力才能讓她蛻變，以及獲得別人的尊重。
作爲組裏唯一的妹子，感謝他們只是把我當漢子用，而不是當牲口用。很多夜間運維的活兒儘量不給我。不過我真心覺得，只有這些真刀真槍的工作才能見識真正的戰場，只有這樣的戰場才能讓戰士迅速成長。所以我投入了這無盡的戰鬥中，看到過凌晨3點的月亮，也哭訴過整夜遷移無盡頭的折磨和無奈。而第一次失誤導致用戶收到亂碼短息、被投訴造成P1級別(最高P0)故障時，也終於知道什麼叫電話被領導打爆。一個人自責地在冬天回龍觀的大街上嚎啕大哭，不知所措，着急地想抽自己兩嘴巴子！
現在覺得，那場景非常類似電影裏小姑娘被男朋友甩了的經典劇情。不過那種疼到骨子裏的自責確實讓我真切地感受到生產環境的重要性，以及DBA工作的極盡嚴謹，我輸入的一條命令背後是千千萬萬與業務緊密相關的數據，是無數用戶的使用與體驗。好吧，更是我甩給老闆的鍋和整個部門戰友們的KPI。感謝那一次次讓我頭破血流的南牆，因爲它讓我知道了做事的深淺與尺度，讓我擁有了能夠面對更大挑戰的勇氣和力量。
- 總結
這段時間讓我成長爲一個合格的DBA。除了掌握數據庫知識體系及周圍生態外，還積累了大規模數據庫運維經驗。此外，所謂的風險意識、快狠準和粗中有細的運維意識也開始慢慢建立。但我覺得有兩個能力非常重要，那就是：作爲下屬對上級命令的絕對執行力，以及面對嚴苛環境的抗擊打能力。
承於DevOps
- 契機
人工運維以及腳本運維已經無法滿足激增的業務發展，對數據庫運維要求出現多元化、多維度的需求。同時運維的邊際效益日益凸顯，於是整個運維部門開始向DevOps轉變。而當時負責數據庫工單系統自動化平臺建設的前輩突然被借調，於是該項目基本停滯。那時，我心裏小惡魔非常想讓我主動請纓負責這個項目，但當時的我並沒有多少項目開發經驗，人微言輕。可是，依據當時部門發展風向，自動化是大勢所趨，只有順勢而爲，纔能有機會獲得大家的認可和肯定，此時若主動出擊，便有可能危中求機。
再靜心分析，前期積累的大規模數據庫運維經驗，可以讓我理解這個項目的核心需求和期望，而曾經和研發及運維同事的交往基礎、妹子獨有的溝通優勢又能推動項目推廣。於是在得到歡哥(周歡，現網聯數據庫負責人)鼓勵和授權後，開始動手！正如那句話所說：並不是所有的比賽，都能允許你做好十足的準備。面對危機，有時候嘗試放手一搏，可能會帶來希望和轉機。
- 日常
沒有Python經驗，我就死啃Python開發，並換工位到組裏Python大神旁邊，方便隨時請教。大半年的時間基本處於封閉開發狀態，實行小步迭代的敏捷開發方針。在地鐵上分析需求、設計方案、構思代碼。在公司跟老闆明確需求、開發功能、解決Bug。週末則利用業務低谷，進行上線測試。此外，還要跨部門合作和推廣。剛開始的時候，工作推動很難有進展。因爲別人根本不聽你說什麼，任你焦急、憤怒，全都無濟於事。越是想着如何說服對方，越只能得到升級版的爭吵。
後來漸漸意識到，不要嘗試與他人爭對錯，因爲根本沒有對錯。如何通過協商、退讓達到雙方共贏、雙方滿意的目的纔是王道。同時，啓榮哥告訴我互聯網的三不要精神：不要錢、不要臉、不要命，我覺得很有道理。在一次次的溝通和打臉後，信任逐漸被建立起來了。對方尊重你，是尊重你的付出，尊重你的能力，尊重雙方的利益。最終，數據庫工單平均執行效率提高70%、非法工單攔截率爲30%、工單正確執行率保持在99.99%的報告終於爲這大半年的付出畫上圓滿的句號。
- 總結
這個階段依據部門風向，從運維DBA轉向數據庫運維開發DBA，積累了項目開發經驗，未卜先知的情況下，竟爲後續轉行打下基礎。此外，跨部門溝通合作、推廣也讓我懂得了要學會選擇和衡量、共贏與合作，並保持樂觀平和的心態。
轉於JAVA
- 契機
數據庫自動化工單平臺已取代人肉工單操作，發展趨於平穩，同時深感自己的圈子和視界太狹隘。就在這樣渾水摸魚的時候，啓榮老闆給我介紹了新的男神：張亮，原噹噹架構部負責人，熱愛開源，懷揣着將Sharding-Sphere打造爲業界一流的金融級開源分佈式數據庫中間件的夢想加入了京東金融。可能考慮到我DBA的知識積累和研究生英語水平，當然最重要的是我不要臉的人美心善。所以，讓我協助亮哥將Sharding-Sphere官檔翻譯成英文。
開源、數據庫中間件、微服務、分佈式事務、數據庫治理……一大堆新鮮的名詞衝進我貧困的大腦，打開了更廣闊世界的天窗，並對我產生強大吸引力。此外，當時平滑的成長曲線讓我迫切想打開自己狹隘視野的枷鎖。於是，我開始仔細分析現狀：開源、分佈式、微服務、Java開發等對我來說又是個全新領域，轉行可能將拋棄部分積累的數據庫行業積澱。
不過，這些數據庫運維經驗，對全是Java開發以及架構出身的團隊來講，未嘗不是一種互補的優勢。同時，前期數據庫自動化工單平臺項目也能幫我做跨行的平滑過渡。思及此時，我終於跟啓榮探討了人生問題和情感問題，並轉向了金融級開源分佈式數據庫中間件Sharding-Sphere的開發。
- 日常
前期對官檔的翻譯工作，讓我對Sharding-Sphere的核心功能，產品定位有了比較全面的理論層面認識。於是開始從源碼層面入手，修改小的Bug，編寫測試用例，到後來負責一整塊的內核功能。在亮哥的指導下不斷深入Sharding-Sphere，並對編碼又了新的理解。它絕對不是故步自封，隨心所欲地編寫，而是存在規則和邏輯的簡潔優雅編碼之道以及重構迭代的價值意義。函數與函數之間的空行、段首多少空格、變量名字命名這些在常人眼裏無足輕重的事情都會被亮哥格外重視，他對設計和代碼120%的要求讓我對細節有了100%的注重。
從GitHub代碼提交記錄可以看出整個變化的步伐，從平緩的小步改造，到後期的模塊開發（見下圖）。坐在工位上看似發呆地進行思考設計、邏輯整理。獲得對整套業務邏輯的深刻理解，便覺得酣暢淋漓；通過DBA視覺和亮哥交流需求，得到新的啓示和想法，便覺得頗有意義；而更多時候是一個人進入所謂的”心流”，將腦子裏勾畫出架構用代碼去漸漸實現，那種忘記周遭，沉迷於代碼與音樂世界，又讓人感覺時光飛逝。當真正想做一件事情、對其充滿興趣的時候，纔會知道什麼叫樂此不疲。
此外，也開始逐漸走向臺前，對外分享，建立影響力。通過認識大牛，同樣開闊了自己的眼界並培養行業靈敏度。京東在線平臺的分享擴大了Sharding-Sphere內部影響力；參加火幣、餓了麼、貝殼金服的交流分享則瞭解大家對數據庫中間件的認識和需求；擔任2018 ODF數據庫大會的主持，重新看到數據庫的行業發展；擔任ServiceComb交流活動的主持，則能感受到開源的力量。
一次次活動經驗，也是一次次小小的積澱，慢慢讓自己懂得了分享的價值，並建立對外影響力。感謝各位大牛的提攜之恩，也感謝啓榮總，亮哥給予的一次次分享交流的機會。其實，每個人都有自己獨特的優勢，多多分析總結，因地制宜，合理運用，纔有可能百尺竿頭更進一步。
部分分享照片
- 總結
這一階段對內低頭磨鍊開發之道以及學習架構重構，並瞭解開源、分佈式、中間件的架構體系。對外積極交流分享，培養行業影響力，鍛鍊表達能力。對時間自由掌控，對事情要求極致。
覆盤
當下，仍需不斷對所在行業的寬度、深度進行積累。在數據庫中間件、DataBase Mesh、開源方面投入主要精力。在亮哥帶領下將Sharding-Sphere做到理想高度(P.歡迎關注https://github.com/sharding-sphere！)。同時，也希望自己多思考，多磨礪下品性，把控前進方向，明確目標。然而現實很骨幹，淺薄的我還在探索之中。對於未來，如果你的高度不足以支撐你當下的選擇，不如借鑑下大牛和前輩的思考，站的在那個高度的他們的指點或許會給你打開新的天窗。
一路成長，總結其原因，我覺得主要有三大點。第一，感謝我上面提到的各位老闆能給予我機會、能放權讓我去做事情、能寬容我的傲慢與偏見；第二，感謝京東的大平臺，能讓我結識到這些大牛前輩，能讓我看到不斷變化進步的世界，並推動我不得不去自我提升；第三，則是感謝自己，懂得思考並及時按照發展調節方向，唯有全力以赴、放手一搏才能危中求機。
我會在這個領域走多遠多高，我能擁怎樣的生活， 能寫什麼樣的故事，又能和哪些人一路相伴？對於未來，現在的我也同樣沒有答案。只是，曾經一步步紮紮實實的探索確實讓我有了更堅強的意志和勇氣去面對必須要面對的現實。願這一路的小小故事，能給正在閱讀的你一些思考和想法，並引起你的共鳴。倘若如此，也不枉這個十一假期一次次的碼字和修改，也不枉右軍老師的邀請。我相信每個人都有自己的故事，每個人都是獨特的你！
Sharding-Sphere發展史
本篇爲InfoQ中文站供稿
原文鏈接：http://www.infoq.com/cn/news/2018/10/Sharding-Sphere-growth-process
- 前序
關注開源圈的同學可能知道，Sharding-Sphere的前身是Sharding-JDBC。
- 起源
Sharding-JDBC是一套擴展於Java JDBC層的分庫分表中間件，最初起源於噹噹的內部應用框架ddframe中的數據庫訪問層組件。由於分庫分表需求的相對普遍，並且具備獨特的生命力與關注度，因此將其抽離成爲獨立的項目，命名爲Sharding-JDBC，並於2016年初開源。
Sharding-JDBC的最初目標是透明化分庫分表所帶來的複雜度，包括數據源的管理、根據業務進行的SQL改寫等。作爲使用Java語言開發的ddframe框架中的一部分，Sharding-JDBC順其自然的選擇了JDBC作爲其分庫分表擴展點的接入端。正如其名稱Sharding-JDBC所昭示，它是在JDBC層進行Sharding（分庫分表）的產品。
- 核心功能完善
Sharding-JDBC在其後的一年中有條不紊的發佈了1.x的6個大版本更新，分別是：
- 奠定了SQL解析、請求路由、SQL改寫、SQL執行和結果歸併的分庫分表的核心模型的1.0.x
- 原生支持Spring和行表達式的1.1.x
- 最大努力送達型柔性事務的1.2.x
- 讀寫分離的1.3.x
- 分佈式主鍵的1.4.x
- 全新SQL解析引擎的1.5.x
- 分佈式治理
在分庫分表功能逐漸成熟之後，在2017年，Sharding-JDBC進入了2.x時代。2.x主要實現的功能是數據庫治理，它可以通過註冊中心提供對配置的集中化和動態化，以及對數據庫和應用進行禁用和熔斷。在此基礎上，還增加了面向OpenTracing協議的鏈路追蹤能力，並且達成了與國內優秀的APM產品Apache SkyWalking(https://github.com/apache/incubator-skywalking)的合作協議，將Sharding-JDBC的追蹤數據對接入SkyWalking，並讓SkyWalking將採用Sharding-JDBC作爲其存儲引擎成爲可選項。
至此，分庫分表、分佈式事務和數據庫治理都有了簡單的雛形。
- 發展
隨着雲原生的普及，應用上雲和對異構語言的無差別支持漸漸成爲當今主流。僅支持Java的Sharding-JDBC已經無法滿足雲原生的全部需要，在業界一直爭論不休的在客戶端（JDBC或其他語言客戶端）還是服務端（Proxy）進行分片的優劣，也未有定論。
- 改名、之後再踏征途
2018年春節前夕，隨着核心開發人員的加盟，京東數科（當時還叫京東金融）加入了Sharding-JDBC的開發工作中，並將其定位爲面向雲化的數據庫中間件。在客戶端進行分庫分表的Sharding-JDBC，雖然可以作爲輕量級微服務框架靈活應用，但卻沒有作爲雲接入端進行統一管控的能力。因此，一個Proxy接入端呼之欲出。
Sharding-JDBC這個名字在過去的兩年中獲得了大量的積累，已經具備一定的辨識度，開發團隊並不希望完全放棄掉這個名字。因此，最初將新的代理端產品命名爲Sharding-JDBC-Server，而將原有的Sharding-JDBC改名爲Sharding-JDBC-Driver。
經過了反覆的權衡，我們發起了社區投票。最終決定保留Sharding這個關鍵詞，將項目的名稱正式改爲Sharding-Sphere，意爲分片生態圈。無論是分佈式事務還是多數據庫的治理，其本源都是分片；若採用單一的無分片數據庫，後續功能都將無需存在。分片生態圈由根據不同的接入端，由3個子項目組成，它們是基於JDBC客戶端接入的Sharding-JDBC（即原有項目）、基於代理端接入的Sharding-Proxy（今年的重點更新）、以及基於Sidecar模式接入的Sharding-Sidecar（明年的產品規劃）。
3.0.0於此刻正式起航，主要目標是將Sharding-JDBC的能力完全移植入Sharding-Proxy，使其具備支持異構語言的能力。雖然分片的核心邏輯並未變化，但相比於Sharding-JDBC，Sharding-Proxy有兩個難點是需要攻破的。
第一個難點是數據庫協議的實現。將代理端僞裝成爲一個數據庫，能夠將接入的成本降至最低。Sharding-Proxy選擇最常用的MySQL協議做爲首先支持的數據庫協議，並完整的實現了所有的應用程序運行時所需的協議包（如：COM_QUERY、COM_STMT_PREPARE、COM_STMT_EXECUTE）。目前對於管理端使用的一些協議包還未全部實現。
第二個難點是通信框架。JDBC層的通信是由各個數據庫驅動提供商通過BIO的方式實現的，雖然吞吐量欠佳，但卻容易實現。代理端爲了更高的吞吐量，需要採用NIO的方式。Sharding-Proxy採用Netty作爲通信框架，在接入層前端實現了完全無鎖的異步通信。目前接入端連接後端數據庫時，仍然採用JDBC的方式，未來會將其完全改爲Netty異步通信的方式，進一步提升吞吐量，達成前後端完全無鎖通信的目標。以下是Sharding-Proxy的架構圖：
在2018年5月，基本可用的Sharding-Proxy隨着Sharding-Sphere 3.0.0.M1發佈。
同時，由於多家公司共同參與開發，Sharding-Sphere決定成立社區，將著作權完全歸屬至Sharding-Sphere社區，併成立了項目管理委員會（PMC），並且也完善了貢獻者和提交者的晉升制度。
隨着新的里程碑版本，Sharding-Sphere申請了全新的域名，並重新制作官網，重裝發佈。
- 擴大範圍、加強合作
Sharding-Sphere的更名，不僅僅是接入端的增強。作爲分片生態圈，更完善的分佈式事務和數據庫治理，也納入了項目範圍。
Sharding-Sphere將原有的分庫分表功能更名爲數據分片，內容包擴核心流程、讀寫分離和分佈式主鍵。Sharding-Sphere的核心流程模塊的幾個重點部分可以通過一張圖幫助用戶理解，下面分別是路由引擎、改寫引擎、執行引擎和歸併引擎的剖析圖：
Sharding-Sphere對分佈式事務進行了重新的設計和定位。廢棄掉原有的最大努力送達型柔性事務，取而代之的是採取剛柔並濟的實現方案：同時支持XA的強一致事務，以及基於Saga的最終一致性事務，基於消息的最終一致性事務也在規劃中。
分佈式事務模塊將定位從自研轉向整合，即整合現有的成熟事務方案，爲本地事務、XA事務和柔性事務提供統一的分佈式事務接口，並儘量彌補各個方案對數據庫層面的缺失。分佈式事務模塊提供一套SPI事務處理接口，能夠無縫對接分佈式事務的各個實現方案。分佈式事務模塊的架構圖如下：
Sharding-Sphere經過比較分析，選擇採用Apache ServiceComb的分佈式事務解決方案來實現柔性事務， 通過在ServiceComb Saga執行引擎基礎上擴展sql執行模塊，實現了基於分佈式Saga的事務執行和回滾功能。
分佈式事務模塊將於3.1.0的版本發佈，目前仍處於緊張的開發階段。
在數據庫治理方面，Sharding-Sphere全數保留了之前的功能，並提供了全新的APM鏈路追蹤數據，可以通過SkyWalking更直觀的觀測Sharding-Sphere。但目前仍未包括數據庫彈性擴縮功能，該部分功能將於明年規劃。
在高速發展的同時，Sharding-Sphere迎來了新的合作伙伴——翼支付。翼支付成立了創新中心部門，並投入開發資源加入到了Sharding-Sphere的開發團隊。這使得Sharding-Sphere的開源社區更加多元化和健康成長。Sharding-Sphere屬於社區而非公司，因此歡迎有興趣參與開發的公司一起打造更加多元化的社區和更加完善的項目。
- 上線、然後發佈
在Sharding-Sphere的旗下產品Sharding-Proxy逐漸成熟的同時，京東數科當仁不讓的成爲了第一個吃螃蟹的人。京東數科將部分核心業務系統通過小流量 -> 大流量 –> 全流量的流程切換到Sharding-Proxy，目前Sharding-Proxy在生產環境中已經管理並運行着萬級別數據節點。
在經受考驗之後，隨之而來的Sharding-Sphere 3.0.0.M2、3.0.0.M3和3.0.0.M4相繼發佈。在經歷了大量的性能調優和功能完善之後，終於在10月24日的程序員節發佈3.0.0穩定版。在經歷了京東數科嚴酷的生產環境驗證後，相信Sharding-Sphere可以成爲架構師們進行技術選型時的其中一個參考。
- 面向未來
Sharding-Sphere 3.0.0的發佈並非終點，而是新的起點。3.1.0已經在同步開發，也將於不久的將來面世，提供更加優化的分佈式事務解決方案。計劃於明年開啓的4.0.0對Sidecar模式的接入端以及自動化的彈性伸縮功能也完成了初步規劃。Sharding-Sphere的線路規劃如下圖：
- 如何獲取
Sharding-JDBC
<groupId>io.shardingsphere</groupId><artifactId>sharding-jdbc-core</artifactId><version>3.0.0</version>
Sharding-Proxy
docker pull shardingsphere/sharding-proxy
源碼
https://github.com/sharding-sphere/sharding-sphere https://gitee.com/sharding-sphere/sharding-sphere
官網
http://shardingsphere.io