相信了解SpringCloud的朋友在剛剛開始接觸Istio的時候一定會有一個疑問：Istio和 spring cloud也太像了，他們都可以提供服務發現、負截均衡、限流、鏈路跟蹤、鑒權等微服務治理手段，那么二者的主要區別是什么呢？本文就會帶大家理解二者的區別，如果您目前對微服務和 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的總結，大家可以自行判斷選擇哪種框架。