微服務架構是由小型自主服務的集合所組成。 每個服務都是獨立的，而且應該在限定的內容內實作單一商務功能。 限定內容是企業內的自然部門，並提供定義域模型存在的明確界限。
什麼是微服務？
微服務屬於小型、獨立且鬆散結合的服務。 開發人員的單一小型小組可以撰寫和維護服務。
每項服務的程式碼基底各自分開，由小型的開發小組負責管理。
服務可以獨立部署。 小組可以直接更新現有服務，而不需要重建和重新部署整個應用程式。
服務會負責保存自己的數據或外部狀態。 這與傳統模型不同，其中個別的數據層會處理數據持續性。
服務會使用定義完善的 API 彼此通訊。 每個服務的內部實作詳細資料都會對其他服務隱藏。
支援多語言程式設計。 例如，服務不需要共用相同的技術堆疊、連結庫或架構。
除了服務本身之外，其他一些元件會出現在一般微服務架構中：
管理/協調流程。 此元件負責將服務放在節點上、識別失敗、跨節點重新平衡服務等等。 此元件通常是現成的技術，例如 Kubernetes，而不是自定義建置的專案。
API 閘道。 API 閘道是客戶端的進入點。 用戶端會呼叫 API 閘道，而不是直接呼叫服務，這會將呼叫轉送至後端的適當服務。
使用 API 閘道的優點包括：
它會將客戶端與服務分離。 服務可以進行版本設定或重構，而不需要更新所有用戶端。
服務可以使用不易用 Web 的傳訊通訊協定，例如 AMQP。
API 閘道可以執行其他交叉功能，例如驗證、記錄、SSL 終止和負載平衡。
現用原則，例如節流、快取、轉換或驗證。
福利
靈活度。 因為微服務為獨自部署，所以可更輕鬆地管理錯誤 (bug) 修正和功能版本。 您可以更新服務而不重新部署整個應用程式，並在發生問題時回復更新。 在許多傳統應用程式中，如果在應用程式的某個部分找到錯誤，這可能會封鎖整個發行程序。 新功能可能會擱置，等待 Bug 修正整合、測試和發布。
小型、專注的團隊。 微服務應小到讓單一功能小組可加以建置、測試及部署。 小型小組大小可提升更大的靈活度。 大型小組的生產力往往較低，因為通訊速度較慢，管理額外負荷會增加，且靈活度會降低。
小型程式代碼基底。 在整合型應用程式中，程式代碼相依性會隨著時間而變得糾纏的趨勢。 新增功能需要在很多地方接觸程序代碼。 微服務架構不會共用程式碼或資料存放區，因而降低相依性，並可讓您更輕鬆地新增功能。
混合技術。 小組可以視情況使用混合的技術堆疊，以挑選出最適合其服務使用的技術。
錯誤隔離。 如果個別微服務變得無法使用，只要任何上游微服務都設計成正確處理錯誤，它就不會中斷整個應用程式。 例如，您可以實 作斷路器模式，也可以設計解決方案，讓微服務使用 異步傳訊模式彼此通訊。
延展性。 服務可以獨立調整，讓您相應放大需要更多資源的子系統，而不需要相應放大整個應用程式。 使用 Kubernetes 之類的協調器，您可以將較高的服務密度封裝到單一主機，以更有效率地利用資源。
資料隔離。 執行架構更新會更容易，因為只有單一微服務受到影響。 在整合型應用程式中，架構更新可能會變得非常具有挑戰性，因為應用程式的不同部分可能會觸碰相同的數據，而對架構有風險的任何變更。
挑戰
微服務的優點不會免費取得。 以下是開始微服務架構之前要考慮的一些挑戰。
複雜度。 微服務應用程式的變動組件數量比同等單體式應用程式的還多。 每個服務會更為簡單，但是系統整個會變得更複雜。
開發和測試。 撰寫依賴其他相依服務的小型服務，需要不同於撰寫傳統整合型或分層式應用程式的方法。 現有工具的設計不一定適合處理服務相依性。 跨服務界限進行重構會很困難。 測試服務相依性也會很困難，尤其是當應用程式的演變速度很快時。
缺乏治理。 微服務的非集中式建置方法有其優點，卻也可能導致問題發生。 您最終可能會有很多不同的語言和架構，而讓應用程式變得難以維護。 備有某些適用於全部專案的標準，而不要過度限制小組的彈性，這樣的做法可能會有幫助。 這特別適用於跨領域功能，例如記錄。
網路壅塞和延遲。 使用許多小型且細微的服務可能會導致服務之間需要更多通訊。 此外，如果服務相依性鏈結變得太長（服務 A 呼叫 B，它會呼叫 C...），額外的延遲可能會變成問題。 您將必須謹慎地設計 API。 避免過度閒聊的 API、考慮串行化格式，並尋找使用異步通訊模式的位置，例如 佇列型負載撫平。
資料完整性。 每個微服務都會負責自己的數據持續性。 因此，跨多個服務的數據一致性可能是一項挑戰。 不同的服務會在不同的時間保存數據，使用不同的技術，以及可能不同的成功層級。 當有多個微服務參與保存新的或變更日期時，不太可能將完整的數據變更視為 ACID 交易。 相反地，這項技術更符合BASE（基本可用、軟狀態和最終一致）。 可能的話，請採用最終一致性。
管理。 想要成功運用微服務，就必須有成熟的 DevOps 文化。 在服務之間建立關聯式記錄會非常困難。 一般而言，記錄必須將多個服務呼叫相互關聯到單一使用者作業。
版本控制。 服務的更新不得打斷與其相依的服務。 多個服務有可能在同一時間一起更新，因此若未謹慎設計，便可能發生回溯相容性或往後相容性問題。
技能集。 微服務是高度分散的系統。 請謹慎評估小組是否有技能和經驗能夠成功。
最佳作法
建立商務網域周圍的模型服務。
分散所有專案。 個別小組負責設計和建置服務。 避免共用程式代碼或數據架構。
數據記憶體應該是擁有數據之服務的私用記憶體。 針對每個服務和數據類型使用最佳的記憶體。
服務會透過設計完善的 API 進行通訊。 避免洩漏實作詳細數據。 API 應該建立網域的模型，而不是服務的內部實作。
避免在服務之間結合。 結合的原因包括共用資料庫架構和嚴格的通訊協定。
將跨領域考慮，例如驗證和 SSL 終止卸除至閘道。
讓網域知識遠離閘道。 網關應該處理和路由傳送用戶端要求，而不需要瞭解商務規則或網域邏輯。 否則，閘道會變成相依性，而且可能會導致服務之間的結合。
服務應該具有鬆散結合和高功能凝聚力。 可能一起變更的函式應該封裝並部署在一起。 如果它們位於個別的服務中，這些服務最終會緊密結合，因為一個服務中的變更需要更新另一個服務。 兩個服務之間過度閒聊的通訊可能是緊密結合和低凝聚力的癥狀。
下一步
如需在 Azure 上建置微服務架構的詳細指引，請參閱 在 Azure 上設計、建置和操作微服務。