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

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

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

自動(dòng)化部署。

可以用不同的編程語言。

可以用不同的存儲(chǔ)技術(shù)。

服務(wù)集中化管理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.微服務(wù)的每個(gè)服務(wù)單元都是獨(dú)立部署的，即獨(dú)立運(yùn)行在某個(gè)進(jìn)程里。微服務(wù)的修改和 部署對(duì)其他服務(wù)沒有影響。試想，假設(shè)一個(gè)應(yīng)用只有一個(gè)簡(jiǎn)單的修改，如果是單體架構(gòu)，需要 測(cè)試和部署整個(gè)應(yīng)用；而如果采用微服務(wù)架構(gòu)，只需要測(cè)試并部署被修改的那個(gè)服務(wù)，這就大 大減少了測(cè)試和部署的時(shí)間。

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