SpringCloud(一)微服務概念

一、單體架構的問題

微服務為什么會出現？在學習Springboot的時候知道Springboot極大的簡化了我們的開發，我們可以快速的進行業務開發，Springboot單體應用在項目的開發初期能夠滿足我們需求，這種單體架構優點非常的明顯：

1. 容易測試：本地就可以起完整的系統，不需要外部依賴。

2. 容易開發：我們只需引入依賴，選擇框架便可快速開發。

3. 易於部署：單體架構部署也較簡單，直接打包即可。

4. 易於水平伸縮：這里的收縮時指當我們需要多個服務器時也比較方便

在項目剛開始的時候我們可以快速的開發，一個長壽的項目，需求不斷增加，原先的模塊也再不斷優化，這個時候單體架構的缺點開始顯現：

1. 代碼膨脹，難以維護：代碼越來越多，開發人員也就越來越多，一旦出現bug，定位、修復成本很高，而且人員太多，代碼都放在一起，容易引起沖突，且由於業務集中在一起，業務復雜，很難全局把握，改一個bug可能會再多出兩個bug。

2. 構建、部署成本大：項目太大，構建和部署就會非常慢，效率低下。

3. 上手困難：互聯網企業人員更迭快，代碼過於集中，導致業務非常復雜，新人想要上手變得非常困難。

4. 技術創新困難：代碼過於集中，我們很難使用到新技術，因為改動實在太大，容易出現問題。

5. 可擴展性差：這里的可擴展性是指因為項目都必須部署在一台服務器中，那項目所要的資源會越來越大，這樣我們只能擴展硬件（集群可以分散壓力，但是單個應用所要的資源還是不能少的）。

二、微服務出現

微服務的出現就是為了解決這些問題，看看是如何解決的，微服務將系統拆分成一個個小服務（一般是按照模塊進行拆分，比如用戶服務、支付服務、訂單服務、出入庫服務等），那么即使業務量增加，我們也可以通過新增服務的形式來解決，這樣代碼就不會膨脹，構建、部署也不是問題。由於服務不在一個框架中，那么我們可以很方便的對某一個服務進行技術創新，對一個服務的進行技術升級改動不會太大，而當我們有新技術產生時，我們就可以也可以應用到新服務中。

微服務並沒有明確的定義，下面是一種比較通用的理解：

使用一套小服務來開發單個應用的方式，每個服務運行在獨立的進程里，一般采用輕量級的通訊機制互聯，並且它們可以通過自動化方式部署。

通過定義我們可以知道微服務的特征：

• 微服務是由一系列的小服務共同組成的。

• 每個微服務都有自己獨立的進程。

• 每個服務都是獨立的業務開發，單一原則

• 每個服務都能獨立的部署（一般部署在容器中）。

• 微服務之間通過輕量級通信機制進行通信

• 分布式的管理。

三、微服務架構圖

講到這里，對微服務的概念應該有了一定的了解，下面畫的一個比較簡單的微服務架構圖

 

圖中可以看出每個微服務都有自己獨立的數據庫，每個服務都會暴露自己的REST API 給外部調用，服務之間會存在互相調用關系，而每個服務都有可能被客戶端直接調用，另外我們看到還有一個API Gateway,這是統一個服務接口，它通常可以有以下作用：

 1. 提供統一服務入口，讓微服務對前台透明

 2. 聚合后台的服務，節省流量，提升性能

 3. 提供安全，過濾，流控等API管理功能

四、優缺點

凡是都有兩面性，一個技術也不可能只有優點而沒有缺點，微服務的優點很多，微服務的優點其實就是單體架構的缺點的反面，因為微服務本身就是來解決單體架構問題的

1. 獨立性：微服務從構建、部署，擴容、縮容、甚至數據庫都是獨立的，服務只要管理好自己就可以，這樣就極大的降低了系統的復雜性。服務完全獨立獨立之后，從構建到部署，到后期的擴容縮容都會變得簡單，基本就解決單體架構上碰到的很多問題。

2. 敏捷性：敏捷性是針對開發人員來講的，服務拆分之后，可以獨立專一開發，開發人員可以通過API快速的了解本服務的業務，互相之間並不影響。

3. 技術棧靈活：微服務可以完全獨立的擁有技術棧，只需要保證提供的服務API不變，內部使用何種技術棧很靈活。

4. 高效的團隊：微服務的團隊會比較小，那溝通就會變得更加高效。

沒有最好的架構，只有最適合的架構，既然有這么多優點，那缺點肯定也有不少

1. 服務的拆分：服務如何拆分其實是非常重要且復雜的，服務拆分的太大或太小都不合適，這需要我們有非常豐富的經驗，而這個在單體中是不存在的。

2. 數據一致性：單體架構中只有一個數據庫，我們可以通過事務解決多表之間數據的一致性，而在微服務中，每個服務中都有自己獨立的數據庫，要保證服務之間的數據一致性也是一個大的挑戰。

3. 服務間通信成本：服務間互相通信也需要時間成本。

4. 測試復雜性提高：服務之間存在依賴，那么測試時就必須啟動這些依賴，這就增加了復雜度。

5. 運維部署復雜性提高：微服務應用由大量服務組成，每個服務會起多個實例，要進行配置，部署，擴展和監控。此外，還需要實現服務發現機制

五、技術點

要實現微服務，我們需要解決以下幾個技術點：

• 客戶端訪問服務：這個上面架構圖中已經給出，使用API Gateway。

• 服務通信：服務與服務之間的通信有兩種方式，同步與異步：

  同步通信中又分為兩種：Http與RPC，http訪問很好理解，相信一般的系統也會調用外部的一些服務，這些基本都是使用http,因為http可以跨語言，跨客戶端，相對使用較廣，如http Client ,而RPC也有自己的優點，首先是效率更高，更安全可控，特別是內部服務互相調用時，用統一的RPC框架，服務的侵入性更低，調用服務甚至就像調用自己的服務一樣簡單,如dubbo（注：dubbo只能使用java語言）。

  異步通信是通過消息隊列來實現，異步通信的好處是可以降低服務之間的耦合，有削峰的好處，而且使用消息隊列可以方便的實現數據的最終一致性。

• 服務治理：為了服務的高可用，微服務一般都有多個拷貝，做負載均衡，而這個時候就必須知道服務的狀態，一個服務隨時有可能下線，下線之后后續有可能重新啟動，這些都需要我們一個服務治理功能，也即是服務的注冊與發現。

      

 

        產品服務啟動了三個，他們都會去注冊中心進行注冊，注冊成功后，會通過心跳包告訴注冊中心是否在線或者下線，而訂單服務要去調用產品服務，會先去注冊中心進行查詢，查詢出相應的地址然后再去調用產品服務。

• 服務崩潰處理：在運行期間會出現服務崩潰的情況，比如網絡原因，阻塞原因，這個時候服務並不是下線，還是能夠被找到，我們必須妥善要進行處理，否則可能會導致整個系統的崩潰，處理的方式有：

  1. 重試機制

  2. 熔斷機制

  3. 降級機制

  4. 限流機制

六、解決方案

以上都是微服務的一些概念，既然有天上飛的概念，就有落地的實現，現在主流的微服務架構有兩套解決方案：Dubbo+Zookeeper與SpringCloud。

我司現在兩種方案都在用，總體來說兩種方案都可以很方便的進行微服務開發，其中的區別在於SpringCloud組件多，功能完備，全家桶式，基本微服務中會遇到的問題都有相應的解決方案，在通信方面SpringCloud使用的是http。

而Dubbo+Zookeeper使用的是RPC，組件較少，功能非完備（但是我們可以自己去找相應的解決方案），並且現在交由Apache進行孵化，后面應該會實現功能的完備。

RPC 也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個的開發規范和統一的服務框架時，他的開發效率優勢更明顯些。

當我們的服務時一個對內服務時，我們可以使用Dubbo+Zookeeper，比如一些公用的服務，這些一般是提供給內部