参考：Service Mesh 初体验 - 知乎

简介

SeviceMesh是云原生下的微服务治理方案。

当我们通过微服务的方式将应用以容器的形式部署在K8S上后，服务之间调用和治理其实有新的方案，可以不需要依赖传统的微服务治理框架。ServiceMesh通过对每个应用在其Pod中启动一个Sidecar（边车）实现对应用的透明代理，所有出入应用的流量都先经过该应用的Sidecar，服务之间的调用转变成了Sidecar之间的调用，服务的治理转变成了对Sidecar的治理。在ServiceMesh中Sidecar是透明的，开发无感知的，之前一直觉得奇怪，总觉得一个应用要让别人发现它从而调用它，总得引入一些库然后进行主动的服务注册，不然啥都不做，别人咋知道这个应用的存在，为什么在ServiceMesh中就可以省去这些，做到对开发者完全地透明呢？这个的实现依赖于容器编排工具，通过K8S进行应用的持续集成和交付时，在启动应用Pod后，其实已经通过Yaml文件的形式向K8S注册了自己的服务以及声明了服务之间的关系，ServiceMesh通过和K8S进行通信获取集群上所有的服务信息，通过K8S这个中间者实现了对开发者的透明。如下图所示，是ServiceMesh的一个基本结构，包括数据平面和控制平面。

这种方式存在很多好处，我们可以发现在这种模式下应用的语言其实不会对整个服务治理过程有什么影响，对于ServiceMesh来说，它只关心Pod或者说是Pod中的容器实例，并不需要在乎容器中应用的实现语言是啥，Sidecar和其负责的容器在同一个Pod中。这样ServiceMesh就可以实现跨语言，这也是目前很多传统的服务治理框架的一大缺点，而且采用传统的服务治理，需要对应用引入大量的依赖，这样就会造成依赖之间的各种冲突，集团通过Pandora对应用的各种依赖进行隔离。再者传统的服务治理门槛较高，需要开发者对整个架构有一定的了解，且发现问题排查较为麻烦。这也造成了开发和运维之间的界限不清，在ServiceMesh中开发只需要交付代码，运维可以基于K8S去维护整个容器集群。

发展现状

通过目前查阅的资料来看，ServiceMesh一词最早出现在2016年，最近两年被炒的很火，蚂蚁金服已经有了自己的一套完整的ServiceMesh服务框架--SofaMesh，集团很多团队也在进行相应的跟进。

从历史发展的路线来看，程序的开发方式经历了很多的变化，但总的方向是变得越来越简单了，现在我们在集团内进行开发，可以很简单的构建一个支撑较大QPS的服务，这得益于集团的整个技术体系的完整和丰富以及强大的技术积淀。

我们下面来看看应用开发到底经历了啥？

发展历史

主机直接阶段

如上图，这一阶段应该是最古老的阶段，两台机器通过网线直接连接，一个应用包含了你能想到的所有的功能，包括两台机器的连接管理，这时还没有网络的概念，毕竟只能和通过网线直接连接在一起的机器进行通信。

网络层的出现

如上图，随着技术的发展，网络层出现了，机器可以和通过网络连接的其他所有机器进行通信，不再限制于必须要网线直连两台机器。

集成到应用程序内部的流量控制

如上图，由于每个应用所在环境和机器配置不一样，接受流量的能力也不相同，当A应用发送的流量大于了B应用的接受能力时，那么无法接收的数据包必定会被丢弃，这时就需要对流量进行控制，最开始流量的控制需要应用自己去实现，网络层只负责接收应用下发的数据包并进行传输。

流量控制转移到网络层

如上图，慢慢地大家发应用中的网络流量控制是可以转移到网络层的，所以网络层中的流量控制出现了，我想大概就是指TCP的流量控制吧，这样还能保证可靠的网络通信。

应用程序的中集成服务发现和断路器

如上图，开发者通过在自己的代码模块中实现服务发现和断路器。

专门用于服务发现和断路器的软件包/库

如上图，开发者通过引用第三方依赖去实现服务发现和断路器。

出现了专门用于服务发现和断路器的开源软件

如上图，基于各种中间件去实现服务发现和断路器。

ServiceMesh出现

最终到了现在，ServiceMesh大法诞生，进一步解放了生产力，提高了软件整个生命周期的效率。

ServiceMesh市场竞争

虽然直到2017年底，ServiceMesh才开始较大规模被世人了解，这场微服务市场之争也才显现，但是其实ServiceMesh这股微服务的新势力，早在 2016年初就开始萌芽：
2016年1月，离开Twitter的基础设施工程师William Morgan和Oliver Gould，在github上发布了Linkerd 0.0.7版本，业界第一个ServiceMesh项目就此诞生。Linkerd基于Twitter的Finagle开源项目，大量重用了Finagle的类库，但是实现了通用性，成为了业界第一个ServiceMesh项目。而Envoy是第二个ServiceMesh项目，两者的开发时间差不多，在2017年都相继成为CNCF项目。2017年5月24日，Istio 0.1 release版本发布，Google和IBM高调宣讲，社区反响热烈，很多公司在这时就纷纷站队表示支持Istio。Linkerd的风光瞬间被盖过，从意气风发的少年一夜之间变成过气网红。当然，从产品成熟度上来说，linkerd作为业界仅有的两个生产级ServiceMesh实现之一，暂时还可以在Istio成熟前继续保持市场。但是，随着Istio的稳步推进和日益成熟，外加第二代ServiceMesh的天然优势，Istio取代第一代的Linkerd只是个时间问题。自从在2016年决定委身于Istio之后，Envoy就开始了一条波澜不惊的平稳发展之路，和Linkerd的跌宕起伏完全不同。在功能方面，由于定位在数据平面，因此Envoy无需考虑太多，很多工作在Istio的控制平面完成就好，Envoy从此专心于将数据平面做好，完善各种细节。在市场方面，Envoy和Linkerd性质不同，不存在生存和发展的战略选择，也没有正面对抗生死大敌的巨大压力。
从Google和IBM联手决定推出Istio开始，Istio就注定永远处于风头浪尖，无论成败，Istio面世之后，赞誉不断，尤其是ServiceMesh技术的爱好者，可以说是为之一振：以新一代ServiceMesh之名横空出世的Istio，对比Linkerd，优势明显。同时产品路线图上有一大堆令人眼花缭乱的功能。假以时日，如果Istio能顺利地完成开发，稳定可靠，那么这会是一个非常美好、值得憧憬的大事件，

Istio介绍

Istio是目前最热的ServiceMesh开源项目，Istio主要分为两个部分：数据平面和控制平面。Istio实现了云原生下的微服务治理，能实现服务发现，流量控制，监控安全等。Istio通过在一个Pod里启动一个应用和Sidecar方式实现透明代理。Istio是一个拓展性较高的框架，其不仅可以支持K8S，还可以支持其他如Mesos等资源调度器。如下图所示，为Istio的整体架构：

• 逻辑上分为数据平面（上图中的上半部分）和控制平面（上图中的下半部分）。
• 数据平面由一组以 Sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。
• 控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。
• Pilot是整个架构中的抽象层，将对接K8S等资源调度器的步骤进行抽象并以适配器的形式展现，并和用户以及Sidecar交互。
• Galley负责资源配置为验证。
• Citadel用于生成身份，及密钥和证书管理
• 核心功能包括流量控制、安全控制、可观测性、多平台支持、可定制化。

Mixer

Mixer同样是一个可拓展的模块，其负责遥感数据的采集以及集成了一些后端服务（BAAS），Sidecar会不断向Mixer报告自己的流量情况，Mixer对流量情况进行汇总，以可视化的形式展现，此外Sidecar可以调用Mixer提供的一些后端服务能力，例如鉴权、登录、日志等等，Mixer通过适配器的方式对接各种后端服务。

In-process Adapter形式

之前版本的Isito采用这种将后端服务适配器集成在Mixer内部的形式，这种方式会有一个问题，就是某个后端服务适配器出现问题即会影响整个Mixer模块，但由于适配器和Mixer集成在一起，在同一个进程内，方法的调用会很快。

Out-of-process Adapter形式

目前版本的Istio将Adapter移到Mixer外部，这样可以实现Mixer与Adapter的解耦，当Adapter出现问题并不会影响Mixer，但这种方式同样也存在问题，即Adapter在Mixer外，是两个不同的进程，二者之间的调用是通过RPC的方式，这种方式比同进程内部的方法调用会慢很多，因此性能会受到影响。

Pilot

• Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy。
• Abstract Model 是 Pilot 定义的服务的抽象模型, 以从特定平台细节中解耦, 为跨平台提供基础。
• Platform Adapter则是这个抽象模型的实现版本, 用于对接外部的不同平台如k8s/mesos等。
• Rules API提供接口给外部调用以管理 Pilot, 包括命令行工具Istioctl以及未来可能出现的第三方管理界面。

Galley

Galley 原来仅负责进行配置验证, 1.1 后升级为整个控制面的配置管理中心, 除了继续提供配置验证功能外, Galley还负责配置的管理和分发, Galley 使用 网格配置协议(Mesh Configuration Protocol) 和其他组件进行配置的交互.

Istio 创造了50多个CRD, 其复杂度可见一斑, 所以有人说面向k8s编程近似于面向yaml编程.早期的Galley 仅仅负责对配置进行运行时验证, Istio 控制面各个组件各自去list/watch 各自关注的配置。越来越多且复杂的配置给Istio用户带来了诸多不便, 主要体现在:

• 配置的缺乏统一管理, 组件各自订阅, 缺乏统一回滚机制, 配置问题难以定位。
• 配置可复用度低, 比如在1.1之前, 每个Mixer adpater 就需要定义个新的CRD。
• 配置的隔离, ACL 控制, 一致性, 抽象程度, 序列化等等问题都还不太令人满意

随着Istio功能的演进, 可预见的Istio CRD数量还会继续增加, 社区计划将Galley 强化为Istio配置控制层, Galley 除了继续提供配置验证功能外, 还将提供配置管理流水线, 包括输入, 转换, 分发, 以及适合Istio控制面的配置分发协议(MCP)。

Citadel

将服务拆分为微服务之后，在带来各种好处的同时，在安全方面也带来了比单体时代更多的需求，毕竟不同功能模块之间的调用方式从原来单体架构中的方法调用变成了微服务之间的远程调用：

• 加密：为了不泄露信息，为了抵御中间人攻击，需要对服务间通讯进行加密。
• 访问控制：不是每个服务都容许被任意访问，因此需要提供灵活的访问控制，如双向 TLS 和细粒度的访问策略。
• 审计：如果需要审核系统中哪些用户做了什么，则需要提供审计功能。

Citadel 是 Istio 中负责安全性的组件，但是 Citadel 需要和其他多个组件配合才能完成工作：

• Citadel：用于密钥管理和证书管理，下发到Envoy等负责通讯转发的组件。
• Envoy：使用从Citadel下发而来的密钥和证书，实现服务间通讯的安全，注意在应用和Envoy之间是走Localhost，通常不用加密。
• Pilot：将授权策略和安全命名信息分发给Envoy。
• Mixer：负责管理授权，完成审计等。

Istio支持的安全类功能有：

• 流量加密：加密服务间的通讯流量。
• 身份认证：通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证，包括传输身份认证和来源身份认证，支持双向TLS。
• 授权和鉴权：提供基于角色的访问控制（RBAC），提供命名空间级别，服务级别和方法级别的访问控制。