目前大家都在說微服務，其實微服務不是一個名字，是一個架構的概念，大家現在使用的基於RPC框架（dubbo、thrift等）架構其實也能算作一種微服務架構。
目前越來越多的公司開始使用微服務架構，所以在目前招聘java崗位時，有springcloud經驗還是會占一點優勢，今天young就和大家一起來學習Spring Cloud微服務框架。
本章，我們先解決新人都頭疼的一個問題，spring Cloud 與spring Boot到底是什么關系？？？？
一 、什么是spring Boot
在講解什么是spring Boot之前，我們先可以思考一下，目前使用spring時，有沒有感覺以下的兩個問題經常被頻繁的吐槽
1. 在過去的 Spring 發中，需要引入大量的 xml 文件。Spring 2.5 引入了包掃描，消除了顯式的配置 Bean。 Spring 3.0 又引入了基於 JavaBean 的配置，這種方式可以取代 xml 文件。
盡管如此，在實際的開發中還是需要配置 xml 文件，例如配 SpringMVC 事務管理器、過濾器、切面等等。
2. 在項目的開發過程中，會引入大量的第三方依賴，選擇依賴是一件不容易的事，解決依賴與依賴之間的沖突也很耗費精力。所以，在以前的Spring開發中，依賴管理也是一件棘手的事情。
結合上面Spring的兩點瑕疵，我們在來總結一下，什么是SpringBoot：
1. Spring Boot並不是一個全新的框架，它不是spring解決方案的一個替代品，而是spring的一個封裝。所以，你以前可以用spring做的事情，現在用spring Boot都可以做。
2. Spring Boot是一種全新的編程規范，是一個服務於框架的框架，服務范圍是簡化配置文件和起步依賴，他的產生簡化了框架的使用，所謂簡化是指簡化了Spring眾多框架中所需的大量且繁瑣的配置文件。
二 、什么是spring Cloud
1. Spring Cloud是一個微服務框架，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系統解決方案，它依賴於 Spring Boot ，有快速開發、持續交付和容易部署等特點。
2. Spring Cloud不像其他Spring子項目那樣相對獨立，它是一個擁有諸多子項目的大型綜合項目。
三 、Spring Cloud與Spring Boot的對比
1. Spring Boot 是 Spring的一套快速配置腳手架，可以基於Spring Boot 快速開發單個微服務；Spring Cloud是一個基於Spring Boot實現的雲應用開發工具；
2. Spring Boot專注於快速、方便集成的單個個體；Spring Cloud是關注全局的服務治理框架；
3. Spring Boot使用了默認大於配置的理念，很多集成方案已經幫你選擇好了，能不配置就不配置；Spring Cloud很大的一部分是基於Spring Boot來實現。
4. Spring Boot可以離開Spring Cloud獨立使用開發項目，但是SpringCloud離不開Spring Boot，屬於依賴的關系。
四、Spring Cloud的常用組件
Spring Cloud 提供了開發分布式微服務系統的一些常用組件，例如服務注冊和發現、配置中心、熔斷器、 智能路由 、微代理、控制總線、全局鎖、分布式會話等。
spring Cloud的子項目很多，但是目前在實際工作中，我們一般業務項目使用到的組件就是常規的幾個，其它的一般開發用不到，做為新手，我們先熟悉常用且重要的幾個。
接下來的這8個常用組件的描述來自（方志朋的《深入理解Spring Cloud 與微服務構建一書》）
（1）服務注冊和發現組件 Eureka
利用 Eureka 組件可以很輕松地實現服務的注冊和發現功能。 Eureka 組件提供了服務的健康監測，以及界面友好的 UI 。通過 Eureka 組件提供的 UI, Eureka 組件可以讓開發人員隨時了解服務單元的運行情況。
另外 Spring Cloud 也支持 Consul 和Zookeepe ，用於注冊和發現服務。
（2）熔斷組件 Hystrix
Hystrix是一個 熔斷組件，它除了有一些基本的熔斷器功能外，還能夠實現服務降級、服務限流的功能。另外 Hystrix 提供了熔斷器的健康監測，以及熔斷器健康數據的 API 口。
Hystrix Dashboard 組件提供了單個服務熔斷器的健康狀態數據的界面展示功能，Hystrix Turbine 組件提供了多個服務的熔斷器的健康狀態數據的界面展示功能。
（3）負載均衡組件 Ribbon
Ribbon 是一個負載均衡組件，它通常和 Eureka 、Zuul、 RestTemplate、Feign 配合使用。Ribbon 和Zuul 配合，很容易做到負載均衡，將請求根據負載均衡策略分配到不同的服務實例中。
Ribbon和RestTemplate、Feign配合，在消費服務時能夠做到負載均衡。
（4）路由網關 Zuul
路由網關 Zuul 有智能路由和過濾的功能。內部服務的 API 接口通過 Zuul 網關統一對外暴露，內部服務的 API 接口不直接暴露，防止了內部服務敏感信息對外暴露。在默認的情況下，Zuul和Ribbon相結合，能夠做到負載均衡、智能路由。
Zuul過濾功能是通過攔截請求來實現的，可以對一些用戶的角色和權限進行判斷，起到安全驗證的作用，同時也可以用於輸出實時的請求曰志。
上述的4個組件都來自於 Netflix 的公司，稱為 Spring Cloud Netflix。
（5）Spring Cloud Config
Spring Cloud Config 組件提供了配置文件統一管理的功能。Spring Cloud Config包括Server端和Client端，Server 端讀取本地倉庫或者遠程倉庫的配置文件，所有的Client 向Server讀取配置信息，從而達到配置文件統一管理的目的。
通常情況下， Spring Cloud Config 和 Spring Cloud Bus 相互配合刷新指定 Client 或所有Client的配置文件。
(6) Spring Cloud Security
Spring Cloud Security 是對 Spring Security 組件的封裝，Spring Cloud Security 向服務單元提供了用戶驗證和權限認證。一般來說，單獨在微服務系統中使用 Spring Cloud Security 是很少見的，一般它會配合 Spring Security 0Auth2 組件一起使用， 通過搭建授權服務，驗證 Token或者 JWT 這種形式對整個微服務系統進行安全驗證。
（7）Spring Cloud Sleuth
Spring Cloud Sleuth 是一個分布式鏈路追蹤組件，它封裝了 Dapper Zipkin 和 Kibana 等組件，通過它可以知道服務之間的相互依賴關系，並實時觀察鏈路的調用情況。
（8）Spring Cloud Stream
Spring Cloud Stream Spring Cloud 框架的數據流操作包，可以封裝 RabbitMq 、ActiveMq 、Kafka 、Redis 等消息組件，利用 Spring Cloud Stream 可以實現消息的接收和發送。
五、微服務相比單體服務的優缺點
關於微服務的優缺點，我不想用官網模板或者書上說的一大堆，young我經歷了從單體服務到微服務項目的過渡，我就從個人工作體會接地氣的講解一下微服務的優缺點。
優點：
1. 新人上手快：新人在參與新項目時，只需要下載需求相關模塊的代碼，了解這部分代碼就行了，不需要關注整個項目的代碼邏輯，可以減少上手時間。
2. 本地調試快：以前修改一個功能，整個項目啟動，花費時間很長。現在只啟動修改的單個模塊，啟動很快。（不知道有沒有和我一樣，以前本地啟動一個復雜項目花費30s-60s，調試啟動一次就能喝杯茶了）。
3. 開發進度加快：以前一個項目，多個人開發，你改的代碼，影響我，我改的代碼影響你，某個人改了錯誤代碼提交，整個項目都啟動不了。微服務不同功能模塊，互不影響，你自己的鍋自己背。
4. 跨語言合作： 同一個項目不同的功能模塊可以使用不同語言開發，java，js，php，隨心所欲。不同語言只需要提供 http 客戶端，便可以實現跨語言調用。
5. 簡單的分庫： 同一個項目，不同模塊連接不同的數據庫，主要是配置簡單。（我們項目就連接3個不同的mysql業務數據庫，1個redis集群，1個mongo集群）。
6. 服務集群擴展容易 ：現在springcloud做服務集群，節省資源，並且搭建速度快。比如項目中，資源服務功能模塊壓力大，運維只要快速copy一份配置，部署一台資源服務模塊的服務就行了，其它功能服務模塊不用管。
缺點：
1. 運維人員壓力大： 單體應用以前運維同事只要監控個一個應用正常運行，而現在卻需要保證幾十甚至上百個應用運轉正常，這是一個艱巨的任務。
2. 事務、異步、測試面臨挑戰：跨進程之間的事務、大量的異步處理、多個微服務之間的整體測試都需要有一整套的解決方案，而現在看起來，這些技術並沒有成熟。
3. 服務分割難度大：對於一個項目，如何進行功能划分，哪些功能歸屬同一個服務模塊，對架構師和設計人員的要求較高。
后面，我會以實際工作中的案例，逐步講解springcloud重要組件的使用，逐漸搭建出一個微服務項目，敬請期待~
如果不正確的地方，歡迎大家留言指出，共同進步~