Istio究竟是干嘛的？
Istio究竟是干嘛的？
当微服务架构体系越来越复杂的时候，需要将“业务服务”和“基础设施”解耦，将一个微服务进程一分为二：
一个进程实现业务逻辑，biz，即上图白色方块
一个进程实现底层技术体系，proxy，即上图蓝色方块，负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现
如此解耦之后：
biz不管是调用服务，还是提供服务，都只与本地的proxy进行本地通信
所有跨网的通信，都通过proxy之间进行
要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的实践，今天说说Istio是干啥的。
画外音：不能落伍。
什么是Istio?
Istio是ServiceMesh的产品化落地，它的一些关键性描述是：
(1) 帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全
画外音：Istio helps you to connect, secure, control, and observe microservices.
(2) 帮助微服务分层解耦，解耦后的proxy层能够更加专注于提供基础架构能力，例如：
服务发现(discovery);
负载均衡(load balancing);
故障恢复(failure recovery);
服务度量(metrics);
服务监控(monitoring);
A/B测试(A/B testing);
灰度发布(canary rollouts);
限流限速(rate limiting);
访问控制(access control);
身份认证(end-to-end authentication);
画外音：佩服，硬是凑齐了十条，其实ServiceMesh还能提供更多基础服务功能。
(3) 使得业务工程团队与基础架构团队都更加高效的工作，各自专注于自己的工作，更好的彼此赋能
画外音：说的还是解耦。
Istio官网是怎么吹嘘自己的?
画外音：这个问题的另一个问法是“为什么大家要来用Istio”。
Istio非常牛逼，如果要实施ServiceMesh，必须用Istio，因为：
(1) 可以通过，在现有服务器新增部署边车代理(sidecar proxy)，应用程序不用改代码，或者只需要改很少的代码，就能实现上述N项基础功能
画外音：你信了么?
(2) 可以通过，控制后台，简单改改配置，点点按钮，就能管理和查看上述N项基础功能
(3) 以下特性，Istio在这个环节里进行了附加说明：
负载均衡支持多协议，HTTP, gRPC, WebSocket, TCP
通过路由、重试、故障转移对流量进行细粒度流控
通过可插拔策略层以及可配置API，能够支持流量访问控制、限速、配额管理
自动度量、日志收集、调用跟踪
服务到服务的身份认证
Istio的核心特性是什么?
Istio强调了它提供的五项关键特性：
(1) 流控(traffic management)
画外音：断路器(circuit breakers)、超时、重试、高可用、多路由规则、AB测试、灰度发布、按照百分比分配流量等。
(2) 安全(security)
画外音：加密、身份认证、服务到服务的权限控制、K8S里容器到容器的权限控制等。
(3) 可观察(observability)
画外音：追踪、监控、数据收集，通过控制后台全面了解上行下行流量，服务链路情况，服务运行情况，系统性能情况，国内微服务架构体系，这一块做得比较缺乏。
(4) 平台无关系(platform support)
画外音：K8s，物理机，自己的虚机都没问题。
(5) 集成与定制(integration and customization)
画外音：可定制化扩展功能。
Istio的吹嘘与特性，对于国外很多通过RESTful提供内网服务的公司，很有吸引力，但相对于国内微服务架构，未必达到了很好的拉拢效果：
国内基本都是TCP的RPC框架，多协议支持未必是必须的
RPC框架里，路由、重试、故障转移、负载均衡、高可用都是最基础的
流控、限速、配额管理，是服务治理的内容，在微服务架构初期是锦上添花
自动度量，系统入口出口数据收集，调用跟踪，可观察和可操控的后台确实是最吸引人的
服务到服务的身份认证，微服务基本是内网访问，在架构初期也只是锦上添花;
另外一个花边，为什么代理会叫sidecar proxy?
看了上图就容易懂了，biz和proxy相生相伴，就像摩托车(motor)与旁边的车厢(sidecar)。未来，sidecar和proxy就指微服务进程解耦成两个进程之后，提供基础能力的那个代理进程。