Spring Cloud or Cloud Native

基于Java的 Spring Cloud 是由Java最大開源生态 Spring 社群推出的Out-of-Box分布式 微服務 解決方案， 自2016年釋出 起就被衆多開發者看好。Java作為廣為流行的服務端程式設計語言， 也就越來越多的被用于微服務開發。 內建了 Netflix OSS 開源項目實作了很多功能(或作為實作之一)，包括服務治理、網關路由、用戶端負載均衡、服務間調用、斷路器等。 Spring Cloud Netflix 将很多生産級别微服務能力開箱即用的帶到了Spring Cloud架構下的微服務中，幫助開發者快速的建構滿足 12要素

的應用。

在去年底釋出的

Spring Cloud Greenwich版本 中宣布 中重要的元件 Hystrix 、 Ribbon

Zuul 1

等由于上遊開源項目進入維護狀态，對應的Spring Cloud Netflix項目也進入到維護狀态。這些項目将不再适合用于長期維護的産品中！

同時随着近年雲計算的發展，特别是

Kubernetes 成為容器編排平台的事實标準，加上 Service Mesh(服務網格) 對微服務的服務治理和流量控制，為 雲原生應用

提供了更為現代、平台無關的解決方案。

讓我們逐一看看在

加上Serivce Mesh(例如 Istio )如何實作微服務的服務發現、路由、鍊路追蹤、斷路器等功能。

配置中心

Spring Cloud Config

預設提供了多種配置管理後端，例如

Git

Vault

JDBC Backend

等。同時也有很多開源方案可以作為替換方案，比如

Alibaba Nacos

。

作為部署在

中的應用，最佳實踐是平衡

Configmap

和

。将涉及程式功能的配置放置在

和Secret，随同微服務的釋出一起做版本管理，可以做到随着應用回退的時候同時回退到曆史對應的配置版本，而不會因為曆史版本的代碼被最新版本的配置所中斷。

Spring Cloud Kuberentes

項目很好的支援了Spring Cloud應用從

Secret

中讀取配置項。而涉及業務的配置選項，将可以考慮放到Spring Cloud Config後端實作統一管理。如果應用是部署在阿裡雲，使用阿裡雲托管的配置服務和

Spring Cloud Config -- Nacos

将是很好的選擇。

服務發現

Kubernetes Services

提供了叢集内原生的服務發現能力，是

Eureka

或

Spring Cloud Zookeeper

等服務發現服務的很好替代品。基于K8S Services的服務發現，很容易通過Service Mesh能力實作限流、A/B測試、金絲雀釋出、斷路器、chaos注入等服務治理能力。同時對微服務應用來說，不用在應用端添加對應三方庫來實作服務注冊及發現，減少了應用端開發需求。

各種流量治理場景

應用被服務化後，一定會面臨流量治理的問題。對于各種服務間如何實作限流、A/B測試、金絲雀釋出、斷路器、chaos注入測試、連結追蹤等，這其實是一類通用的問題。

提供的是一種用戶端解決思路，需要每個應用引入對應功能的libraries的支援。即使通過

spring boot starter

提供了近似開箱即用的能力，但是每個應用仍然需要自行添加對應的能力，版本更新、安全漏洞fix等場景都需要手動更新、測試、打包、部署。在異構程式設計語言實作的微服務架構下，未必每種程式設計架構都能提供很好的對應能力支援。除非有特别的服務治理政策，不推薦在微服務自身來實作服務流量的控制。

Service Mesh(例如

Linkerd

)從整個服務治理層面對上述需求提供了統一的解決方案，而不需要微服務做自身的更新或改動。在基于Kuberentes部署運作的微服務應用，Service Mesh提供了統一的服務治理方案，将使用者從不同的微服務中自身維護服務治理功能中解放出來，從平台層面提供更加統一一緻的解決方案。

在去年的SpringOne Platform 2018上也有一個Topic

A Tale of Two Frameworks: Spring Cloud and Istio

探讨什麼場景應該使用Service Mesh，什麼時候使用Spring Cloud服務治理元件，有興趣的朋友可以看一看。