一、什麼是微服務？
有時候，會有的人存在誤解，所謂微服務就是SpringCloud。這種思想本身是不正確的，微服務是一種系統架構上面的設計風格，而SpringCloud則是一種較爲適用於微服務架構的框架。 在java體系中，我們通常需要將一個大的類，拆分成若干個的小的類，每個類都具有自己獨立的功能。多個類之間可能會根據自己的功能進行相互間的調用，但是每一個類又是獨自存在的。
在微服務的架構體系中，我們則是將一個大服務拆分爲多個獨立的小服務，對服務進行顆粒度細分，每個服務都可以自己進行獨立部署，開發，並具有自己獨立的數據存儲等。各個服務之間互相關聯，但是同時也互相獨立，分離，使用約定好的通訊體系進行通訊。依照這樣的思想，我們不僅可以使用SpringCloud的體系進行微服務的搭建，同樣也可以使用dubbo的體系進行微服務系統的搭建。
二、微服務的優缺點
微服務本身與單服務應用相比較，是具備着可以快速針對性擴容，容災性更強，開發時衝突較少，解耦較爲完善的優點的。但是同時也有着對開發人員的技術要求水平更高，對運維人員也是一種新的挑戰。在進行小型項目開發時，如果強行使用微服務架構，則會產生一些多餘的IO開銷，並佔用更多內存，造成服務比原本的性能更低下的問題，同時也會使開發進度降低，各方面的成本會直接的被提高，並且在處理事務時，還需要使用開發效率更低，性能相比Spring事務效率低下很多倍的分佈式事務策略（事務補償，或者TCC等）。
在上方的圖片中，是一個較爲完整的微服務架構圖，在用戶進行訪問時，需要通過客戶端或者web端進行訪問，訪問後由nginx服務分發到zuul路由服務進行轉發處理，將請求轉發到指定的服務。然後門戶服務通過向eureka的註冊中心獲取需要調用的微服務，來進行實際的業務處理。 其中config服務爲配置中心，在配置中心中對配置文件進行集中化管理。分佈式事務服務爲進行分佈式事務管理的服務。 並且上圖中的所有服務實際部署時，一般均爲多個，並非一個，此處未更多的畫出。
三、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服務中拉取配置文件信息進行服務的初始化。