摘要：故障處理設計微服務架構所帶來的一個后果就是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及相關業務指標的實時監控和日志機制。

微服務是一種架構風格，一個大型的復雜軟件由一個或多個微服務組成。系統中每個微服務都可以被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成任務。在所有情況下，每個任務代表這一個小的業務能力。

微服務的核心思想是：一個完整的應用由多個小的、相互獨立的微服務組成，這些微服務運行在自己的進程中，開發和發布都沒有依賴。不同微服務通過一些輕量級交互機制來通信，例如RPC、HTTP等，服務可獨立拓展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以采用不同的編程語言來實現，由獨立團隊維護。簡單的來說，一個系統的不同模塊轉變成不同的服務！而且服務可以使用不同的技術加以實現！

微服務的目的是為了根據業務有效拆分應用，實現敏捷開發和部署。

微服務與整體式應用的主要差異在于組裝應用組件，微服務架構將相關聯的業務邏輯及數據放在一起形成獨立的邊界，其目的是在不影響其他應用組件（微服務）的情況下更快地交付并推出市場。

看了很多網上對微服務和SOA區別的看法，分為兩種，一種是對區別侃侃而談，列舉了很多，另一種認為微服務其實是SOA的一種架構實現。從中可以看出微服務和SOA還是有很多相似之處的，只是針對業務需求進行區別設計。

如果非要說區別的話，微服務架構與SOA最主要的區別在于：微服務不再強調傳統SOA架構里面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統內部實現真正的組件化。

微服務架構中將組件定義為可被獨立代替和升級的軟件單元，在應用架構設計中通過正整體應用切分成可獨立部署升級的微服務方式進行組件化設計。

以業務能力為出發點組織服務，微服務團隊的組織結構必須是跨功能的（比如：即管應用也管數據庫），通常團隊功能不會太大。

傳統的應用模式是一個團隊以項目模式開發完整的應用，開發完成后就交付給運維團隊負責維護，微服務架構則倡導一個團隊應該負責一個“微服務”完整的生命周期，“誰開發，誰負責”。

微服務架構主張將組件通訊的相關業務邏輯/智能放在組件端點側而非放在通訊組件中，通訊機制或組件應該盡量簡單及松耦合。

整體式應用往往傾向于采取單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每個微服務可以考慮選用最佳工具完成，如不同的編程語言。

微服務架構倡導采用多樣性持久化的方法，讓每個微服務管理其自由數據庫，并允許不同微服務采用不同的數據持久化技術。

云化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度，通過應用持續集成和持續交付等方法有助于達到加速推出市場的目的。

微服務架構所帶來的一個后果就是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及相關業務指標的實時監控和日志機制。

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

每個服務都比較簡單，可以提供更高的靈活性；

微服務架構的方式是松耦合的，可以提供更高的靈活性；

微服務可通過最佳及合適的不同開發語言與工具（比如不同的數據庫）進行開發，能夠做到有的放矢地解決針對性問題；

每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度；

微服務架構是持續交付的巨大動力，允許在頻繁發布不同服務的同時保持系統其它部分的可用性和穩定性。

微服務的想法在實踐上是好的，單當整體實現時也會呈現出復雜性。

運維開銷及成本增加：整體應用可能只需要部署至一小片應用服務區集群，而微服務可能變成需要構建/測試/部署/運行數十個獨立的服務，并可能需要支持多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40-60個進程。

必須具有DevOps開發運維一體化技能：開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的數據存儲技術如NoSQL，具有較強DevOps技能的人員比較稀缺。

隱式接口與接口匹配問題：把系統分為多個協作組件后會產生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需要協調一起發布。在實際環境中，一個新品發布可能被迫同時發布大量服務，由于集成點的大量增加，微服務架構會有更高的發布風險。

代碼重復：某些底層功能需要被多個服務所用，為了避免將”同步耦合引入到系統中“，有時候需要向不同服務添加同樣的代碼，這就會導致代碼重復。

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

異步機制：微服務往往使用異步編程、消息并行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得復雜化。

可測性的挑戰：在動態環境下服務間的交互會產生非常微妙的行為，難以可視化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或采取必要的其他行動，但對于特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。

部署復雜：一個單體應用只需要在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。相比之下，一個微服務應用一般由大批服務構成，這就形成大量需要配置、部署、擴展和監控的部分。除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的地址（包括服務器地址和端口）。

在合適的項目，合適的團隊，采用微服務架構收益會大于成本。

微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。

需要避免為了“微服務”而“微服務”。

微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

服務化是一種架構風格，以服務、數據為中心，構建服務化架構，具備靈活、按需組合的能力。

單一職責：專注一件事，高內聚、低耦合；

遠程隔離：服務必須支持進行隔離；

獨立性：服務可獨立開發，測試，構建和部署；

輕量級：小且靈活；

接口是服務與外界通訊的唯一方式，接口契約化，標準化，跨版本兼容。

服務可獨立發展，獨立發布，獨立升級，服務在開發和運行態可視、可管、可測、可維、故障自愈。

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

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

相同點：

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

最終表現類似：對于兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；

粒度一般都是服務級別：業界也有不少更細粒度的做法，比如做到數據持久層（允許查詢，不允許增刪改）；

自治性要求很高：熔斷模式一般都是服務基于策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置，配置中心都是必要手段；

不同點：

觸發的原因不太一樣：服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；

管理目標的層次不太一樣：熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分0），而降級一般需要對業務有層次之分（比如降級一般是從外圍服務開始）；

實現方式不太一樣。

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