嘉年华专访 | 我有故事，你有酒吗？
数据技术嘉年华等你来
潘娟，京东金融高级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