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

"

如果你更关注新兴技术，你可能在不同的地方听说过Istio，知道它与Service Mesh有关。

这篇文章可以作为了解Istio的入门，了解Istio是什么，为什么Istio最近这么受欢迎，Istio能给我们带来什么好处。

Istio是什么？

Istio的官方介绍浓缩成一句话:

连接、保护、控制和观察服务的开放平台。

翻译过来就是“一个连接、安全加固、控制、观察服务的开放平台”。开放平台就是开源，服务对应微服务，也可以粗略理解为单一应用。

中间的四个动词是Istio的主要功能，每个官方都有自己的解释。这里再解释一下:

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

虽然听起来很高级很厉害，脑子里有那么多名词，但都是很空洞的概念，跟什么都不说一样。要理解这些词的含义，我们先从头说起Service Mesh。

注:其实Istio的起源是微服，但这是个大题目。目前可以参考网上的各种文章。如果有机会，那就说说微服吧。

什么是服务网格

一般介绍Service Mesh的文章都会从网络层的另一个抽象开始，把Service Mesh看成是基于TCP层的微服务层。这次我就换个思路，从Service Mesh-network代理的技术基础来分析。

说到网络代理，我们会想到翻墙。如果熟悉软件架构，会想到Nginx等反向代理软件。

其实网络代理的范围比较广，可以肯定的说，哪里有网络接入，哪里就会有代理。

维基百科对代理的定义如下:

在计算机网络中，代理服务器是一种服务器(计算机系统或应用程序)，它充当从其他服务器寻求资源的客户端请求的中介。

注意:代理可以嵌套，也就是说通信方A和B之间可以有多层代理，这些代理的存在对A和B可能是透明的。

简单来说，网络代理可以简单类比为现实生活中的中介，原本需要沟通的双方因为各种原因在中间加了一道屏障。为什么在双方都能完成沟通的情况下，还要重新发明轮子？

那是因为代理可以给整个通信带来更多的功能，比如:

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

难道不是关于Service Mesh吗？你为什么说很多特工？由于服务网格可以看作是传统代理的升级版，用于解决当前微服务框架中的问题，因此服务网格可以看作是分布式微服务代理。

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

在服务网格中，代理是分布式的，它们驻留在应用程序周围(最常见的是Kubernetes Sidecar模式，在这种模式下，代理运行在每个应用程序的Pod中，负责与流量相关的事务)。

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

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

但在Service Mesh中，代理会知道整个集群的所有应用信息，并添加热更新、注入服务发现、降级融合、认证授权、超时重试、日志监控等附加功能。，这样这些通用功能就不必由每个应用程序自己实现，而可以放在代理中。

也就是说，Service Mesh中的代理对微服务的应用进行了定制和改进！

这样，在微服务和集装箱化的帮助下，传统的代理变成了一个热门的服务网格。

微服务应用后，每个单独的微服务会有多个副本，可能会有多个版本。在如此多的微服务中，相互调用和管理是非常复杂的，但是使用服务网格，我们可以在代理层统一这些内容。

随着分布式代理似乎向各个方向扩展，我们也需要统一管理这些代理。

手动更新每个代理的配置，升级或维护代理是一件不可持续的事情。在上述基础上，增加一个控制中心将成为一个完整的服务网格。

管理员只需要根据控制中心的API配置整个集群的应用流程和安全规则，代理会自动与控制中心进行处理，并根据用户的期望改变其行为。

注:所以你可以理解为Service Mesh中的代理会抢Nginx的业务，这也是Nginx会开始做NginMesh的原因。

让我们再来看看Istio

理解了Service Mesh的概念之后，我们再来看Istio，可能会清楚很多。首先看Istio官方给出的架构图:

可以看到Istio是上面提到的Service Mesh架构的一个实现，服务之间的通信(比如这里的服务A访问服务B)会通过代理(默认为invite)进行。

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

控制中心进一步细分为先导、混合器和城堡，它们各自的功能如下:

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

代理与控制中心通信，控制中心一方面可以获取服务之间所需的信息，另一方面可以报告服务调用的度量数据。

了解Istio的核心架构，非常容易理解其功能描述:

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

Istio解决了什么问题

虽然看起来很酷很强大，但是一个架构和一个产品出来解决具体问题。因此，在这一部分，我们将看看微服务架构中的问题和Istio给出的答案。

首先，把原来单一的应用分成许多分散的微服务，可以互相调用完成一个任务。一旦某个流程出现问题(组件越多，出错的概率越大)，故障排除就非常困难。

用户请求有两个问题:错误和响应慢。如果请求是错误的，那么我们需要知道哪一步出错了。我们如何确定这么多微服务之间的哪个调用成功了？哪个没打成功？

如果请求响应太慢，我们需要知道哪里慢。调用整个环节的每个阶段需要多少时间？哪些调用是并发执行的，哪些是串行执行的？这些问题要求我们非常清楚整个集群的通话和流量。

此外，微服务被分成许多组件，如果单个组件的错误概率是常数，则整个组件的错误概率将会增加。如果在调用一个服务时没有错误处理机制，会导致很多问题。

例如，如果应用程序没有配置超时参数，或者配置的超时参数不正确，会导致请求的调用链超时叠加，这意味着请求被用户卡住。

如果没有重试机制，各种原因导致的偶尔失败也会导致错误直接返回给用户，造成不好的用户体验。

此外，如果某些节点出现异常(如网络中断或高负载)，应用程序的整体响应时间会变长，集群服务应该能够自动避开这些节点上的应用程序。

最后，应用中会出现bug，各种bug会让一些应用无法访问。这些问题需要每个应用程序及时发现问题并采取相应的措施。

应用数量的不断增加也是日常应用发布的一个难题。应用程序的发布需要非常谨慎。如果一次性升级所有应用，错误会使整个在线应用不可用，影响太大。

而且很多时候我们需要同时有不同的版本，用AB测试来验证哪个版本更好。

如果版本升级改变了API，相互依赖，我们也希望在发布时自动控制不同版本访问不同地址。所有这些问题都需要智能流量控制机制。

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

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

上面提到的这些问题熟悉吗？他们是我试图解决的问题。如果你用Istio提供的函数映射上述问题，你会发现它们非常匹配。毕竟，Istio似乎解决了这些微观服务的问题。

在什么位置可以访问Istio？

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

一般来说，集群管理团队需要熟悉Kubernetes，了解常用的使用模式，然后以渐进的方式分批控制Istio的功能。

第一步，自然是在测试环境中构建一组Istio集群，了解所有核心概念和组件。

了解Istio提供的接口和资源，了解它们的用途，思考如何将它们应用到自己的场景中。然后，熟悉Istio的源代码，跟进社区中的Issues，了解现有的Issues和bug，思考如何避免或修复它们。

这一步是基础，需要积累Istio安装部署、核心概念、功能、缺陷等相关知识，为未来做准备。

在第二步中，我们可以考虑访问Istio的观察功能，包括日志记录、跟踪和度量数据。

将应用部署到集群中，对部分应用(一般是流量小、影响范围小的应用)选择性启用Istio自动注入功能，接管应用的流量，安装Prometheus、Zipkin等监控组件，收集系统的所有监控数据。

这一步可以初步了解Istio对应用性能的影响，建立服务性能测试基准，发现服务性能瓶颈，帮助快速定位可能出现的应用问题。

此时，这些功能对应用程序开发人员来说是透明的，只需要集群管理员感知即可，这样可以降低可能的风险。

第三步是为应用程序配置超时参数、自动重试、融合和降级，以提高服务的容错能力。

这样，可以避免一些应用程序错误地进行这些配置所导致的问题。这一步完成后，需要通知所有应用程序开发人员删除应用程序代码中相应的处理逻辑。这一步需要开发人员和集群管理员的参与。

第四步，与Ingress、Helm、应用程序盘架等相关组件和流程对接，使用Istio接管应用程序的升级和发布流程。

允许开发者配置应用灰色发布的升级策略，支持应用蓝绿色发布、加那利发布、AB测试。

第五步是访问安全功能。配置应用的TLS相互信任，添加RBAC授权，设置应用的流量限制，提高整个集群的安全性。

因为安全问题配置比较繁琐，优先级一般比功能性相关的特性低，所以放在这里结束。

当然这一步只是参考，每个公司都需要根据自己的情况、人力、时间、节奏进行调整，找到自己的解决方案。

总结

Istio架构在数据中心和集群管理中非常常见。每个代理分布在不同的节点上(可以是服务器、虚拟机、PODs和容器)，负责接收指令、执行指令和报告信息。

控制中心负责收集整个集群的信息，并为用户提供管理集群的API。

Kubernetes和SDN(软件定义网络)是类似的架构。

我相信未来会有更多类似的架构，因为数据中心需要管理的节点越来越多，我们需要将任务执行分配到每个节点(Agent负责的功能)。

同时需要对整个集群进行管理和控制(控制平面的功能)，完全分散的架构无法满足后者的要求。

Istio的出现为负责任的微服务架构减轻了很多负担。开发人员不必关心服务调用的超时、重试以及Rate Limit的实现，服务之间的安全性和授权是自动保证的。

集群管理员还可以轻松发布应用(AB测试和灰度发布)，可以清晰的看到整个集群的运行情况。

但是，这并不意味着你可以和Istio坐在一起放松。Istio只是把分散在应用中的复杂性抽象出来放在一个统一的地方，并没有让原来的复杂性消失。

所以我们需要维护Istio的整个集群，但是Istio的架构比较复杂，特别是需要建立在Kubernetes上。这两个系统比较复杂，稳定性和性能都会影响整个集群。

所以在采用Isito之前，一定要做好明确的规划，权衡它带来的收益是否远大于维护它的额外成本，需要相关人才对整个网络、Kubernetes和Istio有更好的了解。

参考文献:

Istio / What is Istio?：istio 官网上对 istio 进行介绍的文档Pattern：Service Mesh：service mesh pattern 详解的文章

来源:http://cizixs.com/2018/08/26/what-is-istio