数人云|万字解读:Service Mesh服务网格新生代--Istio

Service Mesh新秀，初出茅庐便声势浩荡，前有Google，IBM和Lyft倾情奉献，后有业界大佬俯首膜拜，这就是今天将要介绍的主角，扛起Service Mesh大旗，掀起新一轮微服务开发浪潮的Istio！

讲师简介：

敖小剑，十五年软件开发经验，微服务专家，专注于基础架构，cloud native拥护者，敏捷实践者。曾在亚信，爱立信，唯品会和ppmoney任职, 现任数人云资深架构师。

以下内容为敖小剑在9月21号晚上进行的线上分享实录。

今天的主角名叫 Istio，估计很多同学在此之前可能完全没有听过这个名字。请不必介意，没听过很正常，因为Istio的确是一个非常新的东西，出世也才四个月而已。

今天的内容将会分成三个部分:

• 介绍： 让大家了解Istio是什么，以及有什么好处，以及Istio背后的开发团队
• 架构： 介绍Istio的整体架构和四个主要功能模块的具体功能，这块内容会比较偏技术
• 展望： 介绍Istio的后续开发计划，探讨未来的发展预期

介绍

Istio是什么：

Istio是Google/IBM/Lyft联合开发的开源项目，2017年5月发布第一个release 0.1.0， 官方定义为:

Istio：一个连接，管理和保护微服务的开放平台。

按照isito文档中给出的定义:

Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。

简单的说，有了Istio，你的服务就不再需要任何微服务开发框架（典型如Spring Cloud，Dubbo），也不再需要自己动手实现各种复杂的服务治理的功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己动手）。只要服务的客户端和服务器可以进行简单的直接网络访问，就可以通过将网络层委托给Istio，从而获得一系列的完备功能。

可以近似的理解为：

Istio = 微服务框架 + 服务治理

名字和图标：

Istio来自希腊语，英文意思是”Sail”， 翻译为中文是“启航”。它的图标如下:

可以类比Google的另外一个相关产品：Kubernetes，名字也是同样起源于古希腊，是船长或者驾驶员的意思。下图是Kubernetes的图标：

后面会看到，Istio和Kubernetes的关系，就像它们的名字和图标一样， 可谓”一脉相传”。

主要特性：

Istio的关键功能:

• HTTP/1.1，HTTP/2，gRPC和TCP流量的自动区域感知负载平衡和故障切换。
• 通过丰富的路由规则，容错和故障注入，对流行为的细粒度控制。
• 支持访问控制，速率限制和配额的可插拔策略层和配置API。
• 集群内所有流量的自动量度，日志和跟踪，包括集群入口和出口。
• 安全的服务到服务身份验证，在集群中的服务之间具有强大的身份标识。
• 这些特性在稍后的架构章节时会有介绍。

为什么要使用Istio

在深入Istio细节之前，先来看看，为什么要使用Istio？它可以帮我们解决什么问题?

微服务的两面性

最近两三年来微服务方兴未艾， 可以看到越来越多的公司和开发人员陆陆续续投身到微服务架构， 让一个一个的微服务项目落地。

但是，在这一片叫好的喧闹中， 我们还是发觉一些普遍存在的问题：虽然微服务对开发进行了简化，通过将复杂系统切分为若干个微服务来分解和降低复杂度，使得这些微服务易于被小型的开发团队所理解和维护。但是，复杂度并非从此消失。微服务拆分之后，单个微服务的复杂度大幅降低，但是由于系统被从一个单体拆分为几十甚至更多的微服务， 就带来了另外一个复杂度：微服务的连接、管理和监控。

试想， 对于一个大型系统， 需要对多达上百个甚至上千个微服务的管理、部署、版本控制、安全、故障转移、策略执行、遥测和监控等，谈何容易。更不要说更复杂的运维需求，例如A/B测试，金丝雀发布，限流，访问控制和端到端认证。

开发人员和运维人员在单体应用程序向分布式微服务架构的转型中， 不得不面临上述挑战。

服务网格

Service Mesh，服务网格，也有人翻译为”服务啮合层”.

这貌似是今年才出来的新名词？在2017年之前没有听过，虽然类似的产品已经存在挺长时间。

什么是Service Mesh（服务网格）？

Service Mesh是专用的基础设施层。
轻量级高性能网络代理。
提供安全的、快速的、可靠地服务间通讯。
与实际应用部署一起，但对应用透明。
为了帮助理解， 下图展示了服务网格的典型边车部署方式：

图中应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。

当有大量服务相互调用时，它们之间的服务调用关系就会形成网格，如下图所示：

在上图中绿色方块为服务，蓝色方块为边车部署的服务网格，蓝色线条为服务间通讯。可以看到蓝色的方块和线条组成了整个网格，我们将这个图片旋转90°，就更加明显了：服务网格呈现出一个完整的支撑态势，将所有的服务”架”在网格之上：

服务网格的细节我们今天不详细展开， 详细内容大家可以参考网上资料。或者稍后我将会推出一个服务网格的专题，单独深入介绍服务网格。

Istio也可以视为是一种服务网格， 在Istio网站上详细解释了这一概念：

如果我们可以在架构中的服务和网络间透明地注入一层，那么该层将赋予运维人员对所需功能的控制，同时将开发人员从编码实现分布式系统问题中解放出来。通常将这个统一的架构层与服务部署在一起，统称为“服务啮合层”。由于微服务有助于分离各个功能团队，因此服务啮合层有助于将运维人员从应用特性开发和发布过程中分离出来。通过系统地注入代理到微服务间的网络路径中，Istio将迥异的微服务转变成一个集成的服务啮合层。

Istio能做什么?

Istio力图解决前面列出的微服务实施后需要面对的问题。

Istio 首先是一个服务网络，但是Istio又不仅仅是服务网格: 在 Linkerd， Envoy 这样的典型服务网