谈谈京东的服务框架

最近由于在实习期间接触到了京东的自研服务框架JSF，简称“杰夫”，目前我写的一些新功能里面调用的下游接口就是杰夫提供的。现有有很多高效的服务框架，如阿里巴巴的Dubbo配合Apache的ZooKeeper，那么为什么京东却自研了JSF服务框架呢？于是看了看京东的JSF的演化历史，不得不感叹好的架构果然不是一朝一夕就能实现的，都是逐步演变而来的。

一、Dubbo与Zookeeper的组合拳

Dubbo是阿里巴巴开源的一个高性能的服务框架，Dubbo使得应用之间可通过高性能的RPC实现服务的输出和输入功能，而且可以和 Spring框架无缝集成。我们可以看看Dubbo架构路线图：从单一应用架构 → 垂直应用架构 → 分布式服务架构 → 流动计算架构 ，也可以看我的另一篇文章《服务拆分方法论》:

从上图可以看出互联网的架构演变经历了单一应用架构、垂直应用架构、分布式服务架构和流动计算架构。服务的粒度越来越细化，多个Tomcat的Servlet之间相互调用，服务治理的尤为重要，所以一个优秀的架构来替我们解决服务之间的调用问题，而且还要保证高可用，甚至是实现负载均衡。于是Dubbo框架就出现了，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册与发现。

下面是Dubbo框架的架构图：

节点	说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

先用容器Container，通过Docker来启动我们的服务Provider。Dubbo本身没有使用任何的注册中心，而是用一种直连的方式进行的。但是，实际上很多时候都是使用 Dubbo + Zookeeper 的方式，使用 zookeeper 作为注册中心，服务调用方Comsumer就会去注册中心去订阅Subscribe相关服务。注册中心会异步的方式将消费者需要的服务的地址列表推送Notify给你。消费者就会将整个地址列表缓存在本地，当业务需求到来时，就会使用地址列表里的地址去请求相关的服务程序。至于Monitor顾名思义就是监视器的含义，消费者和提供者会定时将服务的调用次数和被调用的次数发送给监视器。关于Dubbo和Zookeeper的使用案例在此就不介绍了，可以参考《Dubbo一篇文章就够了：从入门到实战》。