Istio是啥？

Posted 2023-05-06

前几天群里同学们在讨论微服务、服务网格，有人提到了 Istio ，想了解这个系统究竟有何意义？

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络，而不需要对服务的代码进行任何修改。你只需要在部署环境中，例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持，用来截获微服务之间的网络流量。

特性：
使用istio的进行微服务管理有如下特性：
流量管理：控制服务间的流量和API调用流，使调用更可靠，增强不同环境下的网络鲁棒性。可观测性：了解服务之间的依赖关系和它们之间的性质和流量，提供快速识别定位问题的能力。

策略实施：通过配置mesh而不是以改变代码的方式来控制服务之间的访问策略。
服务识别和安全：提供在mesh里的服务可识别性和安全性保护。
未来将支持多种平台，不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。

正是 Istio 的出现使 “Service Mesh”（ 服务网格 ） 这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解为多个微服务。虽然这种方式简化了单个服务的开发，但对于成百上千的微服务的通信、监控以及安全性的管理并不是一件简单的事。
直至目前，对于这些问题的解决方案也只是通过自定义脚本、类库等方式将服务串联在一起，并且投入专门的人力以处理分布式系统的管理任务。但这种方式降低了各个团队的效率，并且提高了维护的成本。这正是 Service Mesh 大显身手的时机

Istio以及Service Mesh的未来

参考技术A

服务网格在国内开始有热度不过是近两年的事，业界有很多开源的服务网格框架，例如 Istio、linkerd2、kuma、nginMesh、maesh等，其中，Istio是目前服务网格领域最流行的开源项目，38% 的企业在生产中使用服务网格，其中有接近一半的选择是Istio。

咱们来聊聊，Istio为何能火？

一、什么是 Istio

下面我们一起来看下 Istio 的架构：

Istio 架构

从上图我们可以看出，Istio 服务网格从逻辑上分为数据平面（Data plane）和控制平面（Control plane）：

数据平面（Data plane）：直接处理入站和出站数据包，提供转发、路由、健康检查、负载均衡、熔断、认证、鉴权、故障注入、可观测能力。

控制平面（Control plane）：提供服务发现、配置和证书管理能力。

在构建大型分布式系统的时候，将控制面和数据面分离开是一种常见的模式。数据面会直接和具体的应用交互，而控制面的组件会下发一系列的配置和指令，帮助数据面完成具体的工作。

二、Istio 的性能

使用两台阿里云 ecs.g6.2xlarge 机器，其中一台部署压测工具 Fortio，另外一台部署Service A和 Service A 的边车。在使用 fannel 网格插件的情况下，用 30 并发进行压测，压测场景如下图所示，其中 Service A 接收到请求不做任何逻辑处理直接返回，Fortios 通过边车调用 Service A 的平均响应时间为 2.505ms。在同样的并发下，不部署 Service A 的边车，通过Fortios 调用 Service A 的平均响应时间为 0.936ms。

服务网格带来的性能损耗包含两个方面：

1、流量策略、可观察性和安全通信带来的损耗，这些损耗是任何微服务框架均存在的，需要不断优化 Envoy 本身的性能来提升。

2、服务网格微服务之间的调用经过边车后，与传统服务框架相比，多了两次网络调用，这是服务网格额外带来的性能损耗。

服务网格默认采用的是 iptables 流量劫持的方式，流量经过边车 Envoy 时，会经过两次 TCP/IP协议栈，图 8 所示，当服务数量大的时候会有大量的 iptables 规则，影响网络性能。目前业界的一个思路是使用 eBPF 这样的技术来提高应用性能，基于eBPF使微服务跟边车直接通过 Socket 通讯，但是该技术对操作系统内核的版本要求比较高，因此很少有企业能够达到。

行云创新对Istio的思考

1、SolarMesh，是基于 Istio 及容器技术，提供流量监控和管理，提供完善的非侵入式服务治理解决方案。

2、SolarMesh，可以帮助企业在纷繁复杂的微服务调度中快速定位问题，增强研发效率。

3、SolarMesh，可以通过流量灰度让版本更新更加平滑，降低版本升级风险。

4、SolarMesh，支持实时反映真实集群状态，以流量的角度凸显业务问题，增强运维能力。

5、SolarMesh，支持多集群管理，可对接任意数量的标准k8s集群，接入成本极低。

SolarMesh 对Istio社区的产品化改进

1、Istio的直连模式，在sidecar故障时提供秒级的直连流量切换；

2、多集群统一纳管，为流量运维提供上帝视角；

3、可视化、规范化Istio操作，告别terminal；

4、反应集群真实情况，流量可视化监控；

5、为istio核心组件提供监控能力；

6、服务质量(SLO)检测能力；

7、一键部署分布式链路追踪组件jaeger；

8、一键部署数据可视化工具grafana，进一步提升流量监控的体验；

……

Istio是啥？一文带你彻底了解！

Istio是什么

官方对 Istio 的介绍浓缩成了一句话：
An open platform to connect, secure, control and observe services.
翻译过来，就是”连接、安全加固、控制和观察服务的开放平台“。开放平台就是指它本身是开源的，服务对应的是微服务，也可以粗略地理解为单个应用。

• 连接（Connect）：智能控制服务之间的调用流量，能够实现灰度升级、AB 测试和红黑部署等功能
• 安全加固（Secure）：自动为服务之间的调用提供认证、授权和加密。
• 控制（Control）：应用用户定义的 policy，保证资源在消费者中公平分配。
• 观察（Observe）：查看服务运行期间的各种数据，比如日志、监控和 tracing，了解服务的运行情况。

NOTE：其实 Istio 的源头是微服务，又涉及到Service Mesh

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

• istio 适用于容器或虚拟机环境（特别是 k8s），兼容异构架构。
• istio 使用 sidecar（边车模式）代理服务的网络，不需要对业务代码本身做任何的改动。
• HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
• istio 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制；支持访问控制、速率限制和配额。
• istio 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。

什么是Service Mesh

Service Mesh 看做建立在 TCP 层之上的微服务层。从 Service Mesh 的技术根基——网络代理来分析。因为 Service Mesh 可以看做是传统代理的升级版，用来解决现在微服务框架中出现的问题，可以把 Service Mesh 看做是分布式的微服务代理。

说起网络代理，我们会想到FQ，如果对软件架构比较熟悉的会想到 Nginx 等反向代理软件。
NOTE：代理可以是嵌套的，也就是说通信双方 A、B 中间可以多多层代理，而这些代理的存在有可能对 A、B 是透明的。

代理可以为整个通信带来更多的功能，比如：

• 拦截：代理可以选择性拦截传输的网络流量，比如一些公司限制员工在上班的时候不能访问某些游戏或者电商网站，再比如把我们和世界隔离开来的 GFW，还有在数据中心中拒绝恶意访问的网关。
• 统计：既然所有的流量都经过代理，那么代理也可以用来统计网络中的数据信息，比如了解哪些人在访问哪些网站，通信的应答延迟等。
• 缓存：如果通信双方比较”远“，访问比较慢，那么代理可以把最近访问的数据缓存在本地，后面的访问不用访问后端来做到加速。CDN 就是这个功能的典型场景。
• 分发：如果某个通信方有多个服务器后端，代理可以根据某些规则来选择如何把流量发送给多个服务器，也就是我们常说的负载均衡功能，比如著名的 Nginx 软件。
• 跳板：如果 A、B 双方因为某些原因不能直接访问，而代理可以和双方通信，那么通过代理，双方可以绕过原来的限制进行通信。这应该是广大中国网民比较熟悉的场景。
• 注入：既然代理可以看到流量，那么它也可以修改网络流量，可以自动在收到的流量中添加一些数据，比如有些宽带提供商的弹窗广告。

在传统模式下，代理一般是集中式的单独的服务器，所有的请求都要先通过代理，然后再流入转发到实际的后端。

而在 Service Mesh 中，代理变成了分布式的，它常驻在了应用的身边（最常见的就是 Kubernetes Sidecar 模式，每一个应用的 Pod 中都运行着一个代理，负责流量相关的事情）。

这样的话，应用所有的流量都被代理接管，那么这个代理就能做到上面提到的所有可能的事情，从而带来无限的想象力。

此外，原来的代理都是基于网络流量的，一般都是工作在 IP 或者 TCP 层，很少关心具体的应用逻辑。

但是 Service Mesh 中，代理会知道整个集群的所有应用信息，并且额外添加了热更新、注入服务发现、降级熔断、认证授权、超时重试、日志监控等功能，让这些通用的功能不必每个应用都自己实现，放在代理中即可。

换句话说，Service Mesh 中的代理对微服务中的应用做了定制化的改进！

就这样，借着微服务和容器化的东风，传统的代理摇身一变，成了如今炙手可热的 Service Mesh。

应用微服务之后，每个单独的微服务都会有很多副本，而且可能会有多个版本，这么多微服务之间的相互调用和管理非常复杂，但是有了 Service Mesh，我们可以把这块内容统一在代理层。

---

有了看起来四通八达的分布式代理，我们还需要对这些代理进行统一的管理。

手动更新每个代理的配置，对代理进行升级或者维护是个不可持续的事情，在前面的基础上，在加上一个控制中心，一个完整的 Service Mesh 就成了。

管理员只需要根据控制中心的 API 来配置整个集群的应用流量、安全规则即可，代理会自动和控制中心打交道根据用户的期望改变自己的行为。

NOTE：所以你也可以理解 Service Mesh 中的代理会抢了 Nginx 的生意，这也是为了 Nginx 也要开始做 NginMesh 的原因。

什么是Istio

可以看到，Istio 就是我们上述提到的 Service Mesh 架构的一种实现，服务之间的通信（比如这里的 Service A 访问 Service B）会通过代理（默认是 Envoy）来进行。

而且中间的网络协议支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以说覆盖了主流的通信协议。

控制中心做了进一步的细分，分成了 Pilot、Mixer 和 Citadel，它们的各自功能如下：

• Pilot：为 Envoy 提供了服务发现，流量管理和智能路由（AB 测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。 用户通过 Pilot 的 API 管理网络相关的资源对象，Pilot 会根据用户的配置和服务的信息把网络流量管理变成 Envoy 能识别的格式分发到各个 Sidecar 代理中。
• Mixer：为整个集群执行访问控制（哪些用户可以访问哪些服务）和 Policy 管理（Rate Limit，Quota 等），并且收集代理观察到的服务之间的流量统计数据。
• Citadel：为服务之间提供认证和证书管理，可以让服务自动升级成 TLS 协议。

代理会和控制中心通信，一方面可以获取需要的服务之间的信息，另一方面也可以汇报服务调用的 Metrics 数据。

知道了 Istio 的核心架构，再来看看它的功能描述就非常容易理解了：

• 连接：控制中心可以从集群中获取所有服务的信息，并分发给代理，这样代理就能根据用户的期望来完成服务之间的通信（自动地服务发现、负载均衡、流量控制等）。
• 安全加固：因为所有的流量都是通过代理的，那么代理接收到不加密的网络流量之后，可以自动做一次封装，把它升级成安全的加密流量。
• 控制：用户可以配置各种规则（比如 RBAC 授权、白名单、Rate Limit 或者 Quota 等），当代理发现服务之间的访问不符合这些规则，就直接拒绝掉。
• 观察：所有的流量都经过代理，因此代理对整个集群的访问情况知道得一清二楚，它把这些数据上报到控制中心，那么管理员就能观察到整个集群的流量情况了

Istio解决什么问题

虽然看起来非常炫酷，功能也很强大，但是一个架构和产品出来都是要解决具体的问题。所以这部分我们来看看微服务架构中的难题以及 Istio 给出的答案。

首先，原来的单个应用拆分成了许多分散的微服务，它们之间相互调用才能完成一个任务，而一旦某个过程出错（组件越多，出错的概率也就越大），就非常难以排查。

用户请求出现问题无外乎两个问题：错误和响应慢。如果请求错误，那么我们需要知道那个步骤出错了，这么多的微服务之间的调用怎么确定哪个有调用成功？哪个没有调用成功呢？

如果是请求响应太慢，我们就需要知道到底哪些地方比较慢？整个链路的调用各阶段耗时是多少？哪些调用是并发执行的，哪些是串行的？这些问题需要我们能非常清楚整个集群的调用以及流量情况。

此外，微服务拆分成这么多组件，如果单个组件出错的概率不变，那么整体有地方出错的概率就会增大。服务调用的时候如果没有错误处理机制，那么会导致非常多的问题。

比如如果应用没有配置超时参数，或者配置的超时参数不对，则会导致请求的调用链超时叠加，对于用户来说就是请求卡住了。

如果没有重试机制，那么因为各种原因导致的偶发故障也会导致直接返回错误给用户，造成不好的用户体验。

此外，如果某些节点异常（比如网络中断，或者负载很高），也会导致应用整体的响应时间变长，集群服务应该能自动避开这些节点上的应用。

最后，应用也是会出现 Bug 的，各种 Bug 会导致某些应用不可访问。这些问题需要每个应用能及时发现问题，并做好对应的处理措施。

应用数量的增多，对于日常的应用发布来说也是个难题。应用的发布需要非常谨慎，如果应用都是一次性升级的，出现错误会导致整个线上应用不可用，影响范围太大。

而且，很多情况我们需要同时存在不同的版本，使用 AB 测试验证哪个版本更好。

如果版本升级改动了 API，并且互相有依赖，那么我们还希望能自动地控制发布期间不同版本访问不同的地址。这些问题都需要智能的流量控制机制。

为了保证整个系统的安全性，每个应用都需要实现一套相似的认证、授权、HTTPS、限流等功能。

一方面大多数的程序员都对安全相关的功能并不擅长或者感兴趣，另外这些完全相似的内容每次都要实现一遍是非常冗余的。这个问题需要一个能自动管理安全相关内容的系统。

上面提到的这些问题是不是非常熟悉？它们就是 Istio 尝试解决的问题，如果把上面的问题和 Istio 提供的功能做个映射，你会发现它们非常匹配，毕竟 Istio 就是为了解决微服务的这些问题才出现的。

用什么姿势接入Istio

虽然 Istio 能解决那么多的问题，但是引入 Istio 并不是没有代价的。最大的问题是 Istio 的复杂性，强大的功能也意味着 Istio 的概念和组件非常多，要想理解和掌握 Istio ，并成功在生产环境中部署需要非常详细的规划。

一般情况下，集群管理团队需要对 Kubernetes 非常熟悉，了解常用的使用模式，然后采用逐步演进的方式把 Istio 的功能分批掌控下来。

第一步，自然是在测试环境搭建一套 Istio 的集群，理解所有的核心概念和组件。
了解 Istio 提供的接口和资源，知道它们的用处，思考如何应用到自己的场景中，然后是熟悉 Istio 的源代码，跟进社区的 Issues，了解目前还存在的 Issues 和 Bug，思考如何规避或者修复。
这一步是基础，需要积累到 Istio 安装部署、核心概念、功能和缺陷相关的知识，为后面做好准备。

第二步，可以考虑接入 Istio 的观察性功能，包括 Logging、Tracing、Metrics 数据。
应用部署到集群中，选择性地（一般是流量比较小，影响范围不大的应用）为一些应用开启 Istio 自动注入功能，接管应用的流量，并安装 Prometheus 和 Zipkin 等监控组件，收集系统所有的监控数据。
这一步可以试探性地了解 Istio 对应用的性能影响，同时建立服务的性能测试基准，发现服务的性能瓶颈，帮助快速定位应用可能出现的问题。
此时，这些功能可以是对应用开发者透明的，只需要集群管理员感知，这样可以减少可能带来的风险。

第三步，为应用配置 Time Out 超时参数、自动重试、熔断和降级等功能，增加服务的容错性。
这样可以避免某些应用错误进行这些配置导致问题的出现，这一步完成后需要通知所有的应用开发者删除掉在应用代码中对应的处理逻辑。这一步需要开发者和集群管理员同时参与。

第四步，和 Ingress、Helm、应用上架等相关组件和流程对接，使用 Istio 接管应用的升级发布流程。
让开发者可以配置应用灰度发布升级的策略，支持应用的蓝绿发布、金丝雀发布以及 AB 测试。

第五步，接入安全功能。配置应用的 TLS 互信，添加 RBAC 授权，设置应用的流量限制，提升整个集群的安全性。
因为安全的问题配置比较繁琐，而且优先级一般会比功能性相关的特性要低，所以这里放在了最后。

当然这个步骤只是一个参考，每个公司需要根据自己的情况、人力、时间和节奏来调整，找到适合自己的方案。

总结

Istio 的架构在数据中心和集群管理中非常常见，每个 Agent 分布在各个节点上（可以是服务器、虚拟机、Pod、容器）负责接收指令并执行，以及汇报信息。

控制中心负责汇聚整个集群的信息，并提供 API 让用户对集群进行管理。

Kubernetes 也是类似的架构，SDN（Software Defined Network） 也是如此。

相信以后会有更多类似架构的出现，这是因为数据中心要管理的节点越来越多，我们需要把任务执行分布到各节点（Agent 负责的功能）。

同时也需要对整个集群进行管理和控制（Control Plane 的功能），完全去中心化的架构是无法满足后面这个要求的。

Istio 的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、Rate Limit 的实现，服务之间的安全、授权也自动得到了保证。

集群管理员也能够很方便地发布应用（AB 测试和灰度发布），并且能清楚看到整个集群的运行情况。

但是这并不表明有了 Istio 就可以高枕无忧了，Istio 只是把原来分散在应用内部的复杂性统一抽象出来放到了统一的地方，并没有让原来的复杂消失不见。

因此我们需要维护 Istio 整个集群，而 Istio 的架构比较复杂，尤其是它一般还需要架在 Kubernetes 之上，这两个系统都比较复杂，而且它们的稳定性和性能会影响到整个集群。

因此再采用 Isito 之前，必须做好清楚的规划，权衡它带来的好处是否远大于额外维护它的花费，需要有相关的人才对整个网络、Kubernetes 和 Istio 都比较了解才行。

Istio用例

https://www.jianshu.com/p/bed143a1c886