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

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

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

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

首先,底层架构平台由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),作者:京东技术沙龙

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 京东微服务平台架构解密

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

    京东技术
  • 【解密】京东B2B业务架构演变

    以分销、代销业务为核心的B2B交易平台,通过建立各级商家之间渠道通路的方式,赋能线上线下B用户,并为其提供一站式采购、售卖的解决方案。

    京东技术
  • 数读11.11丨网购下单最快4分钟送达,京东物流创新服务让消费者轻松收快递

    11.11京东全球好物节如火如荼,消费者摩拳擦掌,在集中的打折和促销中享受购物盛宴。而对物流来说,订单量的再度暴增,也带来又一场服务能力的集中展示和深度检验。

    京东技术
  • 7个点说清楚spring cloud微服务架构

    spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    程序员追风
  • ServiceMesh实战——什么是服务网格

    牛顿有曰:如果说我看得比别人更远些,那是因为我站在巨人的肩膀上。 学习前人的成果,就是先努力站到巨人的肩膀上;掌握前人的成果是前进的必要过程。有些人不学就懂了,...

    秦始皇2.0
  • 微服务 | Martin Fowler

    “微服务架构”这一术语在前几年横空出世,用于描述这样一种特定的软件设计方法,即以若干组可独立部署的服务的方式进行软件应用系统的设计。尽管这种架构风格尚无明确的定...

    ThoughtWorks
  • 一张图带你了解 Spring Cloud 微服务架构!

    Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。

    搜云库技术团队
  • 一张图了解 Spring Cloud 微服务架构

    Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    芋道源码
  • 『互联网架构』软件架构-zuul微服务网关(上)(100)

    1. 客户端会多次请求不同微服务,增加客户端的复杂性。2. 存在跨域请求,在一定场景下处理相对复杂。(有的公司服务比较微服务都是通过内部的域名的方式,分类的微服...

    IT故事会
  • 「微服务架构」Google和eBay在构建微服务生态系统方面的深刻教训

    当你看到来自谷歌,Twitter,eBay和亚马逊的大规模系统时,他们的架构已演变成类似的东西:一组多语言微服务。

    首席架构师智库

扫码关注云+社区

领取腾讯云代金券