京东、宅急送的微服务实践分享（上）- 架构师小组交流会

架构师小组交流会是由国内知名公司技术专家参与的技术交流会，每期选择一个时下最热门的技术话题进行实践经验分享。

本期话题：微服务。微服务架构以其高度的弹性、灵活性和效率的巨大提升，快速受到各领域架构师和技术决策者的关注。我们本期小组交流会邀请到了国内电商领头羊京东、宅急送技术负责人，一起探讨最前线的微服务实践情况。

---

 

自由交流

京东章耿

大家好，我是京东基础架构部平台中间件的章耿，主要负责京东的服务框架，配置中心等项目。京东 2011 年底进行 .NET 转 Java 的技术变革，当时就提出了接口的 SOA 化的概念。那时京东业务发展非常快，项目越来越多，服务化是必然的趋势。

京东的服务化框架是一共有两代。第一代是 2012 年开始，我们使用开源的一个实现，用 Dubbo 作为 RPC 框架，Zookeeper 作为注册中心，那时应该算一个主流的技术选型。我们在开源的基础上做了一些易用性和功能扩展，比如说支持 REST、支持 kryo/thrift 等序列化，服务监控等，这个框架在那时的业务规模和节点数量下面还是比较稳定的。

2014 年初我们开始自研服务框架。为什么这么做呢？一个是之前的服务框架还是有很多可以提升的地方，不管是性能还是服务治理的一些功能，因为京东的机器数，机房也在不停的建，网络拓扑的复杂直接需要高级的服务治理功能；还有一个就是接口节点等数量级的增加，当时我们的接口规模慢慢的已经好几千了，接口的实例也几十万；另外就是用开源的有些内部系统打通比较麻烦，所以我们要做升级换代。当时也是考量了用开源的改改，还是全部自己重新做的抉择。后来觉得一个是有时间，二是觉得自己有能力做一个符合京东自己的定制化的服务框架，所以 2014 年我们就开始自研框架，做了整整一年。2015 年初我们上线新版的服务框架。

我们新的注册中心，是无状态的一些节点，基于数据库做最终一致性。为什么选数据库，替换以前的 Zookeeper？因为 Zookeeper 是树状结构，从某些维度查询它要遍历整棵数，用数据库的好处就是可以从多维度的查询分析过滤，不管是机房、 IP，都可以去查询，分析，过滤比较结果。然后 Zookeeper 在跨机房的时候有一个问题，它是半数节点存活才可以用，所以如果跨机房部署的话，最起码得 3 个机房，才能保证集群整体可用。还有 Zookeeper 它是强一致性的的，比较依赖网络。如果网络不好，如果跨机房断网的时候，它其实是不可用的，读都不能读，所以会带来一定的问题。以前用 Zookeeper 注册服务端，就是写一个临时节点，等服务端死了节点自动消失的。但是你在网络抖动的时候，或者是服务端和 Zookeeper 之间有网络故障的时候，它其实会不小心把它摘掉，因为 Zookeeper 认为它死了，但其实它不一定真的死了，所以这个时候就需要有一些辅助的去判断它是不是真的死了。

第一次遇到的情况是那个临时节点，后来我们是把它改成永久节点，然后