什么是 istio和服务网格？

什么是 istio？

官方对 istio 的介绍浓缩成了一句话：

An open platform to connect, secure, control and observe services.

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

中间的四个动词就是 istio 的主要功能，官方也各有一句话的说明。这里再阐释一下：

• 连接（Connect）：智能控制服务之间的调用流量，能够实现灰度升级、AB 测试和红黑部署等功能

• 安全加固（Secure）：自动为服务之间的调用提供认证、授权和加密

• 控制（Control）：应用用户定义的 policy，保证资源在消费者中公平分配

• 观察（Observe）：查看服务运行期间的各种数据，比如日志、监控和 tracing，了解服务的运行情况

什么是 service mesh

先说说网络代理，网络代理可以简单类比成现实生活中的中介，本来需要通信的双方因为各种原因在中间再加上一道关卡。本来双方就能完成的通信，为何非要多此一举呢？那是因为代理可以为整个通信带来更多的功能，比如：

• 拦截：代理可以选择性拦截传输的网络流量，比如一些公司限制员工在上班的时候不能访问某些游戏或者电商网站，再比如把我们和世界隔离开来的 GFW，还有在数据中心中拒绝恶意访问的网关

• 统计：既然所有的流量都经过代理，那么代理也可以用来统计网络中的数据信息，比如了解哪些人在访问哪些网站，通信的应答延迟等

• 缓存：如果通信双方比较”远“，访问比较慢，那么代理可以把最近访问的数据缓存在本地，后面的访问不用访问后端来做到加速。CDN 就是这个功能的典型场景

• 分发：如果某个通信方有多个服务器后端，代理可以根据某些规则来选择如何把流量发送给多个服务器，也就是我们常说的负载均衡功能。比如著名的 Nginx 软件

• 跳板：如果 A、B 双方因为某些原因不能直接访问，而代理可以和双方通信，那么通过代理，双方可以绕过原来的限制进行通信。这应该广大中国网民比较熟悉的场景

• 注入：既然代理可以看到流量，那么它也可以修改网络流量，可以自动在收到的流量中添加一些数据，比如有些宽带提供商的弹窗广告

service mesh 可以看做是传统代理的升级版，用来解决现在微服务框架中出现的问题，可以把 service mesh 看做是分布式的微服务代理。

原来的代理都是基于网络流量的，一般都是工作在 IP 或者 TCP 层，很少关心具体的应用逻辑。但是 service mesh 中，代理会知道整个集群的所有应用信息，并且额外添加了热更新、注入服务发现、降级熔断、认证授权、超时重试、日志监控等功能，让这些通用的功能不必每个应用都自己实现，放在代理中即可。换句话说，service mesh 中的代理对微服务中的应用做了定制化的改进！

总结

Istio 的架构在数据中心和集群管理中非常常见，每个 agent 分布在各个节点上（可以是服务器、虚拟机、pod、容器）负责接收指令并执行，以及汇报信息；控制中心负责汇聚整个集群的信息，并提供 API 让用户对集群进行管理。kubernetes 也是类似的架构，SDN（Software Defined Network） 也是如此。

相信以后会有更多类似架构的出现，这是因为数据中心要管理的节点越来越多，我们需要把任务执行分布到各节点（agent 负责的功能），同时也需要对整个集群进行管理和控制（control plane 的功能），完全去中心化的架构是无法满足后面这个要求的。

Istio 的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、rate limit 的实现，服务之间的安全、授权也自动得到了保证；集群管理员也能够很方便地发布应用（AB 测试和灰度发布），并且能清楚看到整个集群的运行情况。

但是这并不表明有了 istio 就可以高枕无忧了，istio 只是把原来分散在应用内部的复杂性统一抽象出来放到了统一的地方，并没有让原来的复杂消失不见。因此我们需要维护 istio 整个集群，而 istio 的架构比较复杂，尤其是它一般还需要架在 kubernetes 之上，这两个系统都比较复杂，而且它们的稳定性和性能会影响到整个集群。

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

https://www.cnblogs.com/lidabo/p/16453818.html