全面解析京东微服务平台

众所周知，JSF是基于Java的RPC框架并在其基础上提供了一些服务治理功能，目前被广泛应用于集团内部。但随着微服务及容器化在京东日益深入普及，服务种类及服务实例数急剧增加，部署场景也从单纯内部使用开始向外部延伸出现混合部署的新情况，特别是组件化及对外赋能战略的提出，都对JSF提出了更新、更高的要求。总结一下，这些要求包括如下：

1. 调用端依赖的服务个数及每个服务的实例数越来越多，造成调用端的启动越来越慢；

2. 当前的软负载均衡策略遇到挑战，急需优化、调整；

3. 跨应用、跨系统的调用越来越多，调用关系和依赖关系日益复杂，可观察性越来越差；

4. 混合部署需要支持多注册中心，不同的服务访问不同的注册中心；

5. 各服务的信息比如入参/出参等散落在各个地方，服务调用者无法快速、准确、全面获取这些知识，沟通成本非常高；

6. 跨语言支持日益迫切，基于库方式将开发者绑死在单一技术栈上，与微服务理念相悖；

7. 缺乏灵活、智能、贴近业务场景及业务架构的流量控制机制及相应的运维支持手段；

8. 缺乏灵活、适度的安全机制；特性增加与BUG修复升级非常困难。

客观上讲，JSF还是很成功的，当前它支撑了几万服务接口，几十万的JVM实例，在今年双十一大促季峰值调用量近四千亿次，这些数字足以表明JSF还是非常优秀的。但是，随着业界“容器化”、“云原生应用”等大潮的到来以及集团组件化对外赋能战略的提出，JSF逐渐遇到了“危机”，亟待重整旗鼓，顺应技术潮流的发展，再创辉煌！

经过认真分析，我们认为要彻底解决JSF面临的上述问题，需要从多角度、全方位进行深入细致的优化与再造工作。这些工作不仅涉及到了RPC框架本身，还涉及到了基于该框架之上的微服务治理等工作，以及最后为满足用户各种场景下的需求而提供的一系列操作及API，它们之间存在明显的层次划分，层与层之间相互支撑，共同协作，就像下图所示那样。我们把所有这些正在做以及即将做的工作统一命名为“微服务平台”，该平台的出现宣告了京东微服务工作已经从过去“偏于底层技术建设”向上延伸，发展到了通过提供各种上层功能模块充分与应用场景及应用架构相连接的“平台生态建设”上来。下面我们按照层次划分，从下往上介绍平台组成。

• 基础设施层

微服务软件架构大行其道的重要技术因素就是容器及容器编排系统的出现，JDOS作为京东容器集群平台，理所应当成为JSF最重要的基础设施；目前JSF所有的功能模块全部运行在容器上，而且还跟JDOS2.0进行了若干功能集成；未来JSF还将与JDOS进行更多、更深入的合作，为JSF打造一个坚实、稳定的技术底座。

• 服务框架层

该层是JSF的基础层，包括了JSF SDK、正在研发的京东服务网格（ContainerMesh）以及服务发现机制（JSF Registry）；另外，我们接下来将着力打造全新的通信安全体系，全方位提升JSF的安全性。

• 系统扩展层

该层基于服务框架层，提供了更多的扩展功能，是下层功能的自然延伸，包括微服务调用图谱（解决“微服务大爆炸”后可观察性差的问题）、微服务流控（提供了各种流量控制切换的机制）、微服务配置中心（提供了支持各种格式的服务配置信息）以及微服务监控（我们将和UMP合作，提供更加强大的性能监控服务）。

• 应用层

该层基于下层提供的基础功能，打造了“服务集市”这一全新的应用模式，在集市里可以进行服务检索、服务依赖关系查询、服务质量评价（重要性、健康度、架构合理性）、围绕某个服务的评论互动，甚至包括服务使用资源上的评估等等。我们希望服务集市能够将JSF和业务更加紧密的结合，提供贴近使用场景和应用架构的功能服务。

接下来，我们按照这个层次图分别详细介绍各层的功能。

• 应用层-服务集市

由于缺乏集中管理机制，开发人员只能把提供的服务的知识放在cf或者jpcloud上，造成信息过于分散，极大增加了相关人员的找寻与沟通成本，急需专门的管理中心来解决集中存放和查询的问题，由此服务集市应运而生。

• 检索
  

除了支持按基本属性查询外，还支持按扩展属性查询；除了支持模糊查询外，还支持按类目查询，比如按“交易类”、“商家类”、“金融类”、“物流类”等类目进行查询。

• 知识库
  

提供全方位、多维度的服务知识，除了提供服务基本的出/入参数详情、负责人等组织架构信息外，还提供了服务当前的运行指标数据，比如QPS/TP情况/可用率等；提供服务档案（包括已经终止的服务），记录某服务生命周期各阶段的情况，包括版本变化及各版本对应的接口服务详细信息，以方便事后审计；提供服务快照功能，方便把服务在某个时刻的状态记录下来，比如大促时刻的状态。

• 权限认证
  

提供相关的流程控制，比如调用申请、服务终止申请、服务访问授权等；

质量跟踪

提供服务重要性评估、服务健康度评估、服务架构合理性评估，并提出相应建议；

• 调用关系
  

结合微服务调用图谱，提供服务的调用链信息，以便了解服务的相关依赖关系及链路属性；

• 资源评估
  

提供资源使用情况，以配合相关人评价该服务是否有足够能力满足新的调用需求；还提供测试环境，以供临时测试体验，而不需要去挨个找对应服务的测试环境

• 评价互动
  

提供服务输出者和使用者的互动功能；整合相关系统上对服务的评价信息，给服务使用者更加全面的知识。

• 系统拓展层

• 微服务调用图谱

随着微服务数量的急剧增加，跨应用、跨系统的调用越来越多，调用关系和依赖关系日益复杂，出现了所谓的“微服务大爆炸”。微服务调用图谱通过提供跨网络的调用堆栈分析，使我们既能从宏观上俯瞰纷繁的业务关系及调用链整体特质，又能从微观上观察和审视调用链上各环节的细节，通过多种分析手段，给应用全方位画像，形成一系列的图谱，彻底解决“微服务大爆炸”后带来的可观察性差的问题。该系统提供了如下的分析：

1. 来源分析 – 分析某服务的直接调用者的情况

2. 入口分析 – 分析某服务的最初调用者（入口）的情况

3. 路径分析 – 分析一条完整调用链的情况

4. 耗时分析 – 分析一条调用链中的各个环节的耗时情况

5. 瓶颈分析 – 分析一条调用链中的瓶颈点的情况

6. 依赖度分析 – 分析一条调用链中的强依赖、若依赖等的情况

目前该系统支持JSF/JMQ/JIMDB/各种数据库连接池等中间件，接入应用超过1600个，涉及IP数超过37000个。下图是由该系统生成的全局调用关系图：

下面这张是某个调用链的图：

下面这张是某个应用的上下游关系图：

• 微服务流控

在JSF的使用过程中，业务给我们提出了许多跟流控及运维相关的需求，我们将在微服务平台中给予集中的解决，它们包括如下：

1. 流量控制中要支持“版本”的概念（比如在一个分组中有两个版本，现在需要对其中一个版本的实例进行操作）；

2. 提供平滑的灰度升级和回退手段，支持A/B测试、金丝雀部署等；

3. 支持动态配置（不需要反复修改程序-打包-重新上线），这些动态配置的取值往往不可预测，需要根据实际情况随时调整，比如流量的阈值、服务超时时间等；

4. 服务永久下线的全流程支持（经常有业务为了下线一个即将废弃的服务，而一遍遍的发邮件确认是否有人还在调用该服务）；

5. 临界条件下的强制降级、限流和熔断等；

6. 废弃接口的治理，将长期没有调用量的接口，定期给相关人发通告，让他们下线。必要时，可以主动将它们下线，然后回收相应的资源。

• 微服务配置中心

配置信息是软件的重要一环，几乎每个服务都有自己特殊的配置，比如各种控制开关、降级开关、K-V信息等等。微服务配置中心支持普通字符串、json、properties等的配置格式，并且提供了Restful的K-V的API，实现了跨语言、跨平台。通过该系统，用户可以实现服务功能的动态配置，从而避免了先下线->修改配置->再重新上线的麻烦。目前，该系统已经存放了460多GB的配置信息。

• 微服务监控

JSF当前的监控功能还很弱，监控粒度也粗，没有TP性能数据，不支持“秒级监控”。我们将跟UMP团队展开合作，全面提升JSF在监控方面的能力和体验。

• 服务框架层

• JSF SDK

JSF SDK是微服务平台最早的核心模块，目前已经运行在几乎所有的京东容器上，负责完成所有的服务通信工作。但随着京东业务不断发展，JSF SDK也遇到了挑战，突出表现为：扩展性和灵活性不够。对此，我们重点将从以下几方面进行解决。

A.增加更多的探针

在通信过程的各个环节（编解码、序列化等）加入探针逻辑，并通过开关控制，当出现诸如性能问题时，可以打开开关，通过探针逻辑输出的日志来定位瓶颈点；没有问题时，将开关关闭，避免影响性能。

B.增加更多的扩展点

在诸如序列化、路由决策等地方，提供扩展点，允许用户提供定制的功能实现，来满足他们的个性化需求。

C.开发新通信协议

开发新一代的TCP通信协议，加强协议头部的能力，并加入握手阶段，解决很多控制方面的短板，比如安全认证、路由等。

D.增加相关注解

提供跟服务接口相关的注解，自动收集服务接口信息，为微服务集市收集数据，以降低手动录入的工作量。

E.支持服务扩展属性

当前JSF服务的属性是固定的，不允许用户扩展属性，由此引发了一个深层次问题：业务只能按照JSF的规则来组织服务关系，而不能自定义服务关系，带来的后果就是一旦业务场景或业务架构跟JSF组织的服务关系不匹配，就会出现本来彼此相关的一系列服务被割裂的现象，业务只能逐个处理，而不能整体处理，就像下图所示的那样：

左边是个单体应用，一共由4个彼此依赖的服务构成，当该应用需要下线时，4个服务会同时下线（因为它们在同一进程空间中）；而在右边，它们被微服务化，由不同开发小组来维护，当一个服务需要下线时，实际上需要其他服务一起下线，从而构成一个“有机的微服务集”，此时只能靠扩展属性，将它们“逻辑”地绑定在一起，进行整体下线，否则只能一个个下线，非常麻烦，效率低还易出错。通过该功能特性，使得用户能自由、灵活地按照实际的业务场景或架构来组合形成“有机的微服务集”，进行整体操作，从而提高效率。

• 服务网格

JSF SDK以jar包的形式提供给Java开发者，这种基于“语言库”的交付方式现在受到了越来越多的诟病。随着集团业务领域的不断扩展，不同领域内都有自己独特的生态系统，都有最适合的开发语言，Java一枝独秀的情况将在京东不复存在，go、python、c/c++、node.js等语言会越来越多地出现在我们面前。另外，基于“语言库”的方式还给特性升级和BUG修复带来了困扰，无法做到业务无感知。

对此，我们正在开发京东自己的服务网格技术，力图将业务逻辑与诸如通信、服务治理等非业务逻辑进行彻底解耦，使得开发分布式应用跟开发单机应用一样简单。届时，通过服务网格技术，不同语言之间可以顺畅通信，同时还兼容JSF服务；当需要增加新的治理功能时，可以透明升级实现，业务没有任何感知。

• 服务发现

服务发现在微服务架构中扮演了极为重要的角色，JSF Registry是京东完全自研的支持多数据中心、跨广域网、具有完备容灾特性的服务发现系统。目前，该系统稳定地支持了近3万个服务接口，近30万个JVM实例的服务注册/订阅/配置推送等功能。

• 安全体系

由于JSF运行在公司内网，所以安全性问题一直不是重点关注对象，但是随着对外开放赋能不断深化以及公司体量的不断增大，不少服务提供方纷纷要求提高服务的安全性，从而保护自身服务的稳定运行，就想下图所示那样：

左边是当前的情况，访问不需要身份认证和授权，只要知道服务接口的相关信息就能访问，虽然有token机制，但是极易被突破。右边是新的安全模型，在该模型中，每个服务都有一个全局唯一ID（UUID），基于该ID，会进行证书管理、秘钥管理以及身份认证、访问授权等安全行为。为了兼顾灵活性和效率，还支持命名空间和安全级别，同一命名空间内的服务可以随意通信，不同命名空间的访问受管控；不同级别有不同的安全要求，比如达到某种级别的服务必须有服务提供方的授权才能访问。

閱讀更多 IT界的菜鳥 的文章

關鍵字: 软件 电子商务 服务平台