vlambda博客
学习文章列表

继Docker、K8s之后，云原生时代最炙手可热的技术毫无疑问非服务网格（Service Mesh）莫属。云原生的上半场，Docker + Kubernetes的组合颠覆了传统的应用开发、部署、运维模式，极大的解放了运维人员。但是对于开发人员，似乎没有带来足够的帮助，而服务网格的出现正好弥补了Kubernetes在服务治理，安全以及服务监控等应用层的能力缺陷。笔者认为服务网格在云原生2.0时代必将大放异彩。

在过去几年中，微服务迅速发展，微服务的诞生并非偶然，它是互联网高速发展以及传统分布式、SOA架构无法适应快速的开发迭代等多重因素共同推动下的产物。

微服务架构最早由Fred George在2012年的一次技术大会上所提出，他讲到如何通过拆分SOA服务实现服务之间的解耦，这是微服务最早的雏形。而后在2014年，James Lewis和Martin Fowler发表了一篇名为《Microservices》的文章，详细彻底将“微服务”发扬光大。

微服务架构通过细粒度的服务解耦拆分，带来缩短开发周期、独立部署、易扩展等好处的同时，同时带来对服务发现、负载均衡、熔断等能力前所未有的诉求。因而，以Dubbo、SpringCloud为代表的一批微服务开发框架随之而来，尤其是SpringCloud几乎成为微服务开发的技术标准。

然而Dubbo、SpringCloud不是万能药，它们都是完全侵入式的开发模式，语言强相关，并且对于开发人员来说，无论是Dubbo还是SpringCloud的学习曲线都比较陡峭。

直到非侵入式的Service Mesh技术出现，人们才意识到微服务不止侵入式一种玩法，微服务更不是SpringCloud的独角戏！Service Mesh以如此惊艳的方式出场，完全颠覆了人们对微服务开发的认知。Service Mesh最早在2016年伴随着Linkerd的出现开始崭露头角。

服务网格的出现一方面是为了解决微服务框架侵入式开发，语言强相关、学习曲线陡峭等问题，另一方面还有云原生发展的必然因素。Docker和K8s的组合已经解决了应用的打包、部署的问题，但是它们并没有解决运行时的问题。两方面的因素组合，促使Service Mesh站在了风口浪尖。

Linkerd的出现只是起点， 随着2017年， Google与IBM联合Lyft发布了Istio， Service Mesh技术彻底被点燃。

Istio作为第二代Service Mesh技术，通过控制面带来了前所未有的灵活性及扩展能力，影响力远超更早出现的 Linkerd。根本原因是Istio背负巨大的使命，Google希望在继Kubernetes成为容器编排的事实标准之后，打造另一杀手锏级别的技术，成为服务网格的事实标准。

Istio由于Google与IBM大厂的加持，在资源投入及影响力层面远非Buoyant创建的Linkerd可比拟的。纵然Linkerd加入了CNCF基金会，也难以撼动Istio在服务网格领域的王者地位。

Istio社区吸引了众多的头部厂商参与，并且是2019年Github增长最快的TOP 10开源项目之一，可见社区的活跃度，众多贡献者一起推进Istio生态繁荣。Istio自1.0发布以来，就标志生产可用，目前社区按照三个月一个版本周期演进，最新的1.8版本本周即将发布。

华为云在Istio社区源码贡献排名全球TOP3，拥有Steering Committee成员1名（亚洲唯一，全球仅8家公司13人），项目Maintainer两名，Member 5名。已向社区贡献多个大颗粒特性：

1）服务网格通过Sidecar注入技术，将数据面Proxy注入到应用所在的Pod，通过Iptables劫持应用的流量，所有进出应用的流量均由Proxy代理。对于用户应用来说，Sidecar完全透明，以往微服务的治理、应用的监控以及安全、证书的管理等能力完全下放到Sidecar，对应用零侵入，相比传统SDK框架，极大的解放了开发者。

对用户来说，Istio提供了服务治理，安全，监控三大核心功能 。

1） Istio提供了丰富的服务治理能力：灰度发布，蓝绿部署，熔断，故障注入，丰富的负载均衡算法，限流，健康检查等。主流的微服务框架入SpringCloud提供了类似的功能，然而Istio允许用户更加灵活地动态配置服务治理规则，这一点是微服务框架所不能及的。

2）Istio提供了零信任安全网络：Istio通过Proxy间的数据加密传输以及认证，授权，策略控制等功能允许应用在零信任的网络安全的运行。

3）应用监控：Istio提供应用级别细粒度的Metrics采集，访问日志，以及分布式调用链等APM能力。APM能力下放到Sidecar，使得开发者聚焦业务本身，再也不用关心负载均衡、熔断，安全或者集成APM等业务无关的开发。

Istio并不是服务网格的终点，2018年，HashiCorp发布Consul Connect支持服务网格。2019年，Kuma以及Traefic Mesh几乎同时开源，各家厂商似乎都嗅到了服务网格领域的商业机会。

同年，Istio成为Github增长最快的10大开源项目之一。CNCF刚刚发布了2019年中国云原生调查报告，大约45%的受访者表示在生产环境中使用Istio，远远高于排名第二的Consul。

由此可见，尽管服务网格技术呈现百家争鸣的态势，但是没有一家足以撼动Istio的领先地位。

到目前为止，我们没看到微软站队某一具体技术方案，实际上微软也不想在这场技术竞赛中落后。微软也看到了百花齐放的态势，在2019年，微软发起了SMI，意图打造服务网格控制面的API标准。2020年，微软终于按捺不住，也开源了Open Service Mesh（OSM），彻底搅入服务网格技术的竞争中。两件事情连起来，自然不难看出微软的野心。

目前数据面主要有三种：Envoy，Linkerd，Traefic。Envoy由于高性能，强扩展的能力在数据面的竞争中遥遥领先。相比控制面的激烈竞争，数据面看似平静，实际上Envoy团队也充满危机意识，试图通过UDPA打造统一的数据面标准，巩固Envoy数据面代理的地位。

讲了这么多，笔者依然坚定地认为 Istio+ Envoy将会成功这场技术军备的胜出者，当然Istio的API不可能由别人（微软）制定，因此SMI很难成为事实标准。至于数据面UDPA想统一API标准的想法同样道阻且长。

未来Istio将会成为服务网格的代名词， Istio将会围绕着多云、混合云场景，构建高性能、高安全、高扩展、更加易用的能力。

各大厂商纷纷布局多云混合云战略，提供生产环境高可用，异地容灾的能力。多云、混合云将会带来更加复杂的服务拓扑结构，不仅对基础设施层，应用编排层提出了新的挑战，同样对于服务网格来说，也意味着服务治理难度的提升。

简单的举个例子，服务跨集群、跨AZ的访问时延要远大于同一集群，同一AZ的服务访问。多云、混合云的应用部署模型，网络拓扑复杂多样，进一步加剧了多云、混合云服务治理难度。

北向Istio将会通过更加灵活易用的API提供更好的用户体验以及更强的扩展能力。未来将扩展协议支持，比如QUIC等UDP协议。Istio提供QUIC协议流量的治理基于Envoy对QUIC协议的支持，首先需要提供UDP流量的拦截能力，其次，Istiod负责QUIC协议服务发现，生成Listener、Cluster等xDS配置，管理QUIC流量的处理及转发。

基于WASM的扩展机制有望成为扩展方式的新宠，WASM是一种动态的扩展机制，相对于Envoy最早提供的扩展插件的好处显而易见，但是目前WASM带来的内存及处理速度的开销不可忽视，未来Istio及Envoy社区将会围绕着WASM展开一系列的性能优化，在提高扩展能力的同时，保证高性能。

高安全，自从Istio诞生以来，构建零信任的网络运行环境一直是Istio的宗旨。当前Istio默认对所有的Sidecar之间的流量进行加密，并提供证书自动轮转，这一切对应用程序都是透明的。目前安全机制构建在K8s框架之上，依赖K8s签发证书。如何利用企业现有的安全基础设施，构筑服务网格的安全体系，将会是接下来几个版本Istio重点考虑的工作。

关联阅读