架构师小组交流会：每期选一个时下最热门的技术话题进行实践经验分享。
第三期：微服务。微服务架构以其高度的弹性、灵活性和效率的巨大提升，快速受到各领域架构师和技术决策者的关注。它的基本理念是将一个肥大的系统拆分成若干小的服务组件，组件之间的通讯采用轻量的协议完成。我们本期小组交流会来探讨一下，现在互联网公司的微服务实践情况。
嘉宾：京东章耿、原唯品会石廷鑫、七牛陈爱珍
本文是对此次交流的整理，分了上下两篇文章。
第一轮：*交流
京东章耿：大家好，我是京东基础架构部平台中间件的章耿，主要负责京东的服务框架，配置中心等项目。京东11年底进行.NET转Java的技术变革，当时就提出了接口的SOA化的概念。那时京东业务发展非常快，项目越来越多，服务化是必然的趋势。京东的服务化框架是一共有两代。第一代是12年开始，我们使用开源的一个实现，用Dubbo作为RPC框架，Zookeeper 作为注册中心，那时应该算一个主流的技术选型。我们在开源的基础上做了一些易用性和功能扩展，比如说支持REST、支持kryo/thrift等序列化，服务监控等，这个框架在那时的业务规模和节点数量下面还是比较稳定的。14年初我们开始自研服务框架。为什么这么做呢？一个是之前的服务框架还是有很多可以提升的地方，不管是性能还是服务治理的一些功能，因为京东的机器数，机房也在不停的建，网络拓扑的复杂直接需要高级的服务治理功能；还有一个就是接口节点等数量级的增加，当时我们的接口规模慢慢的已经好几千了，接口的实例也几十万；另外就是用开源的有些内部系统打通比较麻烦，所以我们要做升级换代。当时也是考量了用开源的改改，还是全部自己重新做的抉择。后来觉得一个是有时间，二是觉得自己有能力做一个符合京东自己的定制化的服务框架，所以14年我们就开始自研框架，做了整整一年。15年初我们上线新版的服务框架。
我们新的注册中心，是无状态的一些节点，基于数据库做最终一致性。为什么选数据库，替换以前的Zookeeper？因为Zookeeper是树状结构，从某些维度查询它要遍历整棵数，用数据库的好处就是可以从多维度的查询分析过滤，不管是机房、 IP，都可以去查询，分析，过滤比较结果。然后Zookeeper在跨机房的时候有一个问题，它是半数节点存活才可以用，所以如果跨机房部署的话，最起码得3个机房，才能保证集群整体可用。还有Zookeeper它是强一致性的的，比较依赖网络。如果网络不好，如果跨机房断网的时候，它其实是不可用的，读都不能读，所以会带来一定的问题。以前用zookeeper注册服务端，就是写一个临时节点，等服务端死了节点自动消失的。但是你在网络一抖的时候，或者是服务端和Zookeeper之间有网络故障的时候，它其实会不小心把它摘掉，因为Zookeeper认为它死了，但其实它不一定真的死了，所以这个时候就需要有一些辅助的去判断它是不是真的死了。第一次遇到的情况是那个临时节点，后来我们是把它改成永久节点，然后定时的去telnet 它的端口，像Dubbo是直执行ls 命令，我们也是直接执行一个命令，看它有没有响应，那是第一代的时候。在JSF的框架里有一个哨兵的组件，我们的Provider会定时的发心跳，对于注册中心来说，它知道最后的心跳时间，然后定时刷到数据库里面，看哨兵的情况，如果没有哨兵，数据库里面保存一个最后心跳时间，这时候你可以用定时任务去找它，这是我们最早的一个版本。后来我们改进了，因为有时断网了，这个心跳时间就不准了。所以在每个机房还布了一套独立的程序，没心跳的同时再由它来判断是否可用，如果这个同机房的程序都连不上，我们再把它置成一个不可用的状态，双重保证。另外以前Zookeeper的时候服务列表是下发的全量列表，例如1000台加一台，下发的是1001台，而新版注册中心我们是推变化的部分，只推加1台，大大节省了数据的推送量。
RPC框架，我们内部叫杰夫，JSF，京东服务框架的简称。我们是用基于Netty自己研发的。为了兼容上一代版本，兼容之前的dubbo协议，所以我们也是用的无代码入侵的；我们在同一个端口支持多协议，包括自定义的JSF协议，http协议，dubbo协议等。目前我们只有C++和Java的客户端，然后如果是其它语言例如Golang，python，PHP的话，我们都会让他向我们的一个HTTP的网关发请求，这个网关主要就是转发。把前面的http请求转换到后面一个JSF请求，也是基于Netty做的。序列化默认是Message Pack，是个跨语言的协议，也支持hessian，json，Java，Protobuf等。注册中心和RPC框架直接是长连接，可以进行一个通讯。