技术访谈：Sharding-JDBC 未来将更加多样化

Posted 2021-05-01 点亮架构

Sharding-JDBC 是当当网开源的适用于微服务的分布式数据访问基础类库，完整的实现了分库分表，读写分离和分布式主键功能，并初步实现了柔性事务。从 2016 年开源至今，在经历了整体架构的数次精炼以及稳定性打磨后，如今它已积累了足够的底蕴。它是如何变得如此优秀？未来，它还会带来哪些新的突破呢？本期【开源访谈】邀请到当当架构部总监张亮，为大家介绍 Sharding-JDBC 的发展历程，分享职业发展经验。

记者｜开源中国

受访者｜张亮

编写｜@OSC源创君

问答

请简单介绍一下您自己，如，学习和工作经历

我很高兴能接受这次采访。我目前就职于当当架构部，负责公司的中间件研发和容器调度编排平台的搭建。除了处理公司内部的事务，也负责当当对外开源和分享的相关事宜。

我大学是在爱尔兰读的书，毕业后一直在外企工作。我个人对技术比较感兴趣，在技术选型方面也比较激进，但外企的技术相对稳定。因此我在 2012 年的时候开始转型做互联网，在当当之前就职于百度，我个人比较喜欢互联网这种快速迭代的节奏和浓厚的技术氛围。

当当网于 2016 年开源了 Sharding-JDBC

并取得了一致好评，选择开源的初衷是什么？

谢谢夸奖。Sharding-JDBC 开源至今虽然得到了一些关注，但是考虑到数据分片解决方案的复杂性，它未来还有大量的事情要做。

Sharding-JDBC 是从当当的一个内部系统演化而来，它的前身叫 dd-rdb，是当当的应用框架 ddframe 的一个组成模块。dd-rdb 采用 spring 的动态数据源和简单的 SQL 解析来实现分库和分表的功能，并提供 DAO 的标准化模板。随着当当对数据分片的需求越来越多，单纯的 dd-rdb 已无法再满足，因此将其标准化模板和分片功能独立出来的呼声就越来越高。

我们在做 Sharding-JDBC 之前做了很多调研，希望能够找到开源数据分片的解决方案。但调研之后发现目前开源解决方案的完整性和成熟度都难于完全满足互联网公司的需求，所以只能自研。

关于开源的初衷，主要从三方面考虑。一是希望可以让更多优秀的程序员看到我们的代码，相互促进和交流；二是在调研时受到了社区开源项目的启发，因此我们愿意回馈社区；三是来调动当当内部工程师的积极性，要知道，工程师们对内部框架的兴趣和开源框架的兴趣是完全不同的。

Sharding-JDBC 从开发伊始就以开源为目标，因此从大到整体架构设计的合理性，小到代码的可读性和优雅性，都及其花费精力雕琢，核心开发人员的积极性也非常高。

Sharding-JDBC 在 2017 年取得了哪些进展？未来的开发计划是什么？

从 2016 年开源至今，可以划分为两个阶段，这两个阶段恰好可以按照自然年去划分。

2016 年以及 2016 年以前的 Sharding-JDBC 属于初级阶段。Sharding-JDBC 虽然于 2016 年初开源，但它的核心开发基本是 2015 年完成的，初始版本大概开发了 3 个月左右。整个 2016 年，Sharding-JDBC 都在完善功能的阶段，每次大版本的发布都是一个新的功能点，主要有分库分表、配置多样化、柔性事务、读写分离和分布式主键。在 2016 年底，Sharding-JDBC 的 1.4.2 版本的发布标志着第一阶段的结束。

2017 年上半年 Sharding-JDBC 进入了一个相对静默期，因为我们觉得之前版本太过注重功能，导致最核心的解析模块难于控制。因此，我们花费了近半年的时间，以完全自研的方式重写了 SQL 解析引擎，并根据全新的解析引擎重新设计了 SQL 路由、SQL 重写和结果归并模块，让它看起来更加浑然一体。并于 2017 年的 6 月份发布了 1.5.0.M1 这一里程碑版本，使得 Sharding-JDBC 的架构得到进一步改善，稳定性和可控性也都得到了有效的提升。虽然目前 Sharding-JDBC 已经发布了 2.x 版本，但是我们愿意认为 1.5.x 版本才是 Sharding-JDBC 脱胎换骨的里程碑。

在不久之前，确切的说是两个月之前，2017年10月，Sharding-JDBC 正式发布了 2.0.0.M1 版本。在 2.x 版本中，Sharding-JDBC 完全产品化，完全摆脱掉了 dd-rdb 的束缚，将包名从 com.dangdang.ddframe.rdb 改为 io.shardingjdbc。我们希望全新的包名，让 Sharding-JDBC 能够更加中立化的发展，汲取社区更多的支持。

由于 1.5.x 使得 Sharding-JDBC 在 SQL 兼容性相关部分已经趋于成熟，2.x 我们将目光放在了微服务开发框架之上，增加了治理，配置动态化等功能。虽然当今微服务概念火热，Spring Cloud 等微服务框架也收到很多关注，但在数据层面，并没有一套行之有效的配套方案，希望 Sharding-JDBC 可以弥补这一领域的缺失。

关于未来开发的计划，先来澄清一件事。很多不是 Java 开发背景的同学会吐槽为什么 Sharding-JDBC 是一个应用层的框架，而不是独立部署的 Proxy，其实一个很重要的原因就是它的前身，dd-rdb 是应用框架。因此未来 Sharding-JDBC 也会多样化，将提供 Proxy 的版本。另外除了 Proxy，也会提供 Agent 版本。所谓的 Agent 版本与现在流行的 Service Mesh 模式较为相似，Service Mesh 通过 sidecar 去代理和管控流量，而 Sharding-JDBC 希望通过同样的sidecar的方式代理和管控 SQL，以做到非侵入和跨语言的 Data Mesh。

您现在除了架构技术还有管理方面的工作，您是如何平衡协调的？

管理架构部的工作和管理项目不同。

架构师或者中间件开发工程师，有独立自主的想法以及正确的眼光比较重要。因此在大部分的管理工作中，我会尽量花时间去沟通和把控其他工程师或架构师做事情的方向选择层面。一旦确认了方向的正确性，做事情的细节我就不再会过分关注，而是给予他们工作的自主权。工作交付之前会约定几个里程碑，通过里程碑来验收工作成果，以把控工作的方向和节奏。在管理之外，我会加入到大家之中，一同投入到开发的工作。我比较享受写代码的乐趣。

在实际工作中，您是如何推动架构工作的进行，或帮助团队架构同学的成长呢？

在当当进行底层基础架构的推动，我们主要采用的方式是兼容和增量。以 Sharding-JDBC 来举例，它是完全兼容 JDBC 协议的，因此开发人员完全不用改动他们的代码，就可以轻松使用 Sharding-JDBC，而 Sharding-JDBC 给他们带来的增量是显而易见的，即再也不用考虑数据分片的相关事宜，只要将多库多表当成一个逻辑库表使用即可。再举一个例子，Elastic-Job 是当当开源的另一个项目。当当在分布式架构向平台化迁移时，之前使用 Elastic-Job 的开发团队，可以完全使用之前的接口，业务应用无需改动，即可将其放入基于 Mesos 的作业云平台，带来的增量是应用开发再也无需关注硬件资源和监控配置，并且作业云带来了作业的自愈能力。

帮助架构同学的成长问题，主要是提供足够开放的平台。现在各种社区分享非常多，如果想去学习，想去进步，并不会发愁找不到资源，因此我能做的就是让大家保持开放的心态，参与交流，参与分享。

听说您在如何写出具有展现力的代码方面有较多研究。能否给大家传授一些技巧？

推荐两本如何写代码的书籍，《重构》和《代码整洁之道》，我个人是从读这两本书，遵循其中的一些理念，然后渐渐的觉得写好代码是一件这么有意思的事情。

我所认同的代码分为两个级别。

级别一是我给自己的代码定制的准入标准，主要要求两点，可读和整洁。可读要求代码没有阅读障碍，像读自然语言一样阅读代码；整洁包括风格保持一致，无多余和重复代码等。

级别二则更难达到一些，评判的标准是优雅。它不但要求代码能够像自然语言一样易懂，还能够像读诗或散文一样心旷神怡，使代码的整体结构和具体细节浑然一体。

从事架构相关工作多年，您拥有非常丰富的职业经验，能否为中国的开发人员提供一些关于职业发展方面的建议？

我觉得技术人员应该保持对技术的好奇心和独立思考的能力。

IT技术发展太快，无论是深度还是广度，想 100% 了解是不可能的，但是也没必要自己为自己设置一道墙，来划分什么是该学的，什么是不该学的。技术的积累不是一次性的，经过大量的积累才能够在一定的条件下得到催化和爆发。因此，请保持强烈的好奇心，尽量多关注一下为什么。

独立思考的能力也是技术人员的必备素质。它也可以等同于耐心和敬畏精神。面对一项技术，如果它短期内展现的行为与自己的预期不符合，不应该急躁和草率的认为是别人的问题，最好静下心来从自己的方面多找找原因，如是否理解的有偏差等。现在社区很发达，很多经验不多的工程师也可以接触到各种大牛。希望处在快速成长中的工程师能够通过自己的思考而提出真正有价值的问题，而不是 Google 到的问题。

来源：开源问答

注明：本文已经授权转载，如想转载，请联系原作者。

微信ID: LightenArch

长按左侧二维码关注