摘要：故障處理設(shè)計(jì)微服務(wù)架構(gòu)所帶來的一個(gè)后果就是必須考慮每個(gè)服務(wù)的失敗容錯(cuò)機(jī)制。因此，微服務(wù)非常重視建立架構(gòu)及相關(guān)業(yè)務(wù)指標(biāo)的實(shí)時(shí)監(jiān)控和日志機(jī)制。

微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型的復(fù)雜軟件由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中每個(gè)微服務(wù)都可以被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成任務(wù)。在所有情況下，每個(gè)任務(wù)代表這一個(gè)小的業(yè)務(wù)能力。

微服務(wù)的核心思想是：一個(gè)完整的應(yīng)用由多個(gè)小的、相互獨(dú)立的微服務(wù)組成，這些微服務(wù)運(yùn)行在自己的進(jìn)程中，開發(fā)和發(fā)布都沒有依賴。不同微服務(wù)通過一些輕量級(jí)交互機(jī)制來通信，例如RPC、HTTP等，服務(wù)可獨(dú)立拓展伸縮，每個(gè)服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實(shí)現(xiàn)，由獨(dú)立團(tuán)隊(duì)維護(hù)。簡(jiǎn)單的來說，一個(gè)系統(tǒng)的不同模塊轉(zhuǎn)變成不同的服務(wù)！而且服務(wù)可以使用不同的技術(shù)加以實(shí)現(xiàn)！

微服務(wù)的目的是為了根據(jù)業(yè)務(wù)有效拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署。

微服務(wù)與整體式應(yīng)用的主要差異在于組裝應(yīng)用組件，微服務(wù)架構(gòu)將相關(guān)聯(lián)的業(yè)務(wù)邏輯及數(shù)據(jù)放在一起形成獨(dú)立的邊界，其目的是在不影響其他應(yīng)用組件（微服務(wù)）的情況下更快地交付并推出市場(chǎng)。

看了很多網(wǎng)上對(duì)微服務(wù)和SOA區(qū)別的看法，分為兩種，一種是對(duì)區(qū)別侃侃而談，列舉了很多，另一種認(rèn)為微服務(wù)其實(shí)是SOA的一種架構(gòu)實(shí)現(xiàn)。從中可以看出微服務(wù)和SOA還是有很多相似之處的，只是針對(duì)業(yè)務(wù)需求進(jìn)行區(qū)別設(shè)計(jì)。

如果非要說區(qū)別的話，微服務(wù)架構(gòu)與SOA最主要的區(qū)別在于：微服務(wù)不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時(shí)SOA的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件化。

微服務(wù)架構(gòu)中將組件定義為可被獨(dú)立代替和升級(jí)的軟件單元，在應(yīng)用架構(gòu)設(shè)計(jì)中通過正整體應(yīng)用切分成可獨(dú)立部署升級(jí)的微服務(wù)方式進(jìn)行組件化設(shè)計(jì)。

以業(yè)務(wù)能力為出發(fā)點(diǎn)組織服務(wù)，微服務(wù)團(tuán)隊(duì)的組織結(jié)構(gòu)必須是跨功能的（比如：即管應(yīng)用也管數(shù)據(jù)庫(kù)），通常團(tuán)隊(duì)功能不會(huì)太大。

傳統(tǒng)的應(yīng)用模式是一個(gè)團(tuán)隊(duì)以項(xiàng)目模式開發(fā)完整的應(yīng)用，開發(fā)完成后就交付給運(yùn)維團(tuán)隊(duì)負(fù)責(zé)維護(hù)，微服務(wù)架構(gòu)則倡導(dǎo)一個(gè)團(tuán)隊(duì)?wèi)?yīng)該負(fù)責(zé)一個(gè)“微服務(wù)”完整的生命周期，“誰開發(fā)，誰負(fù)責(zé)”。

微服務(wù)架構(gòu)主張將組件通訊的相關(guān)業(yè)務(wù)邏輯/智能放在組件端點(diǎn)側(cè)而非放在通訊組件中，通訊機(jī)制或組件應(yīng)該盡量簡(jiǎn)單及松耦合。

整體式應(yīng)用往往傾向于采取單一技術(shù)平臺(tái)，微服務(wù)架構(gòu)則鼓勵(lì)使用合適的工具完成各自的任務(wù)，每個(gè)微服務(wù)可以考慮選用最佳工具完成，如不同的編程語言。

微服務(wù)架構(gòu)倡導(dǎo)采用多樣性持久化的方法，讓每個(gè)微服務(wù)管理其自由數(shù)據(jù)庫(kù)，并允許不同微服務(wù)采用不同的數(shù)據(jù)持久化技術(shù)。

云化及自動(dòng)化部署等技術(shù)極大地降低了微服務(wù)構(gòu)建、部署和運(yùn)維的難度，通過應(yīng)用持續(xù)集成和持續(xù)交付等方法有助于達(dá)到加速推出市場(chǎng)的目的。

微服務(wù)架構(gòu)所帶來的一個(gè)后果就是必須考慮每個(gè)服務(wù)的失敗容錯(cuò)機(jī)制。因此，微服務(wù)非常重視建立架構(gòu)及相關(guān)業(yè)務(wù)指標(biāo)的實(shí)時(shí)監(jiān)控和日志機(jī)制。

微服務(wù)應(yīng)用更注重快速更新，因此系統(tǒng)會(huì)隨時(shí)間不斷演進(jìn)。微服務(wù)的設(shè)計(jì)受業(yè)務(wù)功能的生命周期等因素影響。如某應(yīng)用是整體式應(yīng)用，但逐漸朝微服務(wù)應(yīng)用架構(gòu)演進(jìn)，整體式應(yīng)用仍是核心，但新功能將使用所提供的API構(gòu)建。再如在某微服務(wù)應(yīng)用中，可代替模塊設(shè)計(jì)的基本原則，在實(shí)施后發(fā)現(xiàn)某兩個(gè)微服務(wù)經(jīng)常必須同時(shí)更新，則這可能意味著應(yīng)將其合并為一個(gè)服務(wù)。

每個(gè)服務(wù)都比較簡(jiǎn)單，可以提供更高的靈活性；

微服務(wù)架構(gòu)的方式是松耦合的，可以提供更高的靈活性；

微服務(wù)可通過最佳及合適的不同開發(fā)語言與工具（比如不同的數(shù)據(jù)庫(kù)）進(jìn)行開發(fā)，能夠做到有的放矢地解決針對(duì)性問題；

每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開發(fā)，互不影響，加快推出市場(chǎng)的速度；

微服務(wù)架構(gòu)是持續(xù)交付的巨大動(dòng)力，允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其它部分的可用性和穩(wěn)定性。

微服務(wù)的想法在實(shí)踐上是好的，單當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出復(fù)雜性。

運(yùn)維開銷及成本增加：整體應(yīng)用可能只需要部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語言和環(huán)境。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成，可能需要40-60個(gè)進(jìn)程。

必須具有DevOps開發(fā)運(yùn)維一體化技能：開發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境，開發(fā)人員也需要掌握必要的數(shù)據(jù)存儲(chǔ)技術(shù)如NoSQL，具有較強(qiáng)DevOps技能的人員比較稀缺。

隱式接口與接口匹配問題：把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件，并需要協(xié)調(diào)一起發(fā)布。在實(shí)際環(huán)境中，一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù)，由于集成點(diǎn)的大量增加，微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)。

代碼重復(fù)：某些底層功能需要被多個(gè)服務(wù)所用，為了避免將”同步耦合引入到系統(tǒng)中“，有時(shí)候需要向不同服務(wù)添加同樣的代碼，這就會(huì)導(dǎo)致代碼重復(fù)。

分布式系統(tǒng)的復(fù)雜性：作為一種分布式系統(tǒng)，微服務(wù)引入了復(fù)雜性和其他若干問題，例如網(wǎng)絡(luò)延遲、容錯(cuò)性、消息序列化、不可靠的網(wǎng)絡(luò)、異步機(jī)制、版本化、差異化的工作負(fù)載等，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。

異步機(jī)制：微服務(wù)往往使用異步編程、消息并行機(jī)制，如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理，其實(shí)現(xiàn)機(jī)制會(huì)變得復(fù)雜化。

可測(cè)性的挑戰(zhàn)：在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為，難以可視化及全面測(cè)試。經(jīng)典微服務(wù)往往不太重視測(cè)試，更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾或采取必要的其他行動(dòng)，但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意。

部署復(fù)雜：一個(gè)單體應(yīng)用只需要在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個(gè)應(yīng)用實(shí)例是需要配置諸如數(shù)據(jù)庫(kù)和消息中間件等基礎(chǔ)服務(wù)。相比之下，一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成，這就形成大量需要配置、部署、擴(kuò)展和監(jiān)控的部分。除此之外，你還需要完成一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。

在合適的項(xiàng)目，合適的團(tuán)隊(duì)，采用微服務(wù)架構(gòu)收益會(huì)大于成本。

微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前，也需要認(rèn)清它所帶來的挑戰(zhàn)。

需要避免為了“微服務(wù)”而“微服務(wù)”。

微服務(wù)架構(gòu)引入策略 – 對(duì)傳統(tǒng)企業(yè)而言，開始時(shí)可以考慮引入部分合適的微服務(wù)架構(gòu)原則對(duì)已有系統(tǒng)進(jìn)行改造或新建微服務(wù)應(yīng)用，逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗(yàn)，而非全盤實(shí)施微服務(wù)架構(gòu)。

服務(wù)化是一種架構(gòu)風(fēng)格，以服務(wù)、數(shù)據(jù)為中心，構(gòu)建服務(wù)化架構(gòu)，具備靈活、按需組合的能力。

單一職責(zé)：專注一件事，高內(nèi)聚、低耦合；

遠(yuǎn)程隔離：服務(wù)必須支持進(jìn)行隔離；

獨(dú)立性：服務(wù)可獨(dú)立開發(fā)，測(cè)試，構(gòu)建和部署；

輕量級(jí)：小且靈活；

接口是服務(wù)與外界通訊的唯一方式，接口契約化，標(biāo)準(zhǔn)化，跨版本兼容。

服務(wù)可獨(dú)立發(fā)展，獨(dú)立發(fā)布，獨(dú)立升級(jí)，服務(wù)在開發(fā)和運(yùn)行態(tài)可視、可管、可測(cè)、可維、故障自愈。

指通過一定的策略，以自動(dòng)或人工管理的方式對(duì)系統(tǒng)中非重要服務(wù)進(jìn)行下線或控制服務(wù)提供量的一種服務(wù)治理手段，以確保系統(tǒng)在高峰期提供更多的資源給重要服務(wù)。

服務(wù)熔斷也稱服務(wù)隔離，很多地方也成為過載保護(hù)，在系統(tǒng)中，由于某些原因使得服務(wù)出現(xiàn)了過載現(xiàn)象，為了防止造成整個(gè)系統(tǒng)故障，從而采取的一種保護(hù)措施。

相同點(diǎn)：

目的很一致：都是從可用性可靠性著想，為防止系統(tǒng)的整體緩慢甚至崩潰，采取的技術(shù)手段；

最終表現(xiàn)類似：對(duì)于兩者來說，最終讓用戶體驗(yàn)到的是某些功能暫時(shí)不可達(dá)或不可用；

粒度一般都是服務(wù)級(jí)別：業(yè)界也有不少更細(xì)粒度的做法，比如做到數(shù)據(jù)持久層（允許查詢，不允許增刪改）；

自治性要求很高：熔斷模式一般都是服務(wù)基于策略的自動(dòng)觸發(fā)，降級(jí)雖說可人工干預(yù)，但在微服務(wù)架構(gòu)下，完全靠人顯然不可能，開關(guān)預(yù)置，配置中心都是必要手段；

不同點(diǎn)：

觸發(fā)的原因不太一樣：服務(wù)熔斷一般是某個(gè)服務(wù)（下游服務(wù)）故障引起，而服務(wù)降級(jí)一般是從整體負(fù)荷考慮；

管理目標(biāo)的層次不太一樣：熔斷其實(shí)是一個(gè)框架級(jí)的處理，每個(gè)微服務(wù)都需要（無層級(jí)之分0），而降級(jí)一般需要對(duì)業(yè)務(wù)有層次之分（比如降級(jí)一般是從外圍服務(wù)開始）；

實(shí)現(xiàn)方式不太一樣。

參考：
什么是微服務(wù)：https://blog.csdn.net/fly_zhy...
什么是微服務(wù)架構(gòu)：https://www.roncoo.com/articl...
你不愿意做微服務(wù)架構(gòu)的十個(gè)理由：https://blog.csdn.net/gsying1...
SOA和微服務(wù)架構(gòu)的區(qū)別：https://www.zhihu.com/questio...
微服務(wù)和SOA的區(qū)別：https://www.zhihu.com/questio...