微服務(wù)一定要選Spring Cloud的三大原因詳細概述
前言:
現(xiàn)如今微服務(wù)架構(gòu)十分流行，而采用微服務(wù)構(gòu)建系統(tǒng)也會帶來更清晰的業(yè)務(wù)劃分和可擴展性。同時，支持微服務(wù)的技術(shù)棧也是多種多樣的，本文主要講述我們?yōu)槭裁催x擇Spring Cloud和它的技術(shù)概要。
1、為什么微服務(wù)架構(gòu)需要Spring Cloud
簡單來說，服務(wù)化的核心就是將傳統(tǒng)的一站式應(yīng)用根據(jù)業(yè)務(wù)拆分成一個一個的服務(wù)，而微服務(wù)在這個基礎(chǔ)上要更徹底地去耦合(不再共享DB、KV，去掉重量級ESB)，并且強調(diào)DevOps和快速演化。這就要求我們必須采用與一站式時代、泛SOA時代不同的技術(shù)棧，而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合體，他要求開發(fā)、測試、運維進行一體化的合作，進行更小、更頻繁、更自動化的應(yīng)用發(fā)布，以及圍繞應(yīng)用架構(gòu)來構(gòu)建基礎(chǔ)設(shè)施的架構(gòu)。這就要求應(yīng)用充分的內(nèi)聚，也方便運維和管理。這個理念與微服務(wù)理念不謀而合。
接下來我們從服務(wù)化架構(gòu)演進的角度來看看為什么Spring Cloud更適應(yīng)微服務(wù)架構(gòu)。
2、從使用nginx說起
最初的服務(wù)化解決方案是給提供相同服務(wù)提供一個統(tǒng)一的域名，然后服務(wù)調(diào)用者向這個域名發(fā)送HTTP請求，由Nginx負責(zé)請求的分發(fā)和跳轉(zhuǎn)。
這種架構(gòu)存在很多問題:
Nginx作為中間層，在配置文件中耦合了服務(wù)調(diào)用的邏輯，這削弱了微服務(wù)的完整性，也使得Nginx在一定程度上變成了一個重量級的ESB。
服務(wù)的信息分散在各個系統(tǒng)，無法統(tǒng)一管理和維護。每一次的服務(wù)調(diào)用都是一次嘗試，服務(wù)消費者并不知道有哪些實例在給他們提供服務(wù)。這不符合DevOps的理念。
無法直觀的看到服務(wù)提供者和服務(wù)消費者當(dāng)前的運行狀況和通信頻率。這也不符合DevOps的理念。
消費者的失敗重發(fā)，負載均衡等都沒有統(tǒng)一策略，這加大了開發(fā)每個服務(wù)的難度，不利于快速演化。
為了解決上面的問題，我們需要一個現(xiàn)成的中心組件對服務(wù)進行整合，將每個服務(wù)的信息匯總，包括服務(wù)的組件名稱、地址、數(shù)量等。服務(wù)的調(diào)用方在請求某項服務(wù)時首先通過中心組件獲取提供這項服務(wù)的實例的信息(IP、端口等)，再通過默認或自定義的策略選擇該服務(wù)的某一提供者直接進行訪問。所以，我們引入了Dubbo。
3、基于Dubbo實現(xiàn)微服務(wù)
Dubbo是阿里開源的一個SOA服務(wù)治理解決方案，文檔豐富，在國內(nèi)的使用度非常高。
使用Dubbo構(gòu)建的微服務(wù)，已經(jīng)可以比較好地解決上面提到的問題：
調(diào)用中間層變成了可選組件，消費者可以直接訪問服務(wù)提供者。
服務(wù)信息被集中到Registry中，形成了服務(wù)治理的中心組件。
通過Monitor監(jiān)控系統(tǒng)，可以直觀地展示服務(wù)調(diào)用的統(tǒng)計信息。
Consumer可以進行負載均衡、服務(wù)降級的選擇。
但是對于微服務(wù)架構(gòu)而言，Dubbo也并不是十全十美的：
Registry嚴重依賴第三方組件(zookeeper或者redis)，當(dāng)這些組件出現(xiàn)問題時，服務(wù)調(diào)用很快就會中斷。
Dubbo主要使用RPC調(diào)用。使得服務(wù)提供方與調(diào)用方在代碼上產(chǎn)生了強依賴，服務(wù)提供者需要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現(xiàn)問題，就會導(dǎo)致服務(wù)調(diào)用出錯。
4、最佳選擇——Spring Cloud
作為新一代的服務(wù)框架，Spring Cloud提出的口號是開發(fā)“面向云環(huán)境的應(yīng)用程序”，它為微服務(wù)架構(gòu)提供了更加全面的技術(shù)支持。
結(jié)合我們一開始提到的微服務(wù)的訴求，我們把Spring Cloud與Dubbo進行一番對比：
Spring Cloud拋棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。嚴格來說，這兩種方式各有優(yōu)劣。雖然從一定程度上來說，后者犧牲了服務(wù)調(diào)用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調(diào)快速演化的微服務(wù)環(huán)境下，顯得更加合適。
Eureka雖然后續(xù)版本不在開源，但是有很多替代的方案可供選擇，例如：Consul等。
很明顯，Spring Cloud的功能比Dubbo更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務(wù)而言是至關(guān)重要的。
前面提到，微服務(wù)背后一個重要的理念就是持續(xù)集成、快速交付，而在服務(wù)內(nèi)部使用一個統(tǒng)一的技術(shù)框架，顯然比把分散的技術(shù)組合到一起更有效率。更重要的是，相比于Dubbo，它是一個正在持續(xù)維護的、社區(qū)更加火熱的開源項目，這就保證使用它構(gòu)建的系統(tǒng)，可以持續(xù)地得到開源力量的支持。
