Spring Cloud? Kubernetes? Istio?服務治理方案怎麼選

不一樣選擇分別表明了兩個方向：html

sidecar分離了服務治理所需的部分職能到與業務應用不一樣的進程中完成，也表明着：

這些好處顯而易見，在happy-path下咱們可能無往不利

但同時也意味着：

熔斷、限流等須要DevOps人員不止關注到業務應用，還須要對不一樣接口進行配置管理。可能須要和開發人員對齊不一樣接口的設計規格（流量、負載、可用性指標等）
根據老馬對熔斷的描述，熔斷不僅僅是斷掉就萬事大吉，須要咱們關注降級處理方案（fallback）(注1），而這些istio並未提供支持（注2，3）
灰度/金絲雀發佈在istio中的實現方案（注七、8）基於header(cookie)，意味着可能會信息泄露或被客戶端仿造，若內部組件控制則可能再次出現業務邏輯的耦合
灰度/金絲雀發佈在某些需求下可能涉及業務邏輯（如：VIP會員能夠嚐鮮新版應用），須要定製化開發路由邏輯，而在sidecar中編入業務邏輯明顯不符合其設計初衷
定位錯誤、調試、定製化開發不一樣程度上須要團隊中有對應平臺（Go，C++等）經驗的自身工程師存在，而且該工程師須要高度適應平臺的快速迭代
sidecar不是特等公民，同樣會崩潰、報錯（注4）。monitor 和metrics等監控、報警相關基礎設施及配置也是必經之路（注5）
兩次請求轉發帶來的性能損耗不可忽視，在不一樣的掛載方案中性能損耗可能有數倍差異（注6），被掛載sidecar的應用thoughtput能力越強，性能損耗對其影響越大

固然，以上問題並非全部服務集羣都涉及到，簡單概括結論即：

適合採用或繼續選擇SpringCloud方案的狀況：

適合採用Kubernetes/Istio方案的狀況：

一點發散思惟：

若是咱們順着用sidecar分離非業務代碼的方向走，

那咱們的應用系統與數據庫、磁盤等外部資源進行通訊的時候，是否要：

注：

最後，若是以上觀點對你帶來了一點點幫助或者啓發，動動鼠標點個讚唄