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

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

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

首先,底层架构平台由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 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

mongoDB在互联网金融的应用

摘要 本次分享主要讲mongodb 在互联网金融中交易与非交易部分如何实践,金融行业涉及哪些注意点,又踩过的坑。 ? 什么是P2P ? P2P是一种网上的借贷模...

2656
来自专栏ThoughtWorks

服务拆分与架构演进|洞见

本文首发于InfoQ: http://www.infoq.com/cn/articles/service-split-and-architecture-evol...

3264
来自专栏分布式系统和大数据处理

离线和实时大数据开发实战

这本书是公司一位负责数据库的同事推荐的,正好数据中心也在重构和优化,以应对更加海量的数据,所以便花了点时间读完了这本书。全书分了三个篇章:全局概览,从比较高的高...

1503
来自专栏EAWorld

精准测试的动因、概念、特性与价值

在测试领域,精准测试已经成了测试数字化的代名词,渐渐得到测试开发人员的关注,也是测试行业一个具有挑战性的议题,本文试图回答以下几个问题:

1142
来自专栏人工智能头条

3位Committer,12场国内外技术实践,2016中国Spark技术峰会议题详解

1765
来自专栏CDA数据分析师

搭好数据架构,这7个技术是关键

? 本文转自网络,如涉侵权请及时联系我们 企业IT基础设施平台的重新构建是一项复杂的任务。重新构建平台通常由一系列变化的关键业务驱动因素引发,现在情况正是如此...

3915
来自专栏数据之美

转转数据平台从 0 到 1 的演进与实践

1、背景 在转转开始大数据平台建设之前,整个数据从需求提出到研发流程再到数据报表、数据产品,也是经历过一段非常混沌的时期,而且效率和质量往往很难得到保障,主要表...

1886
来自专栏程序员的SOD蜜

架构如何为业务和技术“服务”(1)

前言 为提升架构对于项目,产品的贡献度,更好的服务于业务和技术,本文将探讨架构的现状和规划未来架构的目标。 在讨论架构、业务、技术的问题前,请耐心的阅读完本文有...

2128
来自专栏熊二哥

《大型网站技术架构》学习笔记-01概述

李智慧老师的大型网站架构已经买了两年了,之前大体看过一次,不过还未内化为自己的本领,最近项目空闲,决定尽力掌握这部分的知识,以跟上大师的节奏。今天是儿童节,祝自...

2035
来自专栏大数据和云计算技术

云​大数据和计算技术周报(第47期)

“大数据” 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算、存储、网络都涉及,知识点广、学习难度高。

1043

扫码关注云+社区