一塊兒來學spring Cloud | 序言 ：spring Cloud 與Spring Boot

目前你們都在說微服務，其實微服務不是一個名字，是一個架構的概念，你們如今使用的基於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，屬於依賴的關係。

 

4、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 能夠實現消息的接收和發送。

 

5、微服務相比單體服務的優缺點

關於微服務的優缺點，我不想用官網模板或者書上說的一大堆，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重要組件的使用，逐漸搭建出一個微服務項目，敬請期待~

    若是不正確的地方，歡迎你們留言指出，共同進步~