同时京东成立子公司，在全国各地新建机房，部署结构也变得比较复杂。
加上SAF遗留的一些问题，大概面临如下几点：
- RPC框架较重，性能有提高的空间
- 注册中心无业务逻辑，直接对外暴露
- 京东复杂的部署架构需要更强大灵活的服务治理功能
- 监控数据不完整，维度不够
- 无应用依赖关系
- 跨语言调用需求
第二代JSF选择
所以在2014年初，我们进行了第二代JSF的一个全部自研过程。
我们主要做了如下技术选型：（全部自研）
- RPC框架：轻量级，更佳的性能，兼容旧版本协议
- 注册中心：基于DB作为数据源，前置Index服务；支持十倍接入量；部分逻辑放在注册中心减少客户端负担
- 监控中心：监控Proxy服务+InfluxDB（2015后改为ElasticSearch）
- 管理端：基于DB，功能更强大，提供完善的服务治理管理功能；打通京东应用管理平台，提供应用依赖关系梳理；
- HTTP网关：基于Netty，支持跨语言调用
开发周期：7人/年(2014.1-2015.1)。包括开发、测试、预发、上线、推广。
JSF架构简图
JSF注册中心
京东的注册中心是自研的，基于DB做的数据最终一致，也就是上面说的AP系统。
注册中心主要实现的就是服务列表的注册订阅推送，服务配置的获取下发，服务状态的实时查看等功能。
注册中心节点是无状态的，可水平扩展的。整个注册中心集群下的所有注册中心几点都是等价的。
每个机房部署多个注册中心节点。同机房的RPC框架会优先连本机房的注册中心节点。
主要亮点如下：
引入Index服务概念
- 该服务就是一个最简单HTTP的服务，用于找注册中心节点（同机房或者压力最小或者其它特定场景），可以认为是不会挂的服务，
- RPC框架会优先连该服务拿注册中心地址，这样子的好处是注册中心地址变化后，RPC框架不用修改任何设置。
注册中心内存有服务列表全量缓存，连不上数据库也保证可读
数据库的数据结构更适合各种维度展示、过滤、分析等
- 例如根据分组，IP，应用，机房等不同维度
- 注册中心就是个JSF服务，监控到压力大即可进行动态水平扩展
- dogfooding，注册中心其实是第一个JSF接口
- 服务列表推送逻辑改进
- 例如原来100个Provider，现在加1个节点，之前的SAF是需要下发101个节点，自己判断加了哪个节点，进行长链接建立；
- 现在的改进是：修改为下发一个add事件，告知RPC框架加了1个节点，RPC框架进行长链接建立；
- 这样做大大减少了推送的数据量。
- 注册中心与RPC框架可各种交互
- 注册中心和RPC框架是长链接，而且JSF是支持Callback的，注册中心可以调用RPC框架进行服务列表变化之外的操作；
- 例如查看状态，查看配置，配置下发等。
JSF RPC框架
RPC框架作为服务化里面的最基本的组件，其实都大同小异，因为RPC调用都绕不开代理、网络、序列化这些操作。
JSF的RPC框架也类似，主要分为图中的几个模块，
下面大概列下一些功能特性：
- Config：Spring/API/Annotation
- Proxy: Javassist/JDK
- Invoker/Filter：内置+自定义，Filter可扩展
- Client：Failover（默认）/FailFast/TransportPinpoint/MultiClientProxy
- 调用方式：同步（默认）/异步并行/异步回调/Callback/泛化
- Loadbalance：Random（默认）/Roundrobin/ConsistentHash/ LocalPreference/LeastActiveCall
- 路由：参数路由，分组路由，（IP级别路由逻辑在注册中心做）
- 长连接维护：可用/死亡/亚健康
- 协议：JSF（默认）/SAF(dubbo)/HTTP/Telnet/HTTP2
- 第三方：REST/Webservice
- 序列化：MsgPack（默认）/Hessian/Json/Java/protobuf(c++)
- 压缩：Snappy/LZMA
- 网络：基于Netty4.0，长连接复用
- 线程模型：BOSS+WORKER+BIZ
- 容灾：本地文件
- 请求上下文：IP，参数，隐式传参
- 事件监听：响应事件，连接事件，状态事件
- 分布式跟踪支持：进行数据埋点
JSF管理平台
提供强大管理功能，包括服务管理，监控管理，注册中心管理等功能。