深刻理解Spring Cloud與微服務構建【一】 - 1.2微服務

1.2.1 什麼是微服務

• 按業務劃分爲一個獨立運行的程序，即服務單元。
• 服務之間經過 HTTP 協議相互通訊。
• 自動化部署。
• 能夠用不一樣的編程語言。
• 能夠用不一樣的存儲技術。
• 服務集中化管理。

微服務是一個分佈式系統。 根據這些特色，下面來進一步闡述微服務。

1. 微服務單元按業務來劃分
   微服務的「微」到底須要定義到什麼樣的程度，這是一個很是難以界定的概念，能夠從以 下 3 個方面來界定：
   一是根據代碼量來定義，根據代碼的多少來判斷程序的大小：
   二是根據開 發時間的長短來判斷：
   三是根據業務的大小來劃分。
2. 微服務經過 HTTP 來互相通訊
   按照業務劃分的微服務單元獨立部署， 並運行在各自的進程中。微服務單元之間的通訊方 式通常傾向於使用 HTTP 這種簡單的通訊機制，更多的時候是使用RESTful API的。這種接受 請求、處理業務邏輯、返回數據的 HTTP 模式很是高效，而且這種通訊機制與平臺和語言無關。 例如用 Java 寫的服務能夠消費用 Go 語言寫的服務，用 Go寫的服務又能夠消費用 Ruby 寫的服務。 不一樣的服務採用不一樣的語言去實現，不一樣的平臺去部署，它們之間 使用 HTTP 進行通信。
   
   服務與服務之間也能夠經過輕量級的消息總線來通 信，例如 RabbitMQ、 Kafaka 等。經過發送消息或者訂閱 消息來達到服務與服務之間通訊的目的。
   服務與服務通訊的數據格式， 通常爲 JSON、 XML, 這兩種數據格式與語言、平臺、通訊協議無關。通常來 說， JSON 格式的數據比 XML 輕量，井且可讀性也比 X1在L 要好。另一種就是用 Protobuf進行數據序列化，通過序列化的數據爲二進制數據，它比 JSON 更輕量。 用 Protobuf序列化的數據爲二進制數據，可讀性很是差， 須要反序列化纔可以讀懂。因爲用 Protobuf序列化的數據更爲輕量，因此 Protobuf在通訊協議 和數據存儲上十分受歡迎。
   服務與服務之間經過 HTTP 或者消息總線的方式進行通訊，這種方式存在弊端，其通訊機 制是不可靠的，雖然成功率很高，但仍是會有失敗的時候。
3. 微服務的數據庫獨立
   在單體架構中，全部的業務都共用一個數據庫。隨着業務量的增長，數據庫的表的數量越 來越多，難以管理和維護，而且數據量的增長會致使查詢速度愈來愈慢。例如， 一個應用有這 樣幾個業務：用戶的信息、用戶的帳戶、用戶的購物車、數據報表服務等。
   
   微服務的一個特色就是按業務劃分服務，服務與服務之間無稠合，就連數據庫也是獨立的。 一個典型的微服務的架構就是每一個微服務都有本身獨立的數據庫，數據庫之間沒有任何聯繫。 這樣作的好處在於，隨着業務的不斷擴張，服務與服務不須要提供數據庫集成，而是提供 API 接口相互調用：還有一個好處是數據庫獨立，單業務的數據盆少，易於維護，數據庫性能有着 明顯的優點，數據庫的遷移也很方便。
   
4. 微服務的自動化部署
   在微服務架構中，系統會被拆分爲若干個微服務， 每一個微服務又是一個獨立的應用程序。 單體架構的應用程序只須要部署一次，而微服務架構有多少個服務就須要部署多少次。隨着服 務數量的增長，若是微服務按照單體架構的部署方式，部署的難度會呈指數增長。業務的粒度 劃分得越細，微服務的數量就越多，這時須要更穩定的部署機制。隨着技術的發展，尤爲是 Docker 容器技術的推動，以及自動化部署工具（例如開源組件 Jenkins）的出現，自動化部署 變得愈來愈簡單。
5. 服務集中化管理
   微服務系統是按業務單元來劃分服務的，服務數量越多， 管理起來就越複雜，所以微服務 必須使用集中化管理。目前流行的微服務框架中，例如 Spring Cloud 採用 Eureka 來註冊服務 和發現服務，另外， Zookeeper、 Consul 等都是很是優秀的服務集中化管理框架。
6. 分佈式架構
   分佈式系統是集羣部署的，由不少計算機相互協做共同構成，它可以處理海量的用戶請求。
   微服務架構是分佈式架構， 分佈式系統比單體系統更加複雜，主要體如今服務的獨立性和服 務相互調用的可靠性，以及分佈式事務、全局鎖、 全局 Id 等， 而單體系統不須要考慮這些複雜性。
   分佈式系統的應用都是集羣化部署， 會給數據一致性帶來困難。
   分佈式系統中的服 務通訊依賴於網絡， 網絡很差，必然會對分佈式系統帶來很大的影響。
   在分佈式系統中，服務 之間相互依賴，若是一個服務出現了故障或者是網絡延遲，在高併發的狀況下，會致使線程阻 塞，在很短的時間內該服務的線程資源會消耗殆盡，最終使得該服務不可用 。因爲服務的相互 依賴，可能會致使整個系統的不可用，這就是「雪崩效應」。爲了防止此類事件的發生，分佈式 系統必然要採起相應的措施，例如「熔斷機制」。
7. 熔斷機制
   爲了防止「雪崩效應」事件的發生，分佈 式系統採用了熔斷機制。在用 Spring Cloud 構 建的微服務系統中，採用了熔斷器（即 Hystrix 組件的 Circuit Breaker）去作熔斷。 例如在微服務系統中，有 a、 b、 c、 d、 e、 f、 g、 h 等多個服務，用戶的請求經過網關後， 再到具體的服務，服務之間相互依賴，例如服 務 b 依賴於服務 f， 一個對外暴露的 API 接口 須要服務 b 和服務 f相互協做才能完成。
   
   若是此時服務 b 出現故障或者網絡延遲， 在高併發的狀況下，服務 b 會出現大量的線程阻塞，有可能在很短的時間內線程資源就被消耗完了，致使服務 b 的不可用。若是服務 b 爲較底層的服務，會影響到其餘服務，致使其餘服務會一直等待服務 b 的處理。 若是服務 b 遲遲不 處理，大量的網絡請求不只僅堆積在服務 b，並且會堆積到依賴於服務 b 的其餘服務。而因服 務 b 出現故障影響的服務，也會影響到依賴於因服務 b 出現故障影響的服務的其餘服務，從而 由 b 開始，影響到整個系統，致使整個系統的不可用。這是一件很是可怕的事，由於服務器運 營商的不可靠，必然會致使服務的不可靠，而網絡服務商的不可靠性，也會致使服務的不可靠。 在高併發的場景下，稍微有點不可靠，因爲故障的傳播性，會致使大量的服務不可用，甚至導 致整個系統崩潰。
   爲了解決這一難題，微服務架構引入了熔斷機制。當服務 b 出現故障，請求失敗次數超過 設定的閥值以後，服務 b 就會開啓熔斷器，以後服務 b 不進行任何的業務邏輯操做，執行快速 失敗，直接返回請求失敗的信息。其餘依賴於 b 的服務就不會由於得不到響應而線程阻塞，這時除了服務 b 和依賴於服務 b 的部分功能不可用外， 其餘功能正常。
   

熔斷器還有另一個機制，自我修復的 機制。當服務 b 熔斷後，通過一段時間，半打 開熔斷器。半打開的熔斷器會檢查一部分請求 是否正常，其餘請求執行快邊失敗，檢查的請求若是響應成功，則能夠斷定服務 b 正常了， 就會關閉服務 b 的熔斷器；若是服務 b 還不正 常，則繼續打開熔斷器。 這種自我熔斷機制和 自我修復機制在微服務架構中有精重要的意義， 一方面，它使程序更加健壯，另外一方面， 爲開發和運維減小不少沒必要要的工做。
熔斷組件每每會提供一系列的監控，例如服務可用與否、熔斷器是否被打開、目前 的吞吐量、網絡延遲狀態的監控等，從而很容易讓開發人員和運維人員實時地瞭解服務的情況。

1.2.2 微服務的優點

1.將一個複雜的業務分解成若干小的業務，每一個業務拆分紅一個服務，服務的邊界明 確，將複雜的問題簡單化。服務按照業務拆分， 編碼也是按照業務來拆分，代碼的可讀性和可 擴展性增長。新人加入團隊，不須要了解全部的業務代碼，只須要了解他所接管的服務的代碼，新人學習時間成本減小。

2.因爲微服務系統是分佈式系統，服務與服務之間沒有任何的禍合。 隨着業務的增長， 能夠根據業務再拆分服務， 具備極強的橫向擴展能力。隨着應用的用戶量的增長，井髮量增長， 能夠將微服務集羣化部署，從而增長系統的負載能力。簡而言之，微服務系統的微服務單元具 有很強的橫向擴展能力。

3.服務與服務之問經過 HTTP 網絡通訊協議來通訊，單個微服務內部高度禍合，服務與 服務之間徹底獨立，無調合。這使得微服務能夠採用任何的開發語言和技術來實現。開發人員 再也不被強迫使用公司之前的技術或者已通過時的技術，而是能夠 自由選擇最適合業務場景的或 者最適合本身的開發語言和技術，提升開發效率、下降開發成本。

4.若是是一個單體的應用，因爲業務的複雜性、代碼的禍合性，以及可能存在的歷史問 題。在重寫一個單體應用時，要求重寫的應用的人員瞭解全部的業務，因此重寫單體應用是非 常困難的，而且重寫風險也較高。若是是微服務系統，因爲微服務系統是按照業務的進行拆分 的，而且有堅實的服務邊界，因此重寫某個服務就至關於重寫某一個業務的代碼，很是簡單。

5.微服務的每一個服務單元都是獨立部署的，即獨立運行在某個進程裏。微服務的修改和 部署對其餘服務沒有影響。試想，假設一個應用只有一個簡單的修改，若是是單體架構，須要 測試和部署整個應用；而若是採用微服務架構，只須要測試並部署被修改的那個服務，這就大 大減小了測試和部署的時間。

6.微服務在 CAP 理論中採用的是 AP 架構，即具備高可用和分區容錯的特色。高可用 主要體如今系統 7 x 24 小時不間斷的服務，它要求系統有大量的服務器集羣，從而提升了系 統的負載能力。另外，分區容錯也使得系統更加健壯。