做中间件的这两年总结（201704-201905）

新的篇章即将拉起，是时候给自己的这两年来个总结了。

一、篇前总结

这两年，从北京来到了杭州。从一个北漂变成了杭漂，买了房，买了车，养了条柯基，在这座江南城市生了根。父母健康，家庭和睦。日子过得温馨，感谢父母，感谢媳妇。

这两年，完成了研究生的课程，通过了研究生的答辩。不枉我们杭州北京来回跑，飞机高铁卧铺的来回切换。每次都从南京转车，一晚卧铺的卧铺到北京。飞机取消了好几次。在学校前面的宾馆住了好多次，成了他们的VIP。认识了很多其他行业的人，加了很多其他的非技术群，开阔了眼界，不再局限于技术的小圈子里。坚定了，只有做实业，才能兴国的理念。

这两年，呆在了一家公司。见证了公司业务的不断发展，也见证了一些业务的失败。成功的原因很多，失败的原因也很多。真实见证了研究生老师所说的“四拍”：拍脑袋做决定、拍胸脯打包票、出了事情拍大腿、最后拍屁股走人。

二、做中间件

在来这家公司之前，对做中间件还是满怀憧憬的。当时，做了几年的业务，被产品、测试各种需求，搞的头都大了。心想，一定要做技术底层的东西，不要再做这些乱七八糟的需求了。相信很多同学也一定有这样的想法，觉得做中间件可以更加深入技术底层的东西，我可以告诉你，是的，你有时间看更多的源码了。不用天天被产品和测试追着，被项目经理追进度了，因为都需要你自己把控。

但是，也有各种烦心事。

这两年，做了两年中间件。说是做中间件，其实中间经历了各种坎坷，方向也变了不少。说实话，做中间件，虽然看起来更加偏技术一些，但是比做业务来说更加心累，承受了更大的压力。因为中间件是为业务负责的，不能出错，一旦出错，就是基础设施出了问题，基本上就是P0的故障了。

做中间件，自己就是产品经理、项目经理、测试、开发、运维，得自己去收集需求，去挖掘需求，要有一定的技术前瞻性，能够对标业界的标杆产品，要能推动中间件的推广。也要能抗事，因为业务方的需求千奇百怪，你得去满足他们。

做中间件很烦，很难有成果，不管大厂小厂都一样。听说大厂的中间件就是客服，小厂的中间件基本就是开源的拿来改改，没有太大的成就感。

三、这两年做了啥

我这两年，主要做了几件事。

3.1 elastic-job的推广

来的时候，公司的定时任务都是单机quartz的，相当危险。也是因为当时的业务量不大，所以单机也就单机跑着了。进来的第一件事情，就是研究了下elastic-job，让大家把定时任务都迁移到了这个上面。很可惜的是，由于开发者从当当离职了，elastic-job基本上不再维护了。不过稳定性还是能够得到保证的。这两年，没出什么问题。中间有个小插曲，业务方对elastic-job的分片理解不够透彻，导致现在很多系统的定时任务分片数还是1，基本上也是单机运行，不过有个故障转移的能力。因为业务方在原来的基础上，封装了一层，里面写死了分片数。开源框架里面的各种概念，还需要不断地宣贯，业务方才能运用到他们的业务逻辑代码中。目前公司所有的定时任务，都已经接入了elastic-job。

3.2 延迟队列

这件事，是和elastic-job是同一时间做的，但其实他们是两件事情。延迟队列的需求，来源于业务方，具体的场景有不少，有兴趣的同学可以自己网上搜搜，简单的基于redis的zset实现了下。后来业务方也自己实现了一套，原理类似。可以看出来，业务方同学也喜欢自己造轮子。

3.3 Kafka和Kafka监控

公司的消息队列选择，据说经历了几个阶段。在初期的时候，有在用RocketMQ，后来发现这个占用机器内存太高了，而且是阿里维护的，说实话，当时阿里的开源做的很不好，很可能做着做着就没人维护了（参考当年的Dubbo，不过公司还是毅然决然选择了Dubbo）。所以后来，公司决定，采用Kafka作为唯一的消息队列。

我来了之后，让我做一些Kafka的监控，主要监控Kafka中消息的堆积，在消息有堆积的时候进行报警。当时公司有Kafka-Manager，但是Kafka-Manager是Scala写的，只能看到堆积的数量，没有监控告警的功能。所以经过调研，我们选择了Kafka-Eagle，国人写的一个Kafka监控工具，改造了内部的一些bug和告警机制，就匆匆上线了，效果也还可以。后来有其他同学接手了MQ这块，他对Kafka-Eagle做了进一步的一些改造，能够批量添加告警信息，能够钉钉告警，告警的效率也有了提升。

后来，我们又发现了另一款开源的告警工具-Burrow。这款工具，可以对一个时间窗口的消息堆积进行告警，也就是能够补充Kafka-Eagle的缺失。Kafka-Eagle只有等消息堆积到了一定数量的时候才会告警，而且是定时跑的（5分钟一次），也就是设想这样的场景，如果某个partition突然间不消费了，但是消息的数量又不大，Kafka-Eagle是没法告警出来的，但是Burrow能告警出来，因为它是根据一个时间窗口的趋势告警的。也很感谢那位同学的改造，做了一些易用性的改造，同时添加了邮件告警、钉钉告警等。

3.4 研究并推行了分库分表

在公司的数据量不断累积、公司业务不断发展壮大的情况下，分库分表是一个势在必行的事情。

在我们决定使用Sharding-Jdbc之前，我们用过MyCat。在一定的历史时期内，是一个解决方案，但是仅仅用了一段时间后，就因为他不断出现的问题，而放弃了。在这说一句，MyCat的代码质量真的堪忧，可能开源的这批人，想着怎么去做解决方案，想着去开培训班赚钱了，代码感觉是实习生写的，代码风格不统一，让人没法看。

后来，我们一直在跟进Sharding-Jdbc。当时，这是由当当维护的一个开源项目，后来，负责人去了京东，后来Sharding-Jdbc改名为Sharding-Sphere，并在Apache孵化。选择Sharding-Jdbc的原因，主要有几个原因：

• 源码可控，风格统一
• 客户端分片，性能影响小

我们引入Sharding-Jdbc也分了几个阶段，走了一些弯路。第一个阶段，我们做了个Sharding-Jdbc的后台页面，对源码进行了一些改造，页面上进行数据源配置，并最终同步到ZooKeeper中。业务方配置namespace和数据源名称，在启动时拿到配置，生成分库分表数据源。第二个阶段，对分片算法进行了封装，提供了简单的分片算法，比如Hash、Mod等，业务方配置算法，生成最终的算法。这个阶段，对源码也有一定的改动。第三个阶段，依赖于Sharding-Jdbc的Jar包，封装算法，不改源码。

这块前前后后加推广，做了一段时间，目前公司一些比较核心的业务，已经上了分库分表，目前稳定性也有一定的保证，当然，推广的过程中，也遇到了一些坑，这里不细说。

这段时间的积累，也为后面要做的事情，做了一些铺垫。

3.5 数据同步

在上分库分表之前，我们就对数据同步开始了一定的调研。因为业务的分库分表，势必会遇到以下几个问题：

• 历史数据的sharding
• sharding之后，数据聚合查询

这是两个典型的场景。

第一个的解决方案可以使业务方自己去做，也就是业务自己写定时任务，在低峰期进行数据迁移，写到分库分表中；另一个解决方案就是提供通用的中间件来做数据实时同步，这样对业务方的影响最小。

第二个场景就是，分库分表后的管理端查询，查询条件可能很复杂，这时候不可能通过分库分表来查，需要把分库分表的数据聚合到一个地方，给后端进行查询。

当然，还有一个场景，就是数据库的前后端隔离，前端库面向外部用户，后端库面向管理端。这时候也需要进行同步，当然也可以通过挂从库的方式来做。

这块，我们首先调研的是，阿里开源的Canal，以及配套的Otter。但是Otter不支持分库分表，它支持的是类似DRDS、MyCat的Sharding Proxy，对于客户端的Sharding，很难支持，我们当时对Otter进行了改造。但是效果不好，因为Otter本身里面的一些逻辑复杂，不太可控，而且Otter只支持增量同步，不支持全量同步，所以在做了一段时间后，决定自己研发数据同步的组件。

得益于在Sharding-Jdbc中的积累，我们对分库分表的实践经验还是比较丰富的，所以整个开发的过程中比较顺利。我们采用了全量+增量的同步模式，满足了我们的业务场景。

涉及到数据这块的中间件，细枝末节的东西很多，我们需要和DBA紧密配合，同时也需要不断地实践，才能做出一些成果出来。所幸，我们有了这样的机会，感谢公司及领导。

数据同步的组件目前已经服务了很多的业务系统，稳定性和性能也有了一定的提升，后面还需要做一些优化的工作，一些精细化的事情，当然也有一些更加复杂的业务场景需要满足（目前公司规模下，还未遇到），这块留给后来人做吧。

3.6 其他

中间还做了一些其他的事情，包括配置中心、配置中心的封装等。主要工作是看看源码，进行业务改造，自不必细说。目前主要还是负责数据中间件这块。

四、总结

两年的时间，转瞬即逝。现在还记得当时从北京过来时的样子，懵懵懂懂，现在感觉已经看尽了世间繁华，惟愿岁月静好。感恩所有帮助过我的人，感恩家人，崭新的序幕即将开启，我将一往无前，继续前行。

欢迎大家关注我的公众号，有各种一线分享。