打造坚实的服务平台

－－京东服务化实践

李鑫 lixininfo@jd.com

为何要服务化



• 系统规模随着业务的发展⽽而增⻓长，原有系统架构模式，逻辑过于



耦合不再适应；



• 拆分后的⼦子系统逻辑内聚，易于局部扩展；



• ⼦子系统之间通过接⼝口来进⾏行交互，接⼝口契约不变的情况下可独⽴立



变化；

APP1



APP2



APP3



App1



App2



App3



DB 交互通过DB来进⾏行



Data
 Store



Data
 Store



Data
 Store



交互通过同步／异步接⼝口来进⾏行

为什么要打造服务平台



服务门户



配置查看／推送



存活监控



降级



调⽤用分析图表



限流



服务性能数据收集



负载均衡



服务调⽤用 服务寻址 服务发布

第⼀一代服务框架

• 2012年初开始研发； • zookeeper集群作为注册中⼼心； • base on开源的服务框架；

zookeeper



Web管理端



2.服务消费者进⾏行订阅



1.服务提供者进⾏行注册



服务消费者1 服务消费者2



3.直接服务调⽤用



服务提供者1 服务提供者2



服务消费者3



服务提供者3



地址举例：WebService://172.17.3.18:20880/? interface=com.jd.arch.HelloService&group=pop&version=0.1

运营中暴露出的不⾜足

1.客户端 • 许多逻辑放到客户端，推出新版本；有版本升级问题； • watch时效问题； 2.注册中⼼心

• zookeeper作为注册中⼼心,功能定制扩展受限、性能有瓶颈； 3.服务治理

• 缺乏流控⼿手段，⼤大流量打爆线程池； • 更改配置需重启，对运营不够友好； • 缺乏调⽤用监控，没有调⽤用分析图表；

重装上阵！

新服务平台JSF

• 14年初开始研发； • ⾃自主研发以获得彻底的掌控⼒力； • ⽼老版本运营经验⽀支撑功能特性设计； • 中⽂文名：杰夫

Web管理端



管理数据库 注册中⼼心数据库



index服务数据库



服务注册



InInddeexxSSeervrivcicee



服务寻址 配置管理



注册中⼼心



询问注册中⼼心地址



注册／订阅



服务消费者1 服务消费者2



JSF协议直接调⽤用



服务消费者3



Event Worker 监控数据库



MMonointoitroSr eSrevrivciece



定期发送性能统计数据



服务提供者1 服务提供者2 服务提供者3

JSF核⼼心技术－RPC⽰示意图



proxy



InterfaceImpl



ServerFilterChain



负载均衡 链接管理 重试策略



ClientFilterChain



Invoker



Client



ServerTaskExecutor



encode/序列化



decode



ClientTransport



Header Invocation Body



ServerTransport



NIO TCP⻓长链接 IO-Multiplex多路复⽤用

JSF核⼼心技术－协议



• 采⽤用Netty来实现⺴⽹网络协议栈，异步事件通讯框架；



• 同⼀一端⼝口同时⽀支持Http、TCP协议访问，根据数据包情况挂载不同 解码器；



• TCP⻓长链接下使⽤用⾃自定义⼆二进制协议；



• HTTP⺴⽹网关来应对跨语⾔言访问；



magic full length



协议／序列化／消息.. 消息ID



扩展描述





ad cf 00 00 00 7f 00 0f 01 0a 01 00 00 00 0e 16 01 01 01 00 00 07 d0 97 91 c2 da 00 2f 63 6f 6d 2e 6a 64 2e 6a 6c… …

JSF核⼼心技术 RPC－callback



• TCP⻓长链接是双⼯工的，服务⽅方可以主动推送消息到调⽤用⽅方； • 调⽤用端检测到参数列表中有Callback类型，登记相应的callback对

象；服务端收到调⽤用时，⽣生成相应的反向调⽤用代理； • 服务端持有此代理，并在需要时调⽤用此代理来推送消息；



Consumer

Callback Impl



Provider

Callback stub

JSF核⼼心技术 HA&负载均衡



• ⼀一个服务⾄至少部署两个以上实例； • 服务消费者运⽤用负载均衡算法选择服务提供者，可以设置权重； • 服务消费者对服务提供者有健康监测； • 服务消费者端可以配置重试机制；



服务消费者



服务提供者1



可⽤用列表 重连列表 ⾮非健康列表



服务提供者2

JSF核⼼心技术－性能优化

• 批量处理，请求先写⼊入RingBuffer； • 优化线程模型，将序列化与反序列化这种耗时的操作从Netty的IO

线程中挪到⽤用户线程池中； • 启⽤用压缩以应对⼤大数据量的请求，默认snappy压缩算法； • 定制msgpack序列化，序列化模版，同时还⽀支持fast json、hessian

等多种序列化协议；

JSF核⼼心技术－性能优化



蓝⾊色⼀一代框架 红⾊色⼆二代框架

JSF核⼼心技术－注册中⼼心



客户端



服务注册 服务寻址 配置管理



A机房

注册中⼼心数据库



客户端



服务注册 服务寻址 配置管理



B机房



优先访问本机房注册中⼼心，各组件均有本地容灾缓存

JSF核⼼心技术－注册中⼼心



A机房

客户端

B机房

客户端



Connection Manager

Connection Manager



注册中⼼心数据库

LDM LDS



LDM LDS

JSF核⼼心技术－配置

• 服务提供者列表维护，动态推送； • 查看当前服务⽣生效的配置，动态下发新配置：权重／负载均衡算

法／各种功能开关； • 服务提供者动态分组⽆无需重启；

JSF核⼼心技术－限流

• 每⼀一个服务调⽤用者都有可能成为潜在的DDOS攻击者； • 给服务的所有调⽤用者带上标⽰示，在系统环境变量中带上APPID； • 开发计数器服务（Counter Service），限定单位时间内最⼤大调⽤用次

数（如400次／分钟）； • 限定服务端调⽤用最⼤大并发数（设定到接⼝口－⽅方法级别）； • 服务端执⾏行时检查请求的状态，如等待时间⼤大于超时时间，直接丢

弃；

JSF核⼼心技术－降级

• 每个服务接⼝口的每个⽅方法都有灾备降级开关； • 配置mock逻辑，返回的结果⽤用json格式预先设好； • 降级开关打开时将在consumer端短路RPC调⽤用，直接返回JSON结

果；

JSF核⼼心技术－监控



服务提供者



服务消费者



调⽤用情况报表



MonitorService MonitorService



MonitorQueryService



分钟表



⼩小时表



天表



influx DB

JSF核⼼心技术－报警

• provider下线报警（⼼心跳、telnet端⼝口检查）； • 某应⽤用调⽤用量超限额报警； • Consumer存活报警； • 耗时超限报警； • 异常（Exception）捕获报警；

JSF核⼼心技术－监控报表(1)

JSF核⼼心技术－监控报表(2)

JSF核⼼心技术－弹性云部署

• 按需⾃自动扩展服务能⼒力； • CAP（Cloud Application Platform）系统⾃自动分配物理机并创建容

器； • ⾃自动部署系统在容器上部署业务应⽤用； • 应⽤用启动并在JSF服务注册中⼼心进⾏行注册；

接⼝口设计的问题

• “⽆无缝将本地接⼝口发布为远程接⼝口，调⽤用与本地⼀一样”－只能是理想 • 考虑超时异常的处理； • 考虑业务逻辑粒度； • 考虑是否幂等； • ⼀一些不好的接⼝口设计举例：

• 返回值类型为Object ，实际类型被擦除 • 接⼝口声明中使⽤用范型参数T • 嵌套层数太多

京东服务化的现状



• 接⼊入4000余个接⼝口（按Java Interface计算）； • 接⼊入的物理机 、docker按独⽴立IP计算共 10000+； • 每⽇日上百亿次的调⽤用量； • 商品接⼝口：500＋多个服务实例，9000+消费实例；



2012-06-18 7



2013-06-18 60



2014-06-18 700



商品接⼝口京东店庆⽇日调⽤用次数统计 单位（亿次）

研发中的⼀一些感悟…

• 数字化运营（实时数据／阶段性统计数据）； • 开源软件，必须彻底掌握后再使⽤用； • 寻找系统的关键点，详尽的⽇日志帮助找到问题所在； • 客户端逻辑尽量简单，逻辑做到服务端去；

研发中的⼀一些感悟…

• 重复发明轮⼦子不是问题，满⾜足客户需求是第⼀一位的； • 线上实际环境的压测⾮非常重要； • 定时线上容灾演练，验证应急预案的实际执⾏行效果；

下⼀一步研发⽅方向

• 服务治理，根据应⽤用ID的⼀一系列管理增强； • HTTP/2等协议的⽀支持； • 增强跨语⾔言⽀支持；

Q&A

@InfoQ



infoqchina