一、什麼是微服務？

有時候，會有的人存在誤解，所謂微服務就是SpringCloud。這種思想本身是不正確的，微服務是一種系統架構上面的設計風格，而SpringCloud則是一種較為適用於微服務架構的框架。 在java體系中，我們通常需要將一個大的類，拆分成若干個的小的類，每個類都具有自己獨立的功能。多個類之間可能會根據自己的功能進行相互間的呼叫，但是每一個類又是獨自存在的。

在微服務的架構體系中，我們則是將一個大服務拆分為多個獨立的小服務，對服務進行顆粒度細分，每個服務都可以自己進行獨立部署，開發，並具有自己獨立的資料儲存等。各個服務之間互相關聯，但是同時也互相獨立，分離，使用約定好的通訊體系進行通訊。依照這樣的思想，我們不僅可以使用SpringCloud的體系進行微服務的搭建，同樣也可以使用dubbo的體系進行SpringCloud系統的搭建。

二、微服務的優缺點

微服務本身與單服務應用相比較，是具備著可以快速針對性擴容，容災性更強，開發時衝突較少，解耦較為完善的優點的。但是同時也有著對開發人員的技術要求水平更高，對運維人員也是一種新的挑戰。在進行小型專案開發時，如果強行使用微服務架構，則會產生一些多餘的IO開銷，並佔用更多記憶體，造成服務比原本的效能更低下的問題，同時也會使開發進度降低，各方面的成本會直接的被提高，並且在處理事務時，還需要使用開發效率更低，效能相比Spring事務效率低下很多倍的分散式事務策略（事務補償，或者TCC等）。

在上方的圖片中，是一個較為完整的微服務架構圖，在使用者進行訪問時，需要通過客戶端或者web端進行訪問，訪問後由nginx服務分發到zuul路由服務進行轉發處理，將請求轉發到指定的服務。然後門戶服務通過向eureka的註冊中心獲取需要呼叫的微服務，來進行實際的業務處理。

三、SpringCloud核心元件及其用途

在進行微服務架構時，進行使用的最基礎元件為：Eureka服務治理，Ribbon負載均衡器，Feign宣告式服務呼叫，Zuul路由閘道器，config配置中心。

Eureka服務治理：

Eureka服務治理元件，分為server服務端與client客戶端兩個部分，一般會使用server單獨啟動，作為註冊中心使用，所有的服務在啟動後，都需要主動的註冊到eureka服務中。普通服務與註冊發現服務之間，採用http心跳請求的形式進行連線，判斷該服務是否還處於正常執行狀態。在服務間進行呼叫時，需要先請求eureka服務，獲取要呼叫的服務的地址列表，然後呼叫方選擇所獲取到的服務列表中的服務地址，進行呼叫。

Ribbon負載均衡器：

負載均衡器，是用於做負載均衡處理的元件，該元件會對從eureka中獲取到的服務列表中的服務進行選擇，在沒有進行配置的情況下，會預設使用隨機的形式進行服務選擇。

Feigh宣告式服務呼叫：

Feign宣告式服務呼叫元件中，會自動整合Ribbon元件，一般使用時，可以使用類似於mybatis的形式，以介面定義的形式來進行介面宣告式的提供主動呼叫。介面聲明後，不需要自己進行實現，Spring會自動進行掃描，然後實現被進行了註解的介面。在呼叫服務時，只要使用這些宣告出的介面即可。

Zuul路由閘道器：

Zuul元件，是我們常用的路由元件，該元件可以直接自成服務，擔任路由分發與閘道器過濾，日誌列印的任務（列印日誌並不建議放在該服務中，但是該服務可以承載這個功能）。該服務中會根據請求的url資訊，來將請求分發到指定的服務中。

Config配置中心：

config元件，與Eureka元件一樣，也是分為客戶端與服務端兩個部分，服務端部分，可以從一個遠端git或svn地址，或一個本地的檔案路徑下，拉取配置檔案的資訊，然後根據請求的服務名，來將不同的配置檔案提供給服務。config的服務的服務端，用於在啟動時，從config服務中拉取配置檔案資訊進行服務的初始化。