一文告诉你Istio和 spring cloud该怎么选

相信了解SpringCloud的朋友在刚刚开始接触Istio的时候一定会有一个疑问：Istio和 spring cloud也太像了，他们都可以提供服务发现、负截均衡、限流、链路跟踪、鉴权等微服务治理手段，那么二者的主要区别是什么呢？本文就会带大家理解二者的区别，如果您目前对微服务和 Service Mesh还不了解，那么请您忽略本文；如果您只是了解微服务，而不太懂

Service Mesh 可以参考文章：

一文读懂：下一代微服务技术Service Mesh

Istio 概述

Istio 是一个开源服务网格（Service Mesh），它透明地分层到现有的分布式应用程序上。 Istio 强大的特性提供了一种统一和更有效的方式来保护、连接和监视服务。 Istio 是实现负载平衡、服务到服务身份验证和监视的路径——只需要很少或不需要更改服务代码。

它强大的控制平面带来了重要的特点，包括：

• 使用 TLS 加密、强身份认证和授权的集群内服务到服务的安全通信

• 自动负载均衡的 HTTP, gRPC, WebSocket，和 TCP 流量

• 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制

• 一个可插入的策略层和配置 API，支持访问控制、速率限制和配额

• 对集群内的所有流量(包括集群入口和出口)进行自动度量、日志和跟踪

SpringCloud概述

Spring Cloud为开发人员提供了用于快速构建分布式系统中某些常见模式的工具（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线）。主要涉及的组件包括：

Eureka：注册中心

Zuul：服务网关

Rbiibon：负载均衡

Feign：服务调用

Hystrix：熔断器

Istio 和Spring Cloud的区别

大家会发现：Istio和 spring cloud都可以提供服务发现、负截均衡、限流、链路跟踪、鉴权等微服务治理手段，那么二者的主要区别是什么呢？

1. Istio 使用功能强大的 Envoy 服务代理扩展了 Kubernetes，kubernetes本身是一个运维平台，而Spring cloud只是一个开发框架，所以这就注定了Istio在运维层面更为优秀，下图说明了kubernetes和Spring cloud的差异

Istio通过K8S API收集了Service信息来接管后续工作，把流量转发控制权交给了由C++开发的Envoy，Envoy就是Istio的 Sidecar。因此Istio更注重运维而Spring cloud更注重开发；

2.Istio 支持多语言（Istio 实现了Service Mesh，而Service Mesh的核心是改变通信和服务治理能力的提供的方式，通过将这些能力实现从各语言业务实现中解耦，下沉到基础设施层面，以一种更加通用和标准化的方式提供，屏蔽不同语言、不同平台的差异性，有利于通信和服务治理能力的迭代和创新，使得业务实现更加方便。Service Mesh避免了多语言服务治理上的重复建设，通过Service Mesh语言无关的通信和服务治理能力，助力于多语言技术栈的效率提升）；SpringCloud体系的缺点是语言只能指定Java；

3. 个人认为最重要的是spring cloud 是侵入式微服务，而Istio是非侵入式微服务。在Istio中服务发现，注册，调用，负载均衡，降级熔断隔离，网关都是非侵入式的，不需要程序员关心，不需要加入依赖和注解。

从下面这张图中，就可以更为清晰地看到，Istio与springcloud的差异

二者的选择

看到这里，大家一定会认为在Istio和SpringCloud的比较中，Istio会完胜！因为Istio的出现为微服务架构减轻了很多的负担，开发者不需要关心服务调用的超时、重试、rate limit 的实现，服务之间的安全、授权也自动得到了保证；集群管理员也能够很方便地发布应用（AB 测试和灰度发布），并且能清楚看到整个集群的运行情况。

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

因此在采用Isito 之前，必须做好清楚的规划，权衡它带来的好处是否远大于额外维护它的花费，需要有相关的人才对整个网络、kubernetes 和 Istio 都比较了解才行。下图做了一个关于Istio和springcloud的总结，大家可以自行判断选择哪种框架