摘要
张亮，数据库管理部资深架构师，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/...]。它就像是一块石子投入平静的湖面，激起了各种关于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/incub...]早早的完成，满心期待的希望将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/thre...]，成为Apache孵化器的一员。
新的挑战 —— 知难而进
进入Apache基金会并非结束，而是一个全新的开始。从进入孵化器的那一天开始，ShardingSphere便进入了一个全新的领域，在这个领域中，充满了未知和挑战。而面向这些全新的挑战，ShardingSphere团队已经打起十二分精神，随时准备面对困难的洗礼。
如京东某业务由于业务体量巨大，数据库不可避免地进行了水平拆分。拆分之后的数据节点规模达到了十万级别，是极度少见的金融级、高并发、海量数据并存的应用系统。为了追求性能极致以及代码的可控性，它之前是在业务框架中，根据分片键替换数据库和表名称进行分片的。
随着业务的发展，通过业务框架进行分片的方式，使得代码的维护成本不断攀升。ShardingSphere在经过了大量系统的验证之后，理所当然的成为了这一业务的数据分片中间件的首选方案，ShardingSphere团队也非常愿意帮助业务团队解耦业务和底层技术代码，缓解开发工程师肩上的重担。
虽然经历了大量系统的检验，ShardingSphere已经相对成熟，但面对其体量在全国乃至世界上均屈指可数的王牌级产品，仍将是一次严峻的考验。而事实上，对接工作也确实不是一帆风顺，遇到了很多在以往系统中不曾遇到的深层次问题。在经过一个个不眠之夜后，ShardingSphere已经平稳的在其生产环境运行了几周，性能与原生JDBC几乎一致，GC次数与资源消耗也未见异常。
在已经到来的2019年，ShardingSphere将迎接更大的挑战，对内更加全面的服务于公司，对外则致力于打造业界一流的解决方案，成为国际化技术产品翘楚而努力。
结 语
在一年的前进历程中，ShardingSphere经历过挫折，也获取了短暂的成功，但我们不会站在历史的功劳簿上，而是要不断前进。获得金项奖提名是对ShardingSphere团队以及社区的巨大认同。我们会将它当做前进的动力，继续不断的精进自己。谨以此文记录并感谢ShardingSphere团队和社区在过去一年来的努力和付出，并希望它能在今后为京东贡献更大力量，并在业界和国际化舞台上绽放风采。