阿里巴巴中间件团队在 Service Mesh 的实践和探索

摘要: 所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。

精彩观点导读:
? 我们去探索一项技术,并不会仅仅因为其先进性,而是因为我们目前遇到了一些无法解决的问题,而这项技术正好能解决这个问题。

? 所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。

? 微服务本质是对服务的拆分,微服务架构符合工程领域常用的“分而治之”范式。

近日,在Aliware Open Source?成都站-Apache Dubbo 开发者沙龙上,阿里巴巴中间件高级技术专家李云(至简)向开发者们分享了阿里巴巴中间件团队在Service Mmesh领域的探索和最新实践。本文是根据至简的现场分享所整理,为大家回顾分享中的精彩内容。

嘉宾介绍:李云(至简),阿里巴巴中间件高级技术专家,是阿里巴巴集团Service Mesh方向的重要参与者和推动者。
我们去探索一项技术,并不会仅仅因为其先进性,而是因为我们目前遇到了一些无法解决的问题,而这项技术正好能解决这个问题。现在,阿里巴巴整个集团业务的体量很大,在技术上会遇到很多的挑战。而正是因为这些挑战,让我们思考通过哪些新技术可以去解决这些痛点,这也是我们在Service Mesh领域进行探索和实践的出发点。首先,我们先来看看自己遇到了哪些挑战。

一、微服务的5大挑战
第一个挑战是微服务框架自身演进困难。

任何软件都会有他的生命进化曲线,从最初的萌芽,进入形成期,往上发展,再进入平台期,最后进入衰亡期。当然我们希望我们的软件可以在进入平台期后,能借助某次演进进入新的发展期。从这个维度看,所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。相反,当某个软件无法演进的时候,就会意味着死亡。但软件的演进并不是一个简单的事情,以微服务框架为例,为了进一步提升双11期间整个中间件平台的稳定性,我们会修改若干个功能,并以SDK的方式去提供给业务方,但业务代码和微服务框架SDK是强耦合的,这时候需要我们推动各个业务方和我们一同去做升级。虽然我们的初衷是实现平台稳定性的提升,帮助业务更好的发展,但这时由于大家的出发点和诉求有所不同,业务方和我们一起去做升级是比较困难的。所以要发展微服务框架,首先遇到的挑战就是演进困难。

第二个挑战是微服务框架SDK多语言并行开发与维护成本高。

以前我们都是通过对技术栈的统一来提升成本优势和团队效率,大家可以用一种语言去开发和维护,避免多语言时团队的不聚焦。但在软件和开源生态演进的过程中,多语言已经成为一种流行,因为不同语言都有其自身的优势,今天大家能看到的一个现象是云原生的生态中有多种开发语言,使用频率最高的语言已经不是Java了,而是Go,是因为Go的footprint很小。再以 Dubbo为例,除了Java,我们还提供C++,Node.js的SDK,以便让更多的开发者可以加入Dubbo生态,但所有的这些,如果没有社区力量的参与,是很难维持的。

第三个挑战是异构服务框架难以共存完成渐进式演进。

我们结合场景来看看这个挑战。阿里巴巴收购了一些企业,被收购企业的技术栈可能和阿里巴巴不同,比如有些用的是Go语言,有些用的是PHP,这时候为了统一技术栈,我们需要对这类技术平台推倒重来,但这个过程中,我们会面临一系列问题,首当其冲的就是推倒重来会带来巨大的技术风险,其次是可能会面临技术人员大批量流失的风险,这在社会责任的层面也是很难接受。所以我们在寻求一种可能的方案,去解决这类问题。

第四个挑战是单一的语言限制了人才的多样性。

这里,我们不去争论某个编程语言的好与坏,每个语言都有其适用场景,你不能说我手里有个榔头,你面对的都是钉子。以前我们觉得统一技术栈可以集中开发力量,并且带来较高的运维便利性。但伴随着互联网带来的快节奏,以往的团队能力设置已经很难满足这类变化,对工程师个体提出了更高的要求,我们不仅仅需要是某一方面的专家,而且还需要具备多域的工作技能,DevOps和全栈工程师就是这类快节奏变化下最好的注脚。

第五个挑战是点状的服务治理难以做到及时、有效和经济。

微服务和架构的核心是拆分,通过拆分,让每个模块可以独立运行,跟上业务的发展速度,持续推动业务的创新。但拆完后新的问题出来了,缺少横向的内容拉通所有独立的烟囱,从而在服务治理上带来极大的挑战。

**二、分布式应用的4大发展趋势

  1. 微服务会成为大规模分布式应用的主流架构。**

任何复杂的工程问题都会归结为devide and conquer(分而治之),意思就是就是把一个复杂的问题分成两个或更多的相同或相似的子问题,再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。微服务本质是对服务的拆分,与工程领域惯用的“分而治之”的思路是一致的。

2. 微服务架构下应用的开发是多语言的。

没有一个语言是一家独大的,每种语言在特定场景下都有其自身的优势,我们希望这种优势能够将技术到产品的周期(time to market)缩短。技术的核心在于创造价值,无论是交付给客户,还是服务于整个社会。因此,微服务是需要不同语言的开发者发挥自身的优势,去进一步完善我们的微服务架构,释放技术价值。

3. 数据安全将成为公有云分布式应用的生命线。

云原生时代,业务即便没上云,企业对自身数据的安全都是有诉求的,尤其是在金融行业,如果通过抓包就能获取一些敏感信息,这将会给企业带来巨大的风险。

4. Cloud native成为distributionless(无分布式)的主要探索路径。

分布式发展的终极形式是无分布式,在未来我们做开发,所有的代码在web上写好后,通过点击一个按钮,所有部署都会自动实现,所有的code review的工作可以在一个统一的工作台上全部实现。


?成都站开发者沙龙现场

5. 以更快的速度,通过构建软件去探索新业务。

工程师服务的是客户,通过技术输出来实现技术价值,以互联网的架构帮助赋能传统企业,帮助企业获得差异化竞争力。

三、什么是 Service Mesh
Service Mesh是层次化、规范化、体系化、无侵入的分布式服务治理技术平台。

层次化

分为数据面和控制面两个概念,数据面是指所有数据流动的那个层面,控制面是用来控制这个数据面的,对服务去做处理。对数据面和控制面进行分层,带来的好处是,针对一个复杂的系统进行切分,可以获得更清晰的认识,这和devide and conque是同一个理念。

规范化

是指通过标准协议完成数据平面和控制平面的连接,同时,sidecar成为所有traffic互联、互通的约束标准。

体系化

包含两个维度,一是指observability全局考虑。目前在整个分布式治理过程中的最大挑战是:logging、metrics、tracing这三个observability领域的核心内容缺少体系性的关注。另一个是集中管理的维度,包括服务管理、限流、熔断、安全、灰度在内的服务模块都可以在获得体系化的呈现,每个服务都可以被看到,而非团队a只看限流,团队b只看logging,需要一种技术能力拉通所有的服务模块,这个体系化这个角度看,Service Mesh是一个理想的技术方案。

无侵入

是指我们希望通过无侵入,当新增一个业务的时候,不需要考虑一个SDK去初始化,而是可以通过sidecar的进程方式来解耦。

四、Service Mesh 的形态
我们从三个维度对比的来看 ServiceMesh 的形态。

图中左边是传统的微服务形态,调用者和被调用者是通过一个SDK的方式来实现共享服务的,以Dubbo为例,我们会在SDK里提供服务路由、服务发现等功能,虽然我们的开发者在做应用开发的时候并不会太关注SDK的构成,但这些功能是面临不断被变更的可能,有着比较重的逻辑。在右边Service Mesh的形态中,我们首先会对厚重的SDK进行分解,将复杂的逻辑下沉到sidecar,借助sidecar来实现服务的调用。

虽然在Service Mesh的形态,调用路径要长于传统的形态,路径越长消耗越大,对性能影响越大。但在当前的分布式应用的治理过程中,易用性已经成为一个比性能更重要的话题。当我们给客户部署一套微服务,即便性能很强,但没有处理好易用性问题的话,这将会给技术的推广带来巨大的阻碍,不仅是会影响外部的客户,也会影响内部的用户,如何实现喝着咖啡从容应对双11,必须先解决易用性的问题。在解决易用性问题后,沿着技术的发展路径再去解决性能问题。

Service Mesh的形态中的control plan不会导致重复建设,但在shared service是有可能存在重复建设的。

五、Service Mesh 下的应用架构
无论是单体应用,还是分布式应用,都可以建立在Service Mesh上,mesh上的sidecar支撑了所有的上层应用,业务开发者无须关心底层构成,可以用Java,也可以用Go等语言完成自己的业务开发。

六、Service Mesh 的价值
为单体应用向微服务架构演进提供了渐进的途径
为异构(微)服务框架/平台提供了融合发展的可能
? 被收购子公司与母公司的业务可以融合发展

加速(微)服务框架/平台自身的演进
让业务开发同学聚焦于业务逻辑本身
业务开发时无需关心安全、灰度、限流、熔断等通用的技术内容
培育了多语言业务开发的土壤
? 助力人才发展中编程语言的多样性

对(异构)微服务架构应用实现更为有效的全局一体化监管控
七、Dubbo Mesh 的发展思路
迎合Kubernetes已成orchestrator王者的大势
开源版本与阿里巴巴集团内版本统一
与领域主流开源项目形成合力发展,源于开源、反哺开源
八、Dubbo Mesh 的进展
Dubbo Proxy

Envoy支持Dubbo协议,分两个迭代完成
迭代一:实现对Dubbo协议的解析和统计信息收集(代码已提交给社区review)
迭代二:支持服务路由(规划中)

Dubbo Control

丰富Istio/Pilot-discovery
已完成与VIPServer、Diamond的对接

正规划与ZooKeeper、Nacos的对接

仍在规划Istio/Mixer部分
九、成都沙龙 Q&A
Q1: 阿里巴巴是怎么从微服务过渡到sidecar模式,再过渡到Service Mesh?

整个过渡是渐进式的,我们会将控制平面的一些组件先下沉到与sidecar部署在一起,这一下沉能很好复用开源软件已有的能力而减少开发工作量。当这一步骤完成后,被下沉的控制面组件会重新拉回到上面的控制面,那时就会面临一定的服务端改造,一旦改造完成就有了一个全新、完整的Service Mesh。

Q2: Service Mesh中的服务注册发现,负载均衡,网关,熔断降级,超时,限流,消息总线,分布式配置,这些都是怎么实现的?

Dubbo Mesh在控制面会基于Istio去做,而Istio已经具备了Kubernetes下的服务注册与发现能力,我们要做的是扩充Istio的能力,让服务注册与发现能与ZooKeeper、Nacos进行对接去完成。基于开源的Envoy所实现的sidecar已实现了超时处理的功能,相应的内容可以读代码去了解。其他内容我们仍在规划中。

Q3: Dubbo Mesh目前性能怎么样? 增加一层sidecar导致Dubbo的RT有多少?

在使用iptables的情形下,一跳增加1.5毫秒,如果不采用iptables直接proxy方式的情形下应当性能更好(这一点与Lyft也邮件确认过了),我们接下来会做更多的性能测试,目前的焦点更多在于功能层面。

Q4: Dubbo Mesh是把双刃剑,经过的链路更复杂,运维和开发者问题排查有没有更有效的工具?

理论上,增加一跳并没有改变服务调用的拓扑结构,但确实会增加复杂度,这个应当通过设计实现去解决。好在因为是一体化的方案,所以解决这类问题时需要更具全局视野。

?成都站开发者提问

Q5: Service Mesh中控制面板也用C++吗?我看主流很多实现都是Go, 我相信大佬做过技术调研,有哪些优势?

控制面是复用Istio的,是Go语言的。我们力争不重复造轮子,而是以开放的心态去共建。

Q6: Client做解码和反序列化是吧,有计划支持HTTP2协议吗?

Envoy默认就支持了,不需我们开发。这也是借力开源的收益。

Q7: Dubbo Mesh已经支持domain socket了吗?

目前不支持,这个还处于意向阶段。

原文链接

本文为云栖社区原创内容,未经允许不得转载。

原文地址:http://blog.51cto.com/13952056/2173872

时间: 2024-10-10 02:49:46

阿里巴巴中间件团队在 Service Mesh 的实践和探索的相关文章

阿里巴巴中间件团队出品的开源软件以及商业云服务(转)

RocketMQ 一款开源的高性能消息中间件,天猫双十一大促必备削峰填谷利器,峰值近万亿消息量. https://github.com/alibaba/RocketMQ Corbar 基于Mysql的数据库服务中间件 https://github.com/alibaba/cobar JStorm 流计算框架,已经加入Apache https://github.com/alibaba/jstorm Dubbo 分布式服务调用,SOA框架 https://github.com/alibaba/dub

阿里巴巴 Service Mesh 落地的架构与挑战

点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践>本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者 | 方克明(溪翁)阿里云中间件技术部技术专家 导读:云原生已成为整个阿里巴巴经济体构建面向未来的技术基础设施,Service Mesh 作为云原生的关键技术之一,顺利完成在 双11 核心应用严苛而复杂场景下的落地验证.本文作者将与大家分享在完成这一目标过程中我们所面临和克服的挑战. 部署架构 切入主题前,需要交代一下在 双11

蚂蚁金服 Service Mesh 实践探索

SOFAMesh是蚂蚁金服在ServiceMesh方向上的探索,下面是它高级技术专家敖小剑在QCon上海2018上的演讲. Service Mesh 是一个 基础设施层,用于处理服务间通讯.现代云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中 实现请求的可靠传递. 在实践中,服务网格通常实现为一组 轻量级网络代理,它们与应用程序部署在一起,而 对应用程序透明. 加粗部分是重点: 基础设施层:这是 Service Mesh 的定位,今天内容的最后一个部分我会和大家详细展开这个话题: 服务间通

Service Mesh 是新瓶装旧酒吗?

点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践> 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者 | 李云(花名:至简) 阿里云高级技术专家 导读:在即将过去的 2019 年,Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化,但在国内仍出现了一些值得特别关注的事件.比如:阿里巴巴在 双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案,借助 双11 的严苛业务场景完成了规模

微服务架构下 Service Mesh 会是闪亮的明天吗?

7月7日,时速云企业级容器 PaaS 技术沙龙第 10 期在上海成功举办,时速云容器架构负责人魏巍为大家详细讲解了 Service Mesh 中代表性的实践方案.并以 Istio 为例详细讲解了 Service Mesh 中的技术关键点,包括 Istio 控制平面.Istio 数据平面等.以下内容根据魏巍分享整编,希望对大家了解 Service Mesh 有所帮助. 魏巍:大家下午好,刚才几位讲师讲了 K8S 的存储.PaaS 在企业的落地实践等,我们接下来要讲的是企业有了 PaaS 平台.并且

微服务架构之「 下一代微服务 Service Mesh 」

Service Mesh 被大家称为下一代的微服务,是微服务领域的一颗新星,被大家讨论的非常多. 我在大家的讨论中,还看到有人说 “目前的微服务架构我都没学会呢,现在又来一个下一代微服务,真学不动了”. 哈哈,没办法,互联网技术就是发展得这么快,这些技术其实也都是由于大家所在的公司业务规模和复杂度变大以后所推动出来的. 最开始 Service Mesh 的概念是由Buoyant公司在2016年提出.然后在随后几年,业内就围绕着 Service Mesh 思想探索出了各种实现,其中包括以 Link

Service Mesh——微服务中的流量管理中间件

Service Mesh——微服务中的流量管理中间件 摘自-https://zhuanlan.zhihu.com/p/28794062 Service mesh 与 Cloud Native Kubernetes 设计之初就是按照 Cloud Native 的理念设计的,Cloud Native 中有个重要概念就是微服务的架构设计,当将单体应用拆分微服务后, 随着服务数量的增多,如何微服务进行管理以保证服务的 SLA 呢?为了从架构层面上解决这个问题,解放程序员的创造性,避免繁琐的服务发现.监控

什么是 Service Mesh

作者|敖小剑 微服务方兴未艾如火如荼之际,在 spring cloud 等经典框架之外,Service Mesh 技术正在悄然兴起.到底什么是 Service Mesh,它的出现能带来什么,又能改变什么?本文整理自数人云资深架构师敖小剑在 QCon 2017 上海站上的演讲. 简单回顾一下过去三年微服务的发展历程.在过去三年当中,微服务成为我们的业界技术热点,我们看到大量的互联网公司都在做微服务架构的落地.也有很多传统企业在做互联网技术转型,基本上还是以微服务和容器为核心. 在这个技术转型中,我

Service Mesh在企业级应用的生存之道

导读 近期与几位企业用户交流 Service Mesh 及其相关技术,大家对于它所展现的形态以及未来发展都表示出极大的兴趣.但对当下企业应用现状如何与 Service Mesh 整合到一起又表现出极大的困惑.本文力图结合Service Mesh技术特性与企业应用的实际情况,就 Service Mesh 如何应对企业应用给出博云自身的思考,欢迎有兴趣的朋友一起讨论. 在进行详细探讨之前,我们首先回顾一下 Service Mesh 的定义:服务网格是一个用于处理服务间通信的基础设施层,它负责为构建复