Spring Cloud：面向應用層的雲架構解決方案

上期文章我們介紹了混合雲，以及在實際操作中我們常見的幾種混合雲模式。今天我們來聊一聊Spring Cloud如何解決應用層的雲架構問題。

對於Spring Cloud，你大概不會陌生，它跟Spring生態中的另一個開源專案Spring Boot，基本上已經成為國內絕大多數公司向微服務架構轉型時的首選開發框架。

Spring Boot可以支援快速開發單個微服務應用，Spring Cloud則提供一系列的服務治理框架，比如服務註冊、服務發現、動態路由、負載均衡以及熔斷等等能力，可以將一個個獨立的微服務作為一個整體，進行很好的管理和維護。

從業界實際使用情況和反饋來看，由於兩者完美的搭配，Spring Cloud和Spring Boot確實是可以通過相對較低的技術成本，讓開發人員方便快速地搭建起一套分散式應用系統，從而進行高效的業務開發

同時，優秀的服務治理能力，也為其後續在穩定性保障工作方面打下了不錯的基礎。（注：因為Spring Cloud必須基於Spring Boot框架才能發揮它的治理能力，所以下面我們提到的Spring Cloud是預設包含了Spring Boot框架的。）

所以，通常我們更多地是把Spring Cloud作為微服務應用層面的開發框架，幫助我們提升開發效率。看起來，它貌似跟“雲”這個概念沒有什麼直接關係。

而實際上，在將應用與雲平臺連線方面，Spring Cloud也發揮著非常核心的作用。這也是為什麼本期文章的標題沒有直接定義為微服務治理架構，而是面向應用層的雲架構。

下面我們具體來看看。

Spring Cloud框架中雲的影子

目前整個Spring生態是由Pivotal這家商業公司在主導，但是Pivotal更大的目標是要為客戶提供雲上的端到端的解決方案。

所以Pivotal最早提出了Cloud-Native（雲原生）的概念，或者說是一種理念，目的是幫企業提供雲上業務端到端的技術解決方案，全面提升軟體交付效率，降低運維成本。簡單來說，就是除了業務解決方案和程式碼，其它事情都可以交給平臺處理。

基於這樣的理念，Pivotal打造了自己的雲原生解決方案PCF（Pivotal Cloud Foundry），包括多雲和跨雲平臺的管理、監控、釋出，以及基礎的DB、快取和訊息佇列等等，一應俱全。

我們可以看到，在PCF整體解決方案中，Spring生態是向用戶的業務應用層架構拓展的非常重要的一環，幫助其進行高效的業務開發，並提供後續的穩定性保障。

所以，這個時候，Spring Cloud除了提供微服務治理能力之外，還成為了微服務應用與雲平臺上各項基礎設施和基礎服務之間的紐帶，並在其中起到了承上啟下的關鍵作用。

至此，我們可以得出這樣一個判斷，也是本篇文章想傳遞的一個資訊：Spring Cloud不僅僅是微服務治理解決方案，它同時還是面向應用層的雲架構解決方案。

雖然Pivotal最早提出了雲原生的理念，也提供了PCF這樣的雲原生整體商業解決方案，但是從目前業界的實際應用情況來看，Spring Cloud這個區域性解決方案的應用更為廣泛。

而且從圖中我們看到，其與AWS的深度整合，也正反映出當前Spring Cloud在整個業界的影響力和被應用的廣泛程度。

插句題外話。早期阿里開源的Dubbo，其實是跟Spring Cloud類似的微服務框架，並且經過阿里大規模的應用實踐，可以說是非常優秀的開源專案。早些年國內在選擇微服務框架時，Dubbo基本是首選，但是近年來因為開源維護不力，很早停止了版本更新，導致大量的使用者流失，促使使用者紛紛湧入Spring Cloud陣營。

而Spring Cloud經過近幾年的發展，深入瞭解使用者需求和痛點，不斷完善改進，早已蛻變成我們所說的應用層的雲架構，緊跟整個雲計算髮展趨勢的大潮。

最近Dubbo重啟開源維護，與阿里雲EDAS產品體系整合，很大原因就是因為在使用者技術架構體系裡，缺少了Spring Cloud這樣的產品，再加上Dubbo原有的一些使用者基礎，重啟維護無論從哪方面看都是值得的。但是需要多久才能重拾使用者的信心，就要看Dubbo的後續表現了。

以Spring Cloud為代表的雲原生模式也是當前業界的主流模式。雖然它可能以解決應用層面的問題為主，尚未與雲平臺全面對接整合，不過它所帶動起來的雲原生的理念卻被業界越
來越廣泛地接受。

同時，隨著容器及編排技術的發展和成熟，就出現了另外一個雲原生的體系，且活躍程度非常高：它就是以Google為首的CNCF（Cloud Native Computing Foundation）。下面我們一起看一下。

CNCF設想中的雲原生分層架構示意圖

CNCF組織成立後，圈中大佬們紛紛加入，比如AWS、微軟、思科、Pivotal等等，國內的騰訊雲、阿里雲和華為也參與其中，可見其影響力有多大。

CNCF的核心專案除了K8S外，還有Goggle的gRPC，Docker的ContainerD，CoreOS的Rkt等重量級開源專案。同時也有與Spring Cloud類似，但更加通用的微服務治理框架，如Linkerd和Envoy，它們被稱為Service Mesh（服務網格）。

這些專案的優勢在於，它們是與K8S整合和配套的，可以很便捷地應用於K8S生態中。雖然K8S自身也是支援服務發現、負載均衡這些基本的微服務治理的，但是在CNCF中，它顯得更加包容與開放，不斷吸引業界最佳實踐的開源產品加入，共同打造更加開放的生態。下圖為CNCF當前的專案。

同時，因為目前K8S已實際上成為業界容器編排方面的標準，且被廣泛應用，所以各大雲廠商，無論公有云和私有云，都會主動支援K8S在雲端計算體系中的落地。

因此，我們根本不用擔心K8S與雲平臺上的資源和各種服務的對接問題，而且它最終也會將應用與雲平臺很好地連線起來，讓開發者能夠更加專注於業務開發。至於剩下的工作，則都交由平臺去做。

當前，CNCF的各個專案社群非常活躍，以至於我們一提到雲原生，就會聯想到基於CNCF和K8S的生態體系。雖然Google和CNCF都不是雲原生的提出者，但目前看來，它們都是雲原生的最佳實踐者。

可以預見的技術發展趨勢

我們可以看到，無論是Spring Cloud、CNCF、雲原生、還是K8S等等新技術或理念，究其根本，都是為了能夠更快更好地支援業務需求的快速實現。

從雲原生的理念中，我們可以看到，跟業務無直接關係且相對通用的技術在不斷地被標準化，而且標準化層面越來越高。

從最底層的硬體和網路裝置，到上層資料庫、快取、檔案儲存以及訊息佇列等等基礎元件服務，再到Spring Cloud和Service Mesh這樣的應用層面的服務管理和治理能力，都正變得越來越標準和通用。

技術每被標準化一層，原來繁瑣低效的工作就少一些，技術標準化的層面越高，技術門檻就會變得越低。我們可以作個大膽的預想：或許未來真的只會有業務解決方案和業務程式碼。

對於我們技術人來說，未來更多更迫切的能力需求將會是：如何利用好業界已有的豐富的技術產品和平臺，在面對更加豐富多樣且複雜的業務領域需求時，能夠更加專注於尋求業界解決方案，以更好地將業務和技術連線起來。找到適合業務解決方案的技術並落地實現，而不再只是專注於技術層面的造輪子。

對於運維來說，我們同樣要了解技術發展趨勢。雖然我們不會直接參與具體的業務解決方案和程式碼的開發，但是，如果架構師是業務架構的設計者，那麼我們應該成為技術架構的管理者，從效率、成本、穩定性這幾個方面來檢驗架構是否合理，併為架構朝著更加健康的方向發展保駕護航。這也是運維職能轉型和思路轉變的一個重要方向。

精選提問

1. “那麼運維應該成為技術架構的管理者，從效率、成本、穩定性這幾個方面來檢驗架構是否合理” 這句話能具體舉個例子麼因為感覺成熟的解決方案 對運維關心的 成本 效率 穩定性都包括了 比如彈性擴容故障定位 感覺以後能做的越來越少了

   專欄裡寫的持續交付，和後面的穩定性建設都是實際的案例。
   從技術實現角度，解決方案和思路都是很多成熟的東西可借鑑的，但是落地具體業務時是需要做大量適配的，包括後期的技術運營，這個工作只會越來越多。