平台初心

微服务组件平台是承载京东集团所有业务的服务调用、消息通知的底层架构平台、运维管理平台、知识分享平台、沟通协作平台和服务评价及诊断平台。

底层架构平台由JSFRPC调用、JMQ消息服务及服务网格这三大基础通信技术构成，既能完成同步调用，又能完成异步消息通知，或者两者混合进行，兼容各种流行通信协议，并且支持跨语言，适用于各种线上及线下应用场景，满足了业务各式各样的通信要求，多年来包揽了集团几乎所有后台业务系统的通信流量，确保了集团各项业务的高效、平稳进行。

随着集团对外赋能及组件化积木理论的提出，仅仅满足于“以底层架构平台充当通信管道”已经远远不能适应当前形势的发展。在对外赋能的过程中，不仅仅需要研发人员埋头苦干，还需要他们抬起头来站在全局角度来积极沟通、认真梳理业务领域知识，更需要产品经理、项目经理及各级决策者们跨体系、跨部门、跨业务的高效互动和协作，才能赢得对外赋能战略的真正成功。

由此，微服务组件平台应运而生，它不仅连接了研发人员，而且还连接了广大产品经理、项目经理以及所有决策者们；它不仅提供了应用程序的通信管道，而且还提供了服务知识、信息交流的沟通管道；它不仅连接了京东内部团队，而且还连接了京东外部第三方；它不再“偏于底层技术建设”，而是不断向上延伸，发展到通过提供各种上层功能模块充分与应用场景、应用架构以及人相连接的“平台生态建设”上来。

微服务组件平台的技术愿景：成为京东业务组件化及对外赋能的基石！

平台组成

微服务组件平台作为一个生态系统，采用分层的设计模式，由许多相互支撑的模块共同组成。总体上说，微服务组件平台由三大部分组成：核心部分、生态工具链部分和基础数据服务部分。目前，平台正在按照计划有条不紊地推进，首期功能已经陆续上线。

核心部分

基础设施层

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

底层框架层

该层是平台的基础层，包括了JSF SDK、京东服务网格（ContainerMesh）、服务发现机制（JSFRegistry）和JMQ；另外，我们接下来将着力打造全新的安全体系，全方位提升系统的安全性。

系统扩展层

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

应用层

该层基于下层提供的基础功能，打造了两个全新应用，一个叫“服务集市”，另一个叫“开放平台”。其中，在服务集市里可以进行服务知识的搜索、用户自定义标签、围绕服务的评论互动、服务知识的协同编辑、服务的调用图谱、服务评价（重要性、健康度、架构合理性），甚至包括服务使用资源上的评估等等。我们希望服务集市能够将JSF和业务更加紧密的结合，提供贴近使用场景和应用架构的功能服务，同时除了连接开发人员之外，还可以连接产品经理、项目经理及各级负责人。而在开放平台中，我们除了提供强大的网关服务外，还将为业务梳理、发现和发布服务提供一站式的解决方案，帮助京东内部业务能力快速向外输出，提高对外赋能的效率。

生态工具链

虽然微服务架构给我们带来了巨大的好处，但是采用微服务架构的应用存在“单体应用”所没有的复杂性，因此需要一系列的工具链分别从各个角度来解决这些复杂性。

可视化设计

采用微服务架构的应用，其设计具有一定难度，如何进行业务逻辑拆分和数据Schema的拆分需要仔细考量，这些对于刚入门的人员来说比较头疼。为此，平台将推出针对微服务的可视化设计工具，该工具利用DDD（领域驱动设计）理论来干预和指导开发人员进行设计，希望在提高设计效率的同时，也能保证设计与实现的一致性。

开发调试

当应用依赖的微服务比较多时，在开发调试阶段能否快速搭建一套完整的测试环境是非常关键的，否则将只能进行局部功能测试，而这和反映完整业务流程的测试是有差距的。为此，平台将推出快速搭建开发调试环境的解决方案来解决这个问题。

在线联调

在充分微服务化的情况下，一个应用会调用另外一个应用的服务，以此类推，会形成所谓的“调用链”。当调用链的某个应用出问题时，往往需要挨个询问多个彼此依赖的服务的执行情况来排查问题，这会涉及到多个研发人员的联动，过程非常繁琐和费力。为此，平台将推出支持多方在线联调的工具，来简化在线联调的过程。

配置中心

为服务提供动态修改配置的功能，从而避免了先下线->修改配置->再重新上线的麻烦。

分布式锁

对共享资源的互斥访问提供分布式锁的解决方案。

分布式事务

为需要事务的地方提供了分布式事务的解决方案。

API网关

提供类似Zuul/Kong的API网关的功能。

基础数据服务

微服务组件平台的很多功能都需要IP、IP和机房的映射、机房、系统、应用及应用分组等这些基础信息，但是目前集团还没有提供这样的完整、一致的基础数据服务，这些基础数据分散在多个独立系统中。微服务组件平台在完成这些基础数据的校验、整理为我所用后，也将以服务的形式把这些基础数据共享出去，造福广大的研发人员。

重点介绍

应用层-服务集市

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

服务集市提供的功能如下所示：

搜索功能

除了支持按基本属性（erp、接口名、方法名等）查询外，还支持按自定义属性（自定义标签）查询；除了支持模糊查询外，还支持按类目查询，比如按“交易类”、“商家类”、“金融类”、“物流类”等类目进行查询。另外还支持多种搜索选项，比如排他选项等。

知识库

提供全方位、多维度的服务知识，除了提供基本的出/入参数详情、负责人等信息外，还提供调用图谱信息，包括来源、去向及入口等；还提供服务历史，包括版本变化及各版本对应的接口服务详细信息，以及变更事件通知；

提供服务快照功能，方便把服务在某个时刻的状态记录下来，比如大促时刻的状态。

权限认证

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

质量跟踪

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

调用关系

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

用户自定义标签

提供应用和接口两个维度上的自定义标签功能，帮助业务梳理、发现业务组件。另外根据用户自定义标签，可以完成更加符合用户使用场景的操控及控制。

评论互动

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

协同编辑

为了更好地完善服务知识，平台允许大家可以编辑绝大多数的服务知识点，并且提供了变更历史以供追溯。

系统扩展层

微服务调用图谱

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

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

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

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

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

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

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

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

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

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

微服务流控

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

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

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

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

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

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

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

配置中心

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

服务框架层

JSF SDK

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

增加更多的探针

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

增加更多的扩展点

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

开发新通信协议

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

增加相关注解

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

支持服务扩展属性

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

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

服务网格

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

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

服务发现

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

安全体系

JSF运行在公司内网，随着对外开放赋能不断深化以及公司体量的不断增大，对安全性要求越来越高，保护自身服务的稳定运行，就像下图所示那样：

上图是安全模型，在该模型中，每个服务都有一个全局唯一ID（UUID），基于该ID，会进行证书管理、秘钥管理以及身份认证、访问授权等安全行为。为了兼顾灵活性和效率，还支持命名空间和安全级别，同一命名空间内的服务可以随意通信，不同命名空间的访问受管控；不同级别有不同的安全要求，比如达到某种级别的服务必须有服务提供方的授权才能访问。

生态工具链

在开发分布式应用时，面临着很多方面的挑战，平台将陆续推出系列工具来应对这些挑战。首批将被推出的工具链包括：分布式锁、API网关。敬请大家期待。

基础数据服务

利用JSF广泛的部署优势，平台将积极整合J-ONE、JDOS以及横跨商城、物流、金融、京东云等的基础IT数据。在微服务流控方面，我们需要提供各种维度的诸如服务上下线这样的操作，比如按照机房维度、应用维度、应用分组维度等，这些操作都严重依赖这些基础数据的准确性、完整性和可靠性。这个功能首先是平台自身的需要，另外也将功能服务化以供调用，不断赋能。