京东JSF介绍
JSF（Java Service Framework）是京东基于Dubbo开发的分布式服务框架。
特性如下：
- 可以进行高效RPC（远程过程）调用；
- 有高可用的注册中心，完备的容灾特性；
- 服务端口同时支持TCP与HTTP协议调用，支持跨语言调用；
- 支持msgpack、json等多种序列化格式，支持数据压缩；
- 提供黑白名单、负载均衡、provider动态分组、动态切换调用分组等服务治理功能；
- 提供对接口－方法的调用次数、平均耗时等在线监控报表功能；
- 兼容SAF协议，可以调用SAF1.X接口；
- 全部模块均为自主研发，自主设计应用层JSF协议；各模块功能可控，可扩展性较好；
SAF背景
2012年初，京东从.NET转Java。各个部门，各个业务线都没有一个统一的服务化框架，有的是dubbo，有的是WebService，有的是Hessian等等。
同时各个业务系统自己有非常多的业务代码。通过统计接口规模在1K左右，服务节点在50K左右，机器规模在8K左右，机房比较少拓扑简单。
所以当时的愿景和目标比较明确：
- 京东系统服务化、API化的从无到有；
- 统一京东的RPC调用框架；
- 稳定可靠；
- 提供简单的服务治理功能。
第一代SAF选择
当时的选择如下：
- RPC框架：基于dubbo2.3.2做配置扩展，以及功能扩展包括：rest（resteasy）、webservice（cxf）、kryo/thrift序列化、调用压缩等；
- 注册中心：Zookeeper，RPC框架直接接入数据源；
- 监控中心：监控服务+HBase；
- 管理平台：读取Zookeeper做管理平台，提供基本的上下线、黑白名单等功能。
于2012年4月上线，最大规模时，接口数3K，接入最大IP数20K。
JSF
随着京东业务的不断快速增长，接口、机器数也呈数量级增长。同时京东成立子公司，在全国各地新建机房，部署结构也变得比较复杂。
加上SAF遗留的一些问题，大概面临如下几点：
- RPC框架较重，性能有提高的空间；
- 应用实例暴增，Zookeeper连接数过大(16000)，雪崩效应注册中心无业务逻辑，直接对外暴露；
- 京东复杂的部署架构需要更强大灵活的服务治理功能；
- 监控数据不完整，维度不够；
- 无应用依赖关系；
- 跨语言调用需求。
第二代JSF选择
如下技术选型：（全部自研）：
- RPC框架：轻量级，更佳的性能，兼容旧版本协议；
- 注册中心：基于DB作为数据源，前置Index服务；采用DB+本地缓存模式，分布式部署横向扩展，支持十倍接入量；部分逻辑放在注册中心减少客户端负担；
- 监控中心：监控Proxy服务+InfluxDB（2015后改为ElasticSearch）；
- 管理端：基于DB，功能更强大，提供完善的服务治理管理功能；打通京东应用管理平台，提供应用依赖关系梳理；
- HTTP网关：基于Netty，支持跨语言调用。
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规模
- 接口数：万级
- 服务节点数：百万级
- 接入实例数：十万级
- 框架调用量：每天千亿级别
- 监控数据：每天120亿条数据， 1.2T数据量
- HTTP网关：每天百亿级别
