《istio实战指南》第1章 服务网格

第1章 服务网格

服务端架构发展

面向服务的架构

• SOA（Service-Oriented Architecture）。它是指在分布式环境下，系统或者其组件可以在网络上通过通用协议调用另一个系统，使得多个系统彼此协作，它是令被调用系统成为调用者的服务
• SOA架构中的各个子系统通过企业服务总线（Enterprise Service Bus，ESB）实现了松散耦合。ESB是构建SOA时所使用的关键技术，可以简单地理解为它是一个通信系统，为各个应用提供交互能力
• 图SOA体系结构

微服务架构

• 在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，它们共同构成了较大的应用。每个组件都被称为一个微服务，而每个微服务都在整体架构中执行着单独的任务或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，共同协作来完成一个完整、复杂的业务逻辑
• 下图展示了一个简单的微服务应用。整个业务被拆分成几个不同的服务，客户端通过API网关发送请求，业务数据被拆分到不同的数据库，只能由对应的服务进行访问

• 微服务架构具有如下特点

1. 服务的粒度较小，一个大型复杂的系统由多个微服务组成
2. 采用UNIX的设计哲学，某个服务只做一件事，是一种可以独立开发和部署的无状态服务
3. 通过服务实现组件化。不使用库（Library）而用服务来构建组件以便于独立部署
4. 微服务的开发团队小而内聚，可独立开发自己的业务，团队之间没有依赖
5. 去中心化的数据管理。每个服务有自己的数据存储
6. 不受语言、平台的限制（现实中一个大型的微服务应用往往是一个多语言开发的异构系统）

微服务架构的痛点

• 当一个大型的系统被拆分为几十个、上百个甚至更多的服务时，如何有效地管理服务，以及保证服务间的通信稳定可靠成为开发人员需要关注的新问题
• 稳定可靠的网络通信成为构建微服务系统的一大难题。试想一个大型的业务系统，需要对成百上千个微服务进行版本控制、监控和故障转移等一系列操作，并实现A/B测试、灰度发布、限流、熔断和访问控制等一系列与网络相关的功能，这是多么复杂的一件事情。开发和运维人员在转型到微服务架构时不得不面对这一新的挑战

服务网格的发展

• 为了解决微服务之间网络通信的问题，以应对这一全新的挑战，系统架构也进一步演化，最终催生了服务网格的出现

耦合阶段

• 在微服务架构中，服务发现、熔断这样的弹性能力是架构重要的组成部分。在单体应用中，可以使用一个公共的组件统一实现或是嵌入业务逻辑中。而在微服务架构下，因为服务的分散粒度更小，所以它变得更加复杂。起初开发人员将诸如熔断（Circuit Breaker）这样的网络层功能和业务代码封装在一起，使服务具备了网络控制能力，
• 这种方案虽然易于实现，但从设计角度来讲缺点也很明显

1. 网络功能和业务逻辑耦合
2. 每个服务都需要重复封装和实现这样的代码
3. 管理困难。如果某个服务的负载均衡发生了变化，则调用它的相关服务都需要更新变化
4. 开发人员不能专注在业务逻辑上

Sidecar模式

• 这样的方案仍然不完美，它会导致很多问题的出现，比如跨语言问题、更新后的发布和维护等。许多实践者发现，更好的解决方案是把它作为一个代理——服务不会直接访问它的下游依赖方，而是通过这个透明的代理来处理所有的流量
• 以Sidecar的方式进行网络代理，对应用服务没有侵入性，不会受到应用服务的语言和技术限制，而且可以做到控制层和业务逻辑的分开升级和部署。Sidecar在逻辑上和应用服务部署在同一个结点（如Pod）中，它们拥有相同的生命周期。每个服务都配备了一个Sidecar代理。Sidecar可以迅速方便地为应用服务提供扩展，而不需要应用服务的改造。它的主要功能如下

1. Sidecar可以帮助服务注册到相应的服务发现系统，并对服务做相关的健康检查。如果服务不健康，则可以从服务发现系统中移除服务实例
2. 当应用服务要调用外部服务时，Sidecar可以帮助从服务发现中找到相应外部服务的地址，然后进行服务路由
3. Sidecar接管了进出的流量，这样我们就可以进行相应的日志监视、调用链跟踪、流控熔断等操作，这些都可以在Sidecar中实现
4. 服务控制系统可以通过Sidecar来控制应用服务，如流控、下线等

应用服务终于可以做到专注于业务逻辑

服务网格出现

• 如果把Sidecar代理应用于一个大型的系统，其中包括很多个相互通信的服务，那么每个服务都将有一个配套的Sidecar代理，服务之间通过Sidecar代理进行通信，最终得到一个如下图的网络拜年结构，这就是服务网格

• 最后，总结一下微服务网络通信功能的演进过程

1. 最初，服务进行通信时，因为接收速度不一致，所以需要加入流量控制等功能（服务发现和熔断）
2. 流控功能和业务耦合需要被标准化和复用，它们被封装在公共库里
3. 多语言多平台下，为避免浪费时间来开发和管理这些公共库，应将网络功能下沉并独立出来，和业务服务分离
4. 分离的通信服务发展成为Sidecar模式
5. Sidecar模式应用于多服务的系统，服务之间相互连接形成了网状拓扑结构，最终演变成了服务网格

什么是服务网格

基本概念

• 几个关键点就能理解：基础设施、服务间通信、请求分发、云原生应用、网络代理和对应用服务透明
• 服务网格是用来处理服务间通信的基础设施。可以说，服务网格就是Sidecar的网络拓扑形态，Mesh这个词也由此而来

服务网格的功能

1. 动态路由，可以通过配置路由规则来动态确定要请求的服务。请求需要被路由到生产环境还是预演（Staging）环境？路由到本地还是云？是测试版本还是运行版本？
2. 故障注入。Netflix有一个非常著名的故障测试系统Chaos Monkey，它会故意切断不同范围的网络环境来测试服务的容错能力。在服务网格中我们可以通过故障注入特性模拟基本的网络传输问题来验证系统的健壮性
3. 熔断。生产环境中经常会有各种问题导致服务中断，这就需要系统有检测服务并且快速移除问题服务的能力。熔断可以通过服务降级来终止潜在的关联性错误
4. 安全。微服务环境中，服务间通信变得更加复杂，如何保证这些通信是在安全、授权的情况下进行的就非常重要了。通过在服务网格上实现安全机制（如TLS加解密和授权），不但可以在不同的服务上对其进行重用，而且很容易在整个基础设施层更新安全机制，甚至无须对系统做任何操作
5. 多语言支持。作为独立运行的透明代理，服务网格支持多语言的异构系统
6. 多协议支持。同多语言支持一样，实现多协议支持也非常容易
7. 指标和分布式追踪。服务网格对整个基础设施层的可见性使得它有能力对网络通信进行全面的检测，还可以收集指标和日志，并交由后端设施进行可视化展示

• 概括起来，服务网格主要具有如下4个主要的特性

1. 可见性（Visibility）：运行时指标遥测、分布式跟踪
2. 可管理性（Manage Ability）：服务发现、负载均衡、运行时动态路由
3. 健壮性（Resilience）：超时、重试、熔断等弹性能力
4. 安全性（Security）：服务间访问控制、TLS加密通信

服务网格产品介绍

Linkerd

• 2016年初，前Twitter的两位工程师William Morgan和Oliver Gould组建了一个小的创业公司Buoyant，开发出了Linkerd并在GitHub上发布了0.0.7版本。这是业界公认的第一个Service Mesh。2017年年初Linkerd加入CNCF，同年4月1.0版本发布

Envoy

• 2016年9月，Lyft公司的Matt Klein宣布Envoy在GitHub开源并发布了1.0.0版本。2017年Envoy加入CNCF成为第二个服务网格项目，并于2018年底孵化毕业。Envoy是一个高性能的C++语言实现的分布式代理，它也是一个通信总线。Envoy基于对Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的了解，与每个应用服务一起运行，并以与平台无关的方式提供公共的网络特性
• Envoy具有以下功能特性

1. 过程外架构：Envoy是一个自包含的高性能服务器，内存占用很小，可以与任何应用程序语言或框架一起运行
2. HTTP/2和gRPC支持：Envoy对HTTP/2和gRPC的传入和传出连接都提供支持，它是一个透明的HTTP/1.1到HTTP/2的代理
3. 负载均衡：支持先进的负载均衡能力，包括自动重试、断流、速率限制、请求镜像和区域本地负载均衡等
4. API配置管理：Envoy为动态管理其配置提供了健壮的API
5. 可视化：L7流量的深度可观测性，分布式跟踪的本地支持，MongoDB和DynamoDB数据层面的支持

Istio

• 2017年5月Istio的0.1版本发布，这标志着服务网格第二代产品的诞生，2018年7月Istio又发布了1.0版本。Istio是Google、IBM和Lyft联合发布的产品，靠着这3家公司的强大支持，它很可能成为继Kubernetes之后的另一个重量级产品。在0.1版本发布的时候各个厂商就开始积极响应，Envoy成为Istio默认的数据平面，Linkerd、Nginmesh也放弃了竞争，选择与其集成
• 有了Istio，就几乎可以再需要其他的微服务框架，也不需要自己去实现服务治理，只要客户端和服务端互联互通，把网络层委托给Istio，它就能帮助完成这一系列的功能
• Istio主要功能

1. 对HTTP、gRPC、WebSocket和TCP流量的自动负载均衡
2. 通过路由规则、重试、故障转移和故障注入等功能实现细粒度的流量控制
3. 插件式的策略层以及配置API支持访问控制、速率限制和配额请求
4. 对集群的所有进出流量进行测量、记录并追踪
5. 身份验证和授权保证服务间通信的安全

SOFAMesh

• SOFAMesh由蚂蚁金服发起，控制面板克隆了Istio的开源库并进行了符合自身要求的改进，MOSN是基于Golang开发的全新数据面板，用以替换Envoy
• SOFAMesh除了具有服务网格的基本功能外，还有一些自身的特色

1. 多协议支持：由于公司内部服务和协议的多样化，因此MOSN实现了多协议支持，同时提供了自定义协议以方便扩展
2. 性能：为满足大流量的需要，MOSN在I/O、协议、内存、协程、网络处理等多方面进行了优化，保证了生产环境的需求
3. 安全性：支持mTLS、双向链路加密等