目錄
介紹
背景
微服務架構
粒度
尺寸
有界的上下文
獨立/自包含
服務組合
服務發現
單獨的存儲
優點和缺點
優點
缺點
合适的協定和架構
合适的架構和接口
物聯網需要完全分散的平台，可以更容易地開發，部署，發現和請求。
介紹
物聯網（IoT）是一種新興技術，需要完全分散的軟體架構，可以從軟體的角度開發，部署，發現和請求更可靠，更靈活。由于面向服務是物聯網的一種合适的軟體架構，微服務架構（MSA）是面向服務的軟體的新範例，我發現寫這篇文章很有用，并且希望它能夠讓你更深入地了解MSA。
這篇文章将有幾個部分，是以我将下一部分的連結放到到文本末尾。第一部分将讨論微服務架構（MSA），并将嘗試解釋MSA的基本概念及其優缺點。
背景
“做一件事，做得好。”
The Unix Philosophy, McIlroy
面向服務的體系結構（SOA）将分布式系統轉移到新的範例。它建構了一個獨立于平台的軟體，稱之為子產品易于實作。SOA所做的一切，其祖先，如遠端過程調用（RPC）、分布式計算環境（DCE）、分布式元件對象模型（DCOM）、元件對象請求代理體系結構（CORBA）和面向對象體系結構，都不能實作。然而，SOA建立在OOA之上，并試圖通過在連接配接裝置的網絡上分發對象和将它們作為結構化消息——如簡單定向通路協定（SOAP）——在不同的機器和系統之間傳輸，将OOA帶到軟體體系結構中的更高層次。
微服務架構
微服務架構（MSA）建構于SOA之上，旨在消除不必要的複雜程度，以縮小功能範圍，為實施的服務提供更多的互操作性和靈活性。是以，微服務架構引入了一個非常狹窄的功能化、小型、獨立、有界的上下文和個性化服務。
粒度
面向服務的體系結構沒有定義任何粒度标準來建立服務，除了建議進行粗粒度服務，是以每個服務可以具有與其他服務共享的功能。例如，假設一個提供Credit業務的Web服務。對于這種服務，通常在一個服務中實作幾個功能。另一方面，MSA本質上提供細粒度的服務。但是，在MSA中作為細粒度或粗粒度服務的定義與SOA完全不同。在SOA中，粒度具有水準透視，而在MSA中，它具有垂直透視。這意味着，在MSA中，服務可以包含來自應用程式的所有層的功能，而不違反細粒度标準。
注意：術語粒度在SOA中沒有任何精确的定義，大多數時候，相關的引用要麼沒有給出這個術語的非常精确的定義，除非依賴于模糊的單詞，要麼它們隻是指服務公開的函數和特征的數量。無論如何，似乎這個特性是在損失耦合，複雜性，可靠性等幾個其他特征之間的折衷。
尺寸
與SOA中的服務相比，MSA中的服務規模相對較小，但沒有真正可靠的測量來找到最佳規模。有些人認為服務開發團隊的規模可以構成服務的規模。其他一些建議使用編碼行數，特征和類似特征。為每項服務找到合适的大小非常重要，因為非常小的尺寸會降低整個系統的可靠性。
有界的上下文
SOA嘗試盡可能多地共享，例如對于相同的Credit業務服務，讓服務具有Account，Customer，Credit Policies，Authentication和Authorization等概念是合理的。是以，将有幾個基礎結構服務與Credit業務服務共享的應用服務，以便通過通路資料庫，網絡和其他共享資源和功能來詳細說明處理接收到的請求。然而，MSA試圖通過不讓服務知道其内部功能并通過使用接口和面向消息的場景來隔離它們來盡可能少地共享。是以，對于相同的示例，MSA可以定義獨立服務。域驅動設計（DDD）可以提升您的服務有限的上下文特征。
獨立/自包含
微服務可單獨部署，并且在操作上獨立于其他服務。這意味着微服務包含它自己完成任務所需的一切。這不僅包括業務邏輯，還包括所有必需的庫。與微服務通信的唯一方法是通過其釋出的接口和代理。
服務組合
雖然SOA中的服務提供詳細的功能需要服務編排（右圖）或編排（左圖），但MSA僅受益于服務編排，後者在更自由的情況下承擔相同的責任。服務編排是一種集中式方法，它使整個系統成為單點故障，這意味着如果服務聚合器之類的協調負責的服務失敗将影響系統的整體可靠性并可能阻止系統實作目标。另一方面，在服務編排中，沒有執行個體確定成功完成所有必需的操作。這仍然是一個懸而未決的問題，需要更多的研究和調查。可能是Paxos等共識算法 在這部分可能很有用。
服務編排與服務編排
服務發現
與SOA不同，在具有适當服務的MSA中，發現不是強制性的，它取決于将要運作的服務的數量。有時，即使是簡單的API網關，服務池，甚至是配置檔案，也可以使所有服務互相識别。
單獨的存儲
在MSA中，每個服務都有自己的存儲政策，無論其他服務如何，它都負責存儲執行任務所需的所有必要資訊。實際上，MSA的這一特性消除了處理SOA中資料流範例的複雜性。
優點和缺點
最後的每個系統都是一組缺點和專業人員之間的交易，這取決于系統工程師根據他的系統特性做出正确的選擇。為了使這一點更加清晰，想象一下砍伐一棵樹的事情。有一些工具都具有切割功能，例如鋸，刀和電子鋸。但是，問題是哪一個效率更高？
有效性（e）=效率（e）x績效（p）
上述等式意味着如果效率或性能為零，則有效性也将為零。是以，我們總是需要同時關注P(績效)和E(效率)。以下是有關MSA優缺點的簡短清單。
優點
- 使用編排而不是編排的分散式和解耦式體系結構使得服務基于釋出——訂閱，是以完全分散
- 做一件事，并做得很好（Unix哲學），更集中和單一，功能非常狹窄
- 容易實作并行性和負載平衡，因為從業務流程的角度來看，它更精細
- 無狀态，然而，具有狀态微服務是有效的，但它不是理想的
- 單獨的資料存儲使服務輕松的繼續跟蹤資料流
- 由于使用基于容器引擎的技術（如docker），是以可輕松實作自動部署和發現
- 更多的互操作性，使服務能夠更靈活地接受/删除新的/目前的服務或協定
- 與表述性狀态轉移（REST）完全相容，允許建立無狀态服務
- 适用于離散系統，例如用于批量自動化過程
缺點
- 服務同步，保持服務以協作方式同步
- 很難找到系統性問題，例如，當流程中存在邏輯錯誤時在業務活動鍊中發現問題更加困難，并且需要将多個日志檔案合并為一個
- 當微服務的數量超過幾個時，自動部署和發現是必須的
- 很難找到合适的服務粒度，這會導緻整個系統由于不堪重負的網絡通信和錯誤配置而導緻不穩定
- 當業務系統不夠分散時，就像持續的流程控制一樣具有挑戰性
- 開發自動化測試比單一系統困難得多
由于本文的下一部分将更詳細地讨論以下标題，我隻想簡要總結一下。
合适的協定和架構
HTTP：“超文本傳輸協定（HTTP）是用于分布式協作超媒體資訊系統的應用程式級協定。” （RFC 2068）
Representational State Transfer（REST）：REST不是協定，也不是軟體标準。REST是一種軟體體系結構，它讨論建構無狀态軟體子產品，例如通過無狀态協定（如HTTP）進行通信的Web服務（或者我認為任何支援無狀态端到端的類似協定）。請注意，當我們讨論無狀态時，事實上，我們正在順利地提到MSA特征集，如粒度，自包含，有界上下文和單獨的存儲。
合适的架構和接口
Nancy：法國東北部的一個河濱城市。弗蘭克·辛納特拉的女兒。一個傘形項目，它包含用于建構基于.NET和Mono的HTTP服務的輕量級、低儀式的架構的所有必要元件。所有這三個定義都是正确的，更多資訊可以在這裡找到。
OWIN：是一個用于解耦.NET Web伺服器和.NET Web應用程式的接口，以降低Web應用程式中的HTTP.sys的複雜性并使其易于使用。您可以在本文的第二部分中閱讀有關OWIN架構的更多資訊。
轉到下一部分
原文位址：https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I