【奥迪q5工作台怎么拆装】阿里巴巴中间件团队服务网格的实践与探索

摘要：所有软件最重要的任务不是满足功能要求，而是不断发展和持续增长。

精彩的观点介绍：

我们探索技术不仅仅是因为先进性，我们现在遇到了无法解决的问题，所以这项技术正好可以解决这个问题。

所有软件最重要的任务不是满足功能要求，而是不断发展和持续增长。

微服务的本质是对服务的划分，微服务体系结构符合工程领域常用的“划分和治理”范式。

最近在Aliware Open Source成都站-Apache Dubbo开发者沙龙，阿里巴巴中间件高级技术专家李云(智干)与开发者分享了阿里巴巴中间件团队在Service Mmesh领域的探索和最新做法。这篇文章是根据智珍的现场分享整理的，回顾一下分享中的精彩内容。

嘉宾介绍：李云(简)，阿里巴巴中间件高级技术专家，阿里巴巴集团服务网状方向的重要参与者和推动者。

我们探索技术不仅仅是因为先进性，我们现在遇到了无法解决的问题，所以这项技术正好可以解决这个问题。目前阿里巴巴整个集团业务量很大，技术上会遇到很多挑战。由于这些挑战，让我们考虑一下能够解决这些问题的新技术。这也是在服务网格领域探索和实践的起点。(威廉莎士比亚，北方探索)首先，让我们先看看我们经历了什么样的挑战。

一、微服务的五大挑战

第一个挑战是微服务框架本身的演变很困难。

任何软件都会有他的生命进化曲线。初期萌芽，进入形成期，向上发展，再次进入平台，最终进入衰期。(莎士比亚，哈姆雷特，生活)当然，我们希望我们的软件进入平台期后，我们可以使用进化来进入新的开发期。从这个角度来看，所有软件最重要的任务不是满足功能要求，而是进化并持续增长。相反，当某个软件无法进化的时候，它就意味着死亡。但是软件的进化不仅仅是一件事。以微服务框架为例，在双11期间，为了进一步提高整个中间件平台的稳定性，将修改一些功能，以SDK的方式提供给商业方面。但是，业务代码和微服务框架SDK强烈结合在一起。这时，我们要和各企业一起推进升级。我们的初衷是帮助您实现平台稳定性的提高，让您的业务更好地发展，但此时，由于大家的出发点和诉求不同，与业务一起升级是比较困难的。(大卫亚设，Northern Exposure，成功)因此，为了发展微服务框架，首先面临的挑战是进化困难。

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

以前，通过对技术堆栈的集成，提高了成本优势和团队效率。可以用一种语言开发和维护，防止在多语言时团队的冷漠。(大卫亚设，Northern Exposure(美国电视剧)，艺术)但是在软件和开源生态进化的过程中，多语言已经成为一种时尚。因为每种语言都有自己的优点。今天能看到的现象之一是云的原始生态系统中有多种开发语言。最常用的语言不再是Java，而是go。因为高波托印花很小。以Devubo为例，除Java外，还提供了C、Node.js的SDK，让更多开发者加入Devubo生态系统，但这一切没有社区力量的参与是很难维持的。(威廉莎士比亚，Node.js .Northern Exposure)。

的第三个挑战是异构服务框架共存，难以逐步发展。

为了看到这个挑战，让我们结合场景吧。阿里巴巴收购了部分企业，被收购企业的技术栈可能与阿里巴巴不同。例如，一部分使用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了吗？

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

作者：中间件小哥