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

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

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

自動(dòng)化部署。

可以用不同的編程語(yǔ)言。

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

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

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

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

微服務(wù)通過(guò) HTTP 來(lái)互相通信
按照業(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)和語(yǔ)言無(wú)關(guān)。 例如用 Java 寫的服務(wù)可以消費(fèi)用 Go 語(yǔ)言寫的服務(wù)，用 Go寫的服務(wù)又可以消費(fèi)用 Ruby 寫的服務(wù)。 不同的服務(wù)采用不同的語(yǔ)言去實(shí)現(xiàn)，不同的平臺(tái)去部署，它們之間 使用 HTTP 進(jìn)行通訊。

服務(wù)與服務(wù)之間也可以通過(guò)輕量級(jí)的消息總線來(lái)通 信，例如 RabbitMQ、 Kafaka 等。通過(guò)發(fā)送消息或者訂閱 消息來(lái)達(dá)到服務(wù)與服務(wù)之間通信的目的。
服務(wù)與服務(wù)通信的數(shù)據(jù)格式， 一般為 JSON、 XML, 這兩種數(shù)據(jù)格式與語(yǔ)言、平臺(tái)、通信協(xié)議無(wú)關(guān)。一般來(lái) 說(shuō)， JSON 格式的數(shù)據(jù)比 XML 輕量，井且可讀性也比 X1在L 要好。另外一種就是用 Protobuf進(jìn)行數(shù)據(jù)序列化，經(jīng)過(guò)序列化的數(shù)據(jù)為二進(jìn)制數(shù)據(jù)，它比 JSON 更輕量。 用 Protobuf序列化的數(shù)據(jù)為二進(jìn)制數(shù)據(jù)，可讀性非常差， 需要反序列化才能夠讀懂。由于用 Protobuf序列化的數(shù)據(jù)更為輕量，所以 Protobuf在通信協(xié)議 和數(shù)據(jù)存儲(chǔ)上十分受歡迎。
服務(wù)與服務(wù)之間通過(guò) 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ù)量越 來(lái)越多，難以管理和維護(hù)，并且數(shù)據(jù)量的增加會(huì)導(dǎo)致查詢速度越來(lái)越慢。例如， 一個(gè)應(yīng)用有這 樣幾個(gè)業(yè)務(wù)：用戶的信息、用戶的賬戶、用戶的購(gòu)物車、數(shù)據(jù)報(bào)表服務(wù)等。

微服務(wù)的一個(gè)特點(diǎn)就是按業(yè)務(wù)劃分服務(wù)，服務(wù)與服務(wù)之間無(wú)稠合，就連數(shù)據(jù)庫(kù)也是獨(dú)立的。 一個(gè)典型的微服務(wù)的架構(gòu)就是每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)之間沒(méi)有任何聯(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)化部署工具（例如開(kāi)源組件 Jenkins）的出現(xiàn)，自動(dòng)化部署 變得越來(lái)越簡(jiǎn)單。

服務(wù)集中化管理
微服務(wù)系統(tǒng)是按業(yè)務(wù)單元來(lái)劃分服務(wù)的，服務(wù)數(shù)量越多， 管理起來(lái)就越復(fù)雜，因此微服務(wù) 必須使用集中化管理。目前流行的微服務(wù)框架中，例如 Spring Cloud 采用 Eureka 來(lái)注冊(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ù)一致性帶來(lái)困難。
分布式系統(tǒng)中的服 務(wù)通信依賴于網(wǎng)絡(luò)， 網(wǎng)絡(luò)不好，必然會(huì)對(duì)分布式系統(tǒng)帶來(lái)很大的影響。
在分布式系統(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)求通過(guò)網(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 開(kāi)始，影響到整個(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ù)超過(guò) 設(shè)定的閥值之后，服務(wù) b 就會(huì)開(kāi)啟熔斷器，之后服務(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)過(guò)一段時(shí)間，半打 開(kāi)熔斷器。半打開(kāi)的熔斷器會(huì)檢查一部分請(qǐng)求 是否正常，其他請(qǐng)求執(zhí)行快邊失敗，檢查的請(qǐng)求如果響應(yīng)成功，則可以判定服務(wù) b 正常了， 就會(huì)關(guān)閉服務(wù) b 的熔斷器；如果服務(wù) b 還不正 常，則繼續(xù)打開(kāi)熔斷器。 這種自我熔斷機(jī)制和 自我修復(fù)機(jī)制在微服務(wù)架構(gòu)中有精重要的意義， 一方面，它使程序更加健壯，另一方面， 為開(kāi)發(fā)和運(yùn)維減少很多不必要的工作。
熔斷組件往往會(huì)提供一系列的監(jiān)控，例如服務(wù)可用與否、熔斷器是否被打開(kāi)、目前 的吞吐量、網(wǎng)絡(luò)延遲狀態(tài)的監(jiān)控等，從而很容易讓開(kāi)發(fā)人員和運(yùn)維人員實(shí)時(shí)地了解服務(wù)的狀況。

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

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

4.如果是一個(gè)單體的應(yīng)用，由于業(yè)務(wù)的復(fù)雜性、代碼的禍合性，以及可能存在的歷史問(wèn) 題。在重寫一個(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ù)沒(méi)有影響。試想，假設(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)更加健壯。