微服務架構目前已經越來越成為行業的熱門詞匯，它把一種特定的軟件應用的設計方法描述為能夠獨立部署的服務的套件。盡管缺乏對這一架構類型的準確定義，但是在業務能力、自動化部署、智能端點、語言和數據的去中心化控制等方面，已經形成了某些普遍特征。中培偉業《詳細設計與系統架構最佳實踐》曾老師在這里介紹了微服務架構的九大特征。

通過服務實現組件化

曾老師指出，我們已經在軟件行業浸淫多年，一直期望能夠通過拼插組件的方式來構建系統，而不是采用我們在物理世界里常見的方式。在過去的幾十年里，我們已經見證了多數語言平臺的公共庫的匯編已經取得了長足的進步。

圍繞業務能力組織

要把大型應用拆分為零件，管理人員通常聚焦在技術層面，拆分成 UI 組、服務器端邏輯組和數據庫團組。當這些組被這樣垂直分割，非常簡單的改動就會導致跨組項目，而這需要時間和預算批準。聰明的團隊會圍繞這點進行優化，兩害相權取其輕——強化邏輯到任意有訪問權限的應用。

產品而非項目

大多數我們常見的應用開發會使用項目模式：交付軟件的部分然后再考慮組合完整。完成后的軟件被交付到維護機構，構建此項目的團隊不被解散。

微服務的支持者則易于避免此模式，傾向于「在產品的整個生命周期里，開發團隊應該擁有此項目」。這一靈感來自于亞馬遜的「你構建，你運行」概念。在亞馬遜，開發團隊對生產環境中的軟件負有全部責任。這讓開發者每日都能了解自己的軟件如何在生產環境運行，增強與用戶的接觸，也能承擔部分支持職責。

智能終端和啞管道

要在不同進程之間構建通信結構，我們已經見過許多產品和方案，它們強調在通信機制內部注入智能，其中優秀案例如 ESB(企業服務總線)。ESB 產品包含復雜的設施，用于信息路由、編排、轉化，以及應用業務規則。

去中心化治理

中心化治理的一大后果就是單一技術平臺的標準化傾向。經驗顯示這一方式非常狹隘——每個問題各有特色，而「馬斯洛的錘子」并非萬能。我們更喜歡針對工作使用正確的工具，在特定情境下，一體化應用能夠發揮不同語言的優勢。這并不常見。

去中心化數據管理

去中心化數據管理的方式多種多樣。在最為抽象的層級，這意味著各個系統之間關于世界的概念模型大相徑庭。在大型企業進行整合時，這一現象很常見。對客戶的看法，銷售人員的視角與支持人員的視角不同。銷售認為可稱為「客戶」的某些方面，支持人員卻并不認同。他們可能只是具有一些在語言描述上差異很細微的不同屬性。

使用諸如這樣的事務有助于保持一致，但是帶來了顯著的短時耦合，對跨多個服務產生問題。分布式事務因難以實施而聞名，隨之而來，微服務架構強調了服務之間的事務和諧，明確了一致性只可能為最終一致性，各種問題通過補償運算來解決。

基礎設施自動化

基礎設施自動化已經在過去的幾年里取得了巨大的進步。云特別是 AWS 的進化格外地降低了構建、部署和運行微服務時的復雜度。

許多采用微服務構建的產品或系統是由在持續交付和其前身——持續集成方面經驗豐富的團隊構建的。使用這種方法構建軟件的團隊需要大量使用基礎設施自動化技術。

為故障而生

把服務用作組件的一個結果是應用在設計之初就要能容忍技術故障。任何服務調用可能會由于供應商的不可用而失敗，而客戶端需要盡可能優雅地做出響應。與一體化設計相比，由于引入了額外的復雜性來處理，這是一大不足。其結果是微服務團隊不斷反省服務故障如何影響用戶體驗。 Netflix 的 Simian Army 通過測試應用的彈性和監控，減少了工作日的服務故障，甚至數據中心的故障。

進化的設計

微服務從業者通常具有進化設計的背景，把服務分解視作一個長遠的工具，讓應用開發者們能夠控制應用內的改動，無需讓改動慢下來。改動控制并不一定意味著減少——借助正確的態度和工具，你能夠經常快速、有節制地修改軟件。