摘要：熔斷機制為了防止雪崩效應事件的發(fā)生，分布式系統(tǒng)采用了熔斷機制。為了解決這一難題，微服務架構引入了熔斷機制。由于微服務系統(tǒng)是分布式系統(tǒng)，服務與服務之間沒有任何的禍合。

按業(yè)務劃分為一個獨立運行的程序，即服務單元。

服務之間通過 HTTP 協(xié)議相互通信。

自動化部署。

可以用不同的編程語言。

可以用不同的存儲技術。

服務集中化管理。

微服務是一個分布式系統(tǒng)。 根據(jù)這些特點，下面來進一步闡述微服務。

微服務單元按業(yè)務來劃分
微服務的“微”到底需要定義到什么樣的程度，這是一個非常難以界定的概念，可以從以 下 3 個方面來界定：
一是根據(jù)代碼量來定義，根據(jù)代碼的多少來判斷程序的大?。?
二是根據(jù)開 發(fā)時間的長短來判斷：
三是根據(jù)業(yè)務的大小來劃分。

微服務通過 HTTP 來互相通信
按照業(yè)務劃分的微服務單元獨立部署， 并運行在各自的進程中。微服務單元之間的通信方 式一般傾向于使用 HTTP 這種簡單的通信機制，更多的時候是使用RESTful API的。這種接受 請求、處理業(yè)務邏輯、返回數(shù)據(jù)的 HTTP 模式非常高效，并且這種通信機制與平臺和語言無關。 例如用 Java 寫的服務可以消費用 Go 語言寫的服務，用 Go寫的服務又可以消費用 Ruby 寫的服務。 不同的服務采用不同的語言去實現(xiàn)，不同的平臺去部署，它們之間 使用 HTTP 進行通訊。

服務與服務之間也可以通過輕量級的消息總線來通 信，例如 RabbitMQ、 Kafaka 等。通過發(fā)送消息或者訂閱 消息來達到服務與服務之間通信的目的。
服務與服務通信的數(shù)據(jù)格式， 一般為 JSON、 XML, 這兩種數(shù)據(jù)格式與語言、平臺、通信協(xié)議無關。一般來 說， JSON 格式的數(shù)據(jù)比 XML 輕量，井且可讀性也比 X1在L 要好。另外一種就是用 Protobuf進行數(shù)據(jù)序列化，經(jīng)過序列化的數(shù)據(jù)為二進制數(shù)據(jù)，它比 JSON 更輕量。 用 Protobuf序列化的數(shù)據(jù)為二進制數(shù)據(jù)，可讀性非常差， 需要反序列化才能夠讀懂。由于用 Protobuf序列化的數(shù)據(jù)更為輕量，所以 Protobuf在通信協(xié)議 和數(shù)據(jù)存儲上十分受歡迎。
服務與服務之間通過 HTTP 或者消息總線的方式進行通信，這種方式存在弊端，其通信機 制是不可靠的，雖然成功率很高，但還是會有失敗的時候。

微服務的數(shù)據(jù)庫獨立
在單體架構中，所有的業(yè)務都共用一個數(shù)據(jù)庫。隨著業(yè)務量的增加，數(shù)據(jù)庫的表的數(shù)量越 來越多，難以管理和維護，并且數(shù)據(jù)量的增加會導致查詢速度越來越慢。例如， 一個應用有這 樣幾個業(yè)務：用戶的信息、用戶的賬戶、用戶的購物車、數(shù)據(jù)報表服務等。

微服務的一個特點就是按業(yè)務劃分服務，服務與服務之間無稠合，就連數(shù)據(jù)庫也是獨立的。 一個典型的微服務的架構就是每個微服務都有自己獨立的數(shù)據(jù)庫，數(shù)據(jù)庫之間沒有任何聯(lián)系。 這樣做的好處在于，隨著業(yè)務的不斷擴張，服務與服務不需要提供數(shù)據(jù)庫集成，而是提供 API 接口相互調(diào)用：還有一個好處是數(shù)據(jù)庫獨立，單業(yè)務的數(shù)據(jù)盆少，易于維護，數(shù)據(jù)庫性能有著 明顯的優(yōu)勢，數(shù)據(jù)庫的遷移也很方便。

微服務的自動化部署
在微服務架構中，系統(tǒng)會被拆分為若干個微服務， 每個微服務又是一個獨立的應用程序。 單體架構的應用程序只需要部署一次，而微服務架構有多少個服務就需要部署多少次。隨著服 務數(shù)量的增加，如果微服務按照單體架構的部署方式，部署的難度會呈指數(shù)增加。業(yè)務的粒度 劃分得越細，微服務的數(shù)量就越多，這時需要更穩(wěn)定的部署機制。隨著技術的發(fā)展，尤其是 Docker 容器技術的推進，以及自動化部署工具（例如開源組件 Jenkins）的出現(xiàn)，自動化部署 變得越來越簡單。

服務集中化管理
微服務系統(tǒng)是按業(yè)務單元來劃分服務的，服務數(shù)量越多， 管理起來就越復雜，因此微服務 必須使用集中化管理。目前流行的微服務框架中，例如 Spring Cloud 采用 Eureka 來注冊服務 和發(fā)現(xiàn)服務，另外， Zookeeper、 Consul 等都是非常優(yōu)秀的服務集中化管理框架。

分布式架構
分布式系統(tǒng)是集群部署的，由很多計算機相互協(xié)作共同構成，它能夠處理海量的用戶請求。
微服務架構是分布式架構， 分布式系統(tǒng)比單體系統(tǒng)更加復雜，主要體現(xiàn)在服務的獨立性和服 務相互調(diào)用的可靠性，以及分布式事務、全局鎖、 全局 Id 等， 而單體系統(tǒng)不需要考慮這些復雜性。
分布式系統(tǒng)的應用都是集群化部署， 會給數(shù)據(jù)一致性帶來困難。
分布式系統(tǒng)中的服 務通信依賴于網(wǎng)絡， 網(wǎng)絡不好，必然會對分布式系統(tǒng)帶來很大的影響。
在分布式系統(tǒng)中，服務 之間相互依賴，如果一個服務出現(xiàn)了故障或者是網(wǎng)絡延遲，在高并發(fā)的情況下，會導致線程阻 塞，在很短的時間內(nèi)該服務的線程資源會消耗殆盡，最終使得該服務不可用 。由于服務的相互 依賴，可能會導致整個系統(tǒng)的不可用，這就是“雪崩效應”。為了防止此類事件的發(fā)生，分布式 系統(tǒng)必然要采取相應的措施，例如“熔斷機制”。

熔斷機制
為了防止“雪崩效應”事件的發(fā)生，分布 式系統(tǒng)采用了熔斷機制。在用 Spring Cloud 構 建的微服務系統(tǒng)中，采用了熔斷器（即 Hystrix 組件的 Circuit Breaker）去做熔斷。 例如在微服務系統(tǒng)中，有 a、 b、 c、 d、 e、 f、 g、 h 等多個服務，用戶的請求通過網(wǎng)關后， 再到具體的服務，服務之間相互依賴，例如服 務 b 依賴于服務 f， 一個對外暴露的 API 接口 需要服務 b 和服務 f相互協(xié)作才能完成。

如果此時服務 b 出現(xiàn)故障或者網(wǎng)絡延遲， 在高并發(fā)的情況下，服務 b 會出現(xiàn)大量的線程阻塞，有可能在很短的時間內(nèi)線程資源就被消耗完了，導致服務 b 的不可用。如果服務 b 為較底層的服務，會影響到其他服務，導致其他服務會一直等待服務 b 的處理。 如果服務 b 遲遲不 處理，大量的網(wǎng)絡請求不僅僅堆積在服務 b，而且會堆積到依賴于服務 b 的其他服務。而因服 務 b 出現(xiàn)故障影響的服務，也會影響到依賴于因服務 b 出現(xiàn)故障影響的服務的其他服務，從而 由 b 開始，影響到整個系統(tǒng)，導致整個系統(tǒng)的不可用。這是一件非?？膳碌氖?，因為服務器運 營商的不可靠，必然會導致服務的不可靠，而網(wǎng)絡服務商的不可靠性，也會導致服務的不可靠。 在高并發(fā)的場景下，稍微有點不可靠，由于故障的傳播性，會導致大量的服務不可用，甚至導 致整個系統(tǒng)崩潰。
為了解決這一難題，微服務架構引入了熔斷機制。當服務 b 出現(xiàn)故障，請求失敗次數(shù)超過 設定的閥值之后，服務 b 就會開啟熔斷器，之后服務 b 不進行任何的業(yè)務邏輯操作，執(zhí)行快速 失敗，直接返回請求失敗的信息。其他依賴于 b 的服務就不會因為得不到響應而線程阻塞，這時除了服務 b 和依賴于服務 b 的部分功能不可用外， 其他功能正常。

熔斷器還有另外一個機制，自我修復的 機制。當服務 b 熔斷后，經(jīng)過一段時間，半打 開熔斷器。半打開的熔斷器會檢查一部分請求 是否正常，其他請求執(zhí)行快邊失敗，檢查的請求如果響應成功，則可以判定服務 b 正常了， 就會關閉服務 b 的熔斷器；如果服務 b 還不正 常，則繼續(xù)打開熔斷器。 這種自我熔斷機制和 自我修復機制在微服務架構中有精重要的意義， 一方面，它使程序更加健壯，另一方面， 為開發(fā)和運維減少很多不必要的工作。
熔斷組件往往會提供一系列的監(jiān)控，例如服務可用與否、熔斷器是否被打開、目前 的吞吐量、網(wǎng)絡延遲狀態(tài)的監(jiān)控等，從而很容易讓開發(fā)人員和運維人員實時地了解服務的狀況。

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

2.由于微服務系統(tǒng)是分布式系統(tǒng)，服務與服務之間沒有任何的禍合。 隨著業(yè)務的增加， 可以根據(jù)業(yè)務再拆分服務， 具有極強的橫向擴展能力。隨著應用的用戶量的增加，井發(fā)量增加， 可以將微服務集群化部署，從而增加系統(tǒng)的負載能力。簡而言之，微服務系統(tǒng)的微服務單元具 有很強的橫向擴展能力。

3.服務與服務之問通過 HTTP 網(wǎng)絡通信協(xié)議來通信，單個微服務內(nèi)部高度禍合，服務與 服務之間完全獨立，無調(diào)合。這使得微服務可以采用任何的開發(fā)語言和技術來實現(xiàn)。開發(fā)人員 不再被強迫使用公司以前的技術或者已經(jīng)過時的技術，而是可以 自由選擇最適合業(yè)務場景的或 者最適合自己的開發(fā)語言和技術，提高開發(fā)效率、降低開發(fā)成本。

4.如果是一個單體的應用，由于業(yè)務的復雜性、代碼的禍合性，以及可能存在的歷史問 題。在重寫一個單體應用時，要求重寫的應用的人員了解所有的業(yè)務，所以重寫單體應用是非 常困難的，并且重寫風險也較高。如果是微服務系統(tǒng)，由于微服務系統(tǒng)是按照業(yè)務的進行拆分 的，并且有堅實的服務邊界，所以重寫某個服務就相當于重寫某一個業(yè)務的代碼，非常簡單。

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

6.微服務在 CAP 理論中采用的是 AP 架構，即具有高可用和分區(qū)容錯的特點。高可用 主要體現(xiàn)在系統(tǒng) 7 x 24 小時不間斷的服務，它要求系統(tǒng)有大量的服務器集群，從而提高了系 統(tǒng)的負載能力。另外，分區(qū)容錯也使得系統(tǒng)更加健壯。