京东技术沙龙系列之二 | 深度解析京东微服务组件平台

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

本文邀请京东微服务组件平台技术专家,为大家深度解析微服务组件平台。

首先,底层架构平台由JSFRPC调用、JMQ消息服务及服务网格这三大基础通信技术构成,既能完成同步调用,又能完成异步消息通知,或者两者混合进行。

兼容各种流行通信协议,并且支持跨语言,适用于各种线上及线下应用场景,满足了业务各式各样的通信要求,多年来包揽了集团几乎所有后台业务系统的通信流量,确保了集团各项业务的高效、平稳进行。

【京东技术沙龙】是由企业信息化部/京东大学技术学院联合京东集团各技术体系共同举办,针对京东研发内部,每月1期,分享前沿技术成果及热点话题。建立“技术交流平台”、促进“技术资源共享”、解决“工作痛点”。

本文也是基于活动上的分享内容, 小编整理后为大家放送干货。

京东微服务平台总览

在IDE工具中推出微服务设计的插件,该插件以DDD理论为基础,通过提供类似于PowerDesigner的功能,当开发人员进行设计时,系统自动检查其设计是否符合DDD理论,达到所谓“监督式设计”的效果。

另外还提供代码生成的功能,通过扫描代码,并与设计进行比对,以检查实现和设计的一致性,从而很好地维护“概念的一致性”。通过该工具,我们希望结束微服务设计阶段没有工具支撑的局面,努力提高京东微服务设计的整体水平。

通过自定义标签机制,可以给接口和应用定义多维度的标签:组件类型、权限、部门、系统级能力、所属业务层级、业务能力等,通过这些标签,拉近了jsf系统与业务场景的距离,使得业务可以根据标签进行一些个性化操作,而这个在以前是不可能做到的。

京东目前已经有3万+个微服务,通过服务评价机制,我们可以给服务进行排名,目的有两个:1)服务定级;2)趋良逐弊。

服务定级的作用集中体现在618、双11进行资源分配时,按照服务等级进行资源倾斜,以解决“资源总是不够,僧多粥少”的情况;

趋良逐弊的作用体现在:对于排名高的服务,我们可以进行最佳实践的学习;而对于排名低的服务,我们给出整改建议和意见,希望相关团队进行改进,从而提高排名。这样就可以不断提高京东微服务的整体质量。

当前jsf是基于java技术栈,以sdk的交付方式提供给开发人员。这种方式存在两大问题:1)跨语言支持不力。随着京东业务领域的快速扩张,AI、区块链、物联网等新技术领域都有各自生态里最佳的开发语言,比如phyton、go、c++等;

2)透明升级困难。基于sdk强绑定的方式决定了jsf升级必然会影响业务使用,无法做到业务无关。

另外,目前jsf对于gRPC和熔断、错误注入等高级控制手段支持不好。通过开发服务网格技术,将跟业务无关的rpc通信、服务治理等逻辑彻底与业务逻辑解耦,不仅体现在开发、编译、打包上的解耦,还体现在运行时的解耦(运行在不同的容器或进程中)。服务网格技术将完全兼容现存的Jsf服务。

京东的服务网格叫“ContainerMesh”,分为三部分,其中基础设施层主要解决网格服务的定义、装配、环境准备和应用发布,第1期将重点考虑JDOS,以后会考虑非JDOS的基础设施。

数据面主要完成通信协议的编解码、序列化以及相关的服务治理的内容,比如熔断、错误注入、流量拆分等,直白点儿说,就是“干活儿的”。

控制面接收用户的配置信息,然后将配置信息传递给数据面,数据面按照配置信息来完成具体的动作,比如用户要求服务快速失败,那么可以通过控制面下达“错误注入”相关的配置指令,从而使得数据面迅速返回错误,达到快速失败的效果。

数据面的envoy将同属于一个pod的本地service的流量接管(比如通过iptables机制)过来,然后envoy询问控制面(Jpilot)目标服务的实例信息(ip/port);这样envoy就知道如何访问目标服务了。

控制面Jpilot从jsf registry获取服务列表,等待envoy的查询;envoy通过与jsf registry的通信,完成服务注册和心跳检测。

当前京东微服务的数量达到3万+,服务与服务的依赖关系非常复杂,出现了所谓的“微服务大爆炸”。

京东分布式服务跟踪系统(CallGraph)秉承Google Dapper论文的先进理念,以业务“零”侵入的交付方式,提供跨网络的调用堆栈分析,使我们既能从宏观上俯瞰纷繁的业务关系及调用链整体特质,又能从微观上观察和审视调用链上各环节的细节,通过多种分析手段,给应用全方位画像,彻底解决“微服务大爆炸”后带来的可观察性差的问题。

当前京东已经有JOS、京麦和开普勒这样的基于API网关技术的服务于外部客户的系统,这些外部客户包括商家、今日头条等。

这些产品共同的技术特点就是提供了一个功能强大的API网关,微服务平台将考虑推出自己的API网关技术框架,来更好地支撑这些产品。

微服务平台致力于将自己打造成一个“自我进化”的系统,包含三方面的进化:

1)服务知识的进化。我们希望该进化过程可以提高京东服务知识的“精度”和“纯度”;

2)服务质量的进化。我们希望该进化过程可以提高京东微服务的整体水平;

3)组件进化。我们希望该进化过程可以促进更多、更好的组件出现,提高我们对外赋能的效率。

微服务平台将提供一系列的配套生态工具链,来提高研发人员开发分布式应用的效率。分布式事务、分布式锁、在线联调是我们重点要提供的工具。

Jsf当前的技术路线决定了研发人员“要么不用,要么全用”的局面,属于重型技术范畴。

而开源的spring cloud(Netflix提供了绝大多数的插件)通过利用spring boot的特性,提供了一个插件化的技术路线,研发人员可以选择使用其中的一种或者几种插件,比如用Eurake完成服务发现,用Hystrix完成熔断等,相对jsf而言就显得很轻了。

微服务平台想借助spring boot来改造jsf框架,达到“插件化”的使用效果,提高研发对于技术选型的灵活度。 在分享活动中,张老师就大家颇为关注的几个问题,进行了深度探讨交流。

Q: 怎么降低微服务之间的依赖?

A:从根本上讲,如果发现微服务之间的依赖太多,一定是微服务设计上出现了问题,对此强烈推荐认真学习一下DDD(领域驱动设计)理论,该理论系统地阐述了如何进行领域建模,涉及到聚合、聚合root、限界上下文、Service、Repository等概念。

可以说认真贯彻DDD理论设计出来的微服务一定是“服务内高内聚,服务间低耦合”的。

当然,随着业务规模和内容的发展,一定还会出现服务间依赖过多等各种“腐化”问题,所以我们要始终坚持按照DDD理论进行领域模型的“精进”,确保领域模型始终跟业务保持高度的“概念一致性”,才能根本杜绝微服务依赖过多等各种”腐化“问题的出现。

Q:新系统在实践微服务过程中的设计考量。

A:建议新系统首先采用“巨石模式”进行系统设计和开发,先迅速上线。不建议新系统一开始就采用微服务架构,除非团队内有精于此道、经验丰富的开发人员。

互联网公司强调快速开发、快速上线,因此,对于新系统采用何种技术应该首先考虑业务快速上线的要求。

另外,新系统领域模型的建立和演进是需要时间和积累的,等团队对本系统所涉及的问题已经完全了然于胸后,再进行微服务化也不迟。

Q:微服务架构中是否会统一各端的服务,为各端提供统一的一个服务?涉及到由多个服务组合完成一个业务功能时,事务问题如何考量?

A:这个问题其实既有业务合作上的问题,又涉及到技术问题。各端(APP、微信手Q、PC等)可能出于对所依赖的底层服务的担忧,而增加了一层后端服务,然后再由后端服务来调用真正的底层服务,形成所谓“前端自己的后端服务”。

这种设计在技术上有它的合理性,因为在自己的后端服务中可以进行通用逻辑抽离、采用统一的控制策略(比如超时机制)、进行服务聚合以减少曝露给前端的API接口数目,另外各种前端采用的技术栈不太一样,而jsf在跨语言方面支持不好,种种原因促使这一层后端服务的出现。

但是这一层后端服务是一个类似网关的东西,作为一个中心化的设施,有可能成为性能瓶颈。可以考虑将若干服务从这一层后端服务中去除,而让前端直接调用真正的底层服务,但前提是相关团队要进行技术沟通,确保服务的SLA达到业务要求。

Q:从哪些方面考虑当前系统是否有必要切为微服务实现,有哪些维度需要优先考量。微服务对比当前系统的优势。

A:决定当前系统是否切为微服务架构,有几个考虑要素:1)团队内部是否有微服务方面合适的人才;

2)系统所涉及的业务领域模型是否已经完全掌握。

微服务对比当前系统("巨石"系统)的优势如下:

- 服务简单,边界清晰,责任单一,各服务间松散耦合 - 由不同团队独立开发、独立部署及独立维护

- 高内聚、低耦合,便于扩展,易于应对变化

- 自由选用不同技术栈,用最合适的技术来解决专门问题及场景

Q:当服务数量达到一定规模,尤其是多个部门共同开发的一个庞大的系统,服务之间的关系会错综复杂,如何进行有效的管理。如何找到需要的服务,如何有效的文档化?

A:当服务达到相当规模后,服务间的依赖关系就会非常复杂,出现所谓的“微服务大爆炸”问题。

微服务平台中的CallGraph系统秉承Google Dapper论文的先进理念,以业务“零”侵入的交付方式,提供跨网络的调用堆栈分析,使我们既能从宏观上俯瞰纷繁的业务关系及调用链整体特质,又能从微观上观察和审视调用链上各环节的细节,通过多种分析手段,给应用全方位画像,彻底解决“微服务大爆炸”后带来的可观察性差的问题。

微服务平台中的“服务集市”系统提供了全京东所有服务的搜索,并提供了各种高级的搜索功能选项,使大家可以快速找到所需的服务。另外,从“服务集市”搜索出来的服务知识包罗万象,完全起到了“集中文档化”的作用。

京东技术 ∣关注技术的公众号

原文发布于微信公众号 - 京东技术(jingdongjishu)

原文发表时间:2018-05-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JAVA高级架构

【干货】阿里资深无线技术专家孙兵谈闲鱼社区技术架构演进

近期在ArchSummit北京会议上,阿里巴巴资深无线技术专家孙兵(花名酒丐)发表了《网格社区-闲鱼技术架构演讲》主题演讲。孙兵2011年加入阿里巴巴,先后在B...

25440
来自专栏SDNLAB

解密:“云”上的安全

安全是一个多层级的话题,包括物理、硬件、引导、存储和其他方面。本文只探讨数据中心工作负载的访问控制。 几乎所有企业数据中心里都有很多防火墙/VPN设备,但是Go...

28570
来自专栏云计算D1net

避免在云迁移过程中宕机

在公共云迁移期间,IT团队需要采取谨慎的步骤,以避免听到“系统宕机”这种可怕的提示。 随着组织迁移到基于云计算的基础设施,IT团队需要在迁移过程中保持可用性。...

373100
来自专栏云计算

5种确保云成本透明度和准确分析的方法

这些提示将帮助您收集并准确分析所需的成本核算信息,确保您从多云战略中能最大限度节约。

51660
来自专栏韩伟的专栏

在小型团队中如何做技术储备

如果要利用第一步的成功,来扩展一个事业,就必须要想办法满足更多的需求,从而占领更大的市场份额,因此需要在“产品”和“团队”两方面都做准备。 特种兵小队在踏出项目...

59950
来自专栏WeTest质量开放平台团队的专栏

远离服务器宕机,腾讯WeTest正式推出服务器深度性能测试服务

原文链接:https://wetest.qq.com/lab/view/415.html

18020
来自专栏技巅

毕业工作五年的总结和感悟(中)

24250
来自专栏数据和云

遇见未来 | 对话王璞:谈分布式系统在企业落地的挑战

分布式的概念很早就有了,然而真正在企业中得以广泛应用却是最近几年的事情。互联网的深入深化及大数据应用的兴起,对于IT系统的处理能力及效率都提出了更高的要求。通过...

32540
来自专栏云计算D1net

多云计算需要谨慎的IT成本分配

多云环境对企业来产有很多好处,但如果没有适当的管理,其成本分配将变得艰难。人们按照以下这些提示进行资源标记和预算警报。 单个云平台的成本分配和管理可能很困难,而...

29680
来自专栏喔家ArchiSelf

面向数据架构的云演变

现代数据架构的概念在过去的10多年里发生了巨大的变化,具体可以参见公众号“补天遗石”的《从数据仓库到数据湖——浅谈数据架构演进》一文。

13220

扫码关注云+社区

领取腾讯云代金券