京东微服务平台架构设计
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
京东微服务平台架构设计
平台初心
微服务组件平台是承载京东集团所有业务的服务调用、消息通知的底层架构平台、运维管理平台、知识分享平台、沟通协作平台和服务评价及诊断平台。
底层架构平台由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、接口名、方法名等)查询外,还支持按自定义属性(自定义标签)查询;除了支持模糊查询外,还支持按类目查询,比如按“交易类”、“商家类”、“金融类”、“物流类”等类目进行查询。另外还支持多种搜索选项,比如排他选项等。
•知识库
提供全方位、多维度的服务知识,除了提供基本的出/入参数详情、负责人等信息外,还提供调用图谱信息,包括来源、去向及入口等;还提供服务历史,包括版本变化及各版本对应的接口服务详细信息,以及变更事件通知;
提供服务快照功能,方便把服务在某个时刻的状态记录下来,比如大促时刻的状态。
•权限认证
提供相关的流程控制,比如调用申请、服务终止申请、服务访问授权等;
•质量跟踪
提供服务重要性评估、服务健康度评估、服务架构合理性评估,并提出相应建议;
•调用关系
结合微服务调用图谱,提供服务的调用链信息,以便了解服务的相关依赖关系及链路属性;
•用户自定义标签