京东、宅急送的微服务实践分享(上)| 架构师小组交流会-演道网

本网站用的阿里云ECS,推荐大家用。自己搞个学习研究也不错
大家好,我是京东基础架构部平台中间件的章耿,主要负责京东的服务框架,配置中心等项目。京东 2011 年底进行 .NET 转 Java 的技术变革,当时就提出了接口的 SOA 化的概念。那时京东业务发展非常快,项目越来越多,服务化是必然的趋势。

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

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

我们新的注册中心,是无状态的一些节点,基于数据库做最终一致性。为什么选数据库,替换以前的 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 框架直接是长连接,可以进行一个通讯。

转载自演道,想查看更及时的互联网产品技术热点文章请点击http://go2live.cn

未经允许不得转载:演道网 » 京东、宅急送的微服务实践分享(上)| 架构师小组交流会-演道网

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册