現在市面上比較熱微服務，今天花時間整理了一下SpringCloud的搭建及一些常用組件的功能及搭建流程，如有不對的地方歡大牛們的指導

一 什么是springcloud

Spring cloud是一個基于Spring Boot實現的服務治理工具包，用于微服務架構中管理和協調服務的。Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包。有了SpringCloud之后，讓微服務架構的落地變得更簡單。

二 SpringCloud的常用組件

2.1 EurekaServer

當我們的微服務過多的時候，管理服務的通信地址是一個非常麻煩的事情，Eureka就是用來管理微服務的通信地址清單的，有了Eureka之后我們通過服務的名字就能實現服務的調用。

2.2 Netflix Ribbon\Feign : 客戶端負載均衡

Ribbon和Feign都是客戶端負載均衡器，它的作用是在服務發生調用的時候幫我們將請求按照某種規則分發到多個目標服務器上，簡單理解就是用來解決微服務之間的通信問題。

2.3 Netflix Hystrix ：斷路器

微服務的調用是非常復雜的，有的時候一個請求需要很多的微服務共同完成，那么一旦某個服務發生故障，導致整個調用鏈上的微服務全都出現異常，甚至導致整個微服務架構癱瘓。Hystrix就是用來解決微服務故障，保護微服務安全的組件。
2.4 Netflix Zuul ： 服務網關

zuul作為服務網關，我們可以把它看作是微服務的大門，所有的請求都需要經過zuul之后才能到達目標服務，根據這一特性，我們可以把微服務公共的是事情交給zuul統一處理，如：用戶鑒權，請求監控等。

2.5 Spring Cloud Config ：分布式配置

微服務架構中的服務實例非常的多，服務的配置文件分散在每個服務中，每次修改服務的配置文件和重新服務實例都是一個很麻煩的工作，Spring Cloud Config作為分布式配置管理中心就是用來統一的管理服務的配置文件。

2.6 Spring Cloud Bus : 消息總線

消息總線是在微服務中給各個微服務廣播消息的一個組件，我們使用消息總線構建一個消息中心，其他微服務來接入到消息中心，當消息總線發起消息，接入的微服務都可以收到消息從而進行消費。

2.7 Spring Cloud sleuth :微服務鏈路追蹤

當我們的應用采用微服務架構之后，后臺可能有幾十個甚至幾百個服務在支撐，一個請求請求可能需要多次的服務調用最后才能完成，鏈路追蹤的作用就是來監控維護之間的調用關系,讓程序員方便直觀的感受到一個請求經歷了哪些微服務，以及服務的請求時間，是否有異常等。

三 SpringCloud的版本

SpringCloud是基于SpringBoot的,所以兩者的jar包缺一不可,但是要注意的是SprinbCloud的版本需要和SpringBoot的版本兼容.下面是版本兼容圖：

四 服務通信協議

在微服務當中使用網絡通信協議有兩種選擇，如下：

4.1 .RPC

RPC(Remote Produce Call)遠程過程調用，類似的還有RMI。自定義數據格式，基于原生TCP通信，速度快，效率高。早期的webservice，現在熱門的dubbo，都是RPC的典型

4.2 Http

Http其實是一種網絡傳輸協議，基于TCP，規定了數據傳輸的格式。現在客戶端瀏覽器與服務端通信基本都是采用Http協議。也可以用來進行遠程服務調用。缺點是消息封裝臃腫。 現在熱門的Rest風格，就可以通過http協議來實現

4.3 如何選擇

其實我們并不需要刻意去選擇該使用RPC或者是Http，如果架構師選擇Dubbo作為微服務開發框架，通信方式自然就是RPC，當架構師選擇了SpringCloud作為微服務開發框架，那么通信方式自然就是基于Http協議，當然，如果服務的通信方式成為了微服務的性能瓶頸，那么架構師自然需要去考慮更換微服務的通信協議。

五 Dubbo 與 SpringCloud

.Dubbo簡介
Dubbo最早是有阿里巴巴提供的一個服務治理和服務調用框架，現在已經成為Apache的頂級項目，Dubbo跟SpringCloud最顯著的區別是Dubbo的定位只是一個RPC框架，相比SpringCloud來說它缺少很多功能模塊，如：網關，鏈路追蹤等，所以往往在使用Dubbo作為微服務開發框架的時候，還需要去配合其他的框架一起使用，如:加入zookeeper作為注冊中心。

SpringCloud與Dubbo的區別*

早期在國內做分布式(微服務)應用Dubbo是比較熱門的框架，被許多互聯網公司所采用，并產生了許多衍生版本，如網易，京東，新浪，當當等等，奈何在2014年10月Dubbo停止維護，在Dubbo停更的時間里Spring Cloud快速追趕上。在2017年9月，阿里宣布重啟Dubbo項目，計劃對Dubbo進行持續更新維護。2018.2月，阿里將Dubbo捐獻給Apache基金會，Dubbo成為Apache孵化器項目。

所以當前微服務架構，Dubbo和SpringCloud比較火，另外還有Thrift、gRPC等等 。很多人把SpringCloud 和Dubbo進行對比，其實兩個框架并沒有太大的可比性，因為他們的定位不同。Spring Cloud是一個完整的微服務解決方案,它提供了微服務各問題的解決方案集合，而Dubbo是一個高性能的RPC框架，它有著很多功能的缺失。

定位不一樣

SpringCloud為了微服務的落地提供了一套完整的組件，而Dubbo只是一個RPC框架，缺失的功能很多。

通信協議不一樣

Dubbo的通信方式是RPC，基于原聲的tcp,性能較好，而SpringCloud的通信方式基于Http協議，雖然底層基于tcp，但是Http的封裝過于臃腫，但是使用Http好處在于互相通信的兩個服務可以使用不同的變成語言去編寫，只要他們都支持Http通信即可互相調用，而Dubbo只支持Java,當然Dubbo交給Apache維護之后做了升級，Dubbo在以后不僅僅支持Java。

背景都很強大

Dubbo背靠阿里和Apache,淘寶就是使用的Dubbo來開發經理過雙“11”期間的高并發大流量檢驗，可以說是非常的穩定和成熟，SpringCloud是Spring家族的成員，嚴格遵循Martin Fowler提出的微服務規范，可以認為SpringCloud是微服務架構的標準，總之兩者背景都很強大，文檔完善，社區活躍，所以不管作何選擇，都是很有前途的。

開發風格

從開發風格上來講，Dubbo官方推薦傾向于使用Spring xml配置方式，SpringCloud是基于SpringBoot的開發風格，即采用注解的方式進行配置，從開發速度上來說，SpringCloud具有更高的開發和部署速度。

下面是網上比較流行的Dubbo和Spring Cloud功能對比圖：