### 微服務的九大特性 > 1. **服務組件化** > 2. **按業務組織團隊** > 3. **做“產品”的態度** > 4. **智能端點與啞管道** > 5. **去中心化治理** > 6. **去中心化數據管理** > 7. **基礎設施自動化** > 8. **容錯設計** > 9. **演進式設計** * **服務組件化** 組件，是一個可以獨立更換和升級的單元。就像PC中的CPU、內存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。在“微服務”架構中，需要我們對服務進行組件化分解。服務，是一種進程外的組件，它通過http等通信協議進行協作，而不是傳統組件以嵌入的方式協同工作。服務都獨立開發、部署，可以有效的避免一個服務的修改引起整個系統的重新部署 微服務架構中將組件定義為可被獨立替換和升級的軟件單元，在應用架構設計中通過將整體應用切分成可獨立部署及升級的微服務方式進行組件化設計 * **按業務組織團隊** 微服務架構采取以業務能力為出發點組織服務的策略，因此微服務團隊的組織結構必須是跨功能的（如：既管應用，也管數據庫）、強搭配的DevOps開發運維一體化團隊，通常這些團隊不會太大； 當我們開始決定如何劃分“微服務”時，通常也意味著我們要開始對團隊進行重新規劃與組織。按以往的方式，我們往往會以技術的層面去劃分多個不同的團隊，比如：DBA團隊、運維團隊、后端團隊、前端團隊、設計師團隊等等。若我們繼續按這種方式組織團隊來實施“微服務”架構開發時，當有一個有問題需要更改，可能是一個非常簡單的變動，比如：對人物描述增加一個字段，這就需要從數據存儲開始考慮一直到設計和前端，雖然大家的修改都非常小，但這會引起跨團隊的時間和預算審批。 在實施“微服務”架構時，需要采用不同的團隊分割方法。由于每一個微服務都是針對特定業務的寬棧或是全棧實現，既要負責數據的持久化存儲，又要負責用戶的接口定義等各種跨專業領域的職能。因此，面對大型項目時候，對于微服務團隊拆分更加建議按業務線的方式進行拆分，一方面可以有效減少服務內部修改所產生的內耗；另一方面，團隊邊界可以變得更為清晰 * **做“產品”的態度** 傳統的應用模式是一個團隊以項目模式開發完整的應用，開發完成后就交付給運維團隊負責維護；微服務架構則倡導一個團隊應該如開發產品般負責一個“微服務”完整的生命周期，倡導“誰開發，誰運營”的開發運維一體化方法 * **智能端點與啞管道** 微服務架構主張將組件間通訊的相關業務邏輯/智能放在組件端點側而非放在通訊組件中，通訊機制或組件應該盡量簡單及松耦合。RESTful HTTP協議和僅提供消息路由功能的輕量級異步機制是微服務架構中最常用的通訊機制 在“微服務”架構中，通常會使用這兩個服務調用方式： * 第一種，使用HTTP協議的RESTful API或輕量級的消息發送協議，來實現信息傳遞與服務調用的觸發。 * 第二種，通過在輕量級消息總線上傳遞消息，類似RabbitMQ等一些提供可靠異步交換的結構 > 在極度強調性能的情況下，有些團隊會使用二進制的消息發送協議，例如：protobuf。即使是這樣，這些系統仍然會呈現出“智能端點和啞管道”的特點，為了在易讀性與高效性之間取得平衡。當然大多數Web應用或企業系統并不需要作出在這兩者間做出選擇，能夠獲得易讀性就已經是一個極大的勝利了。 ——Martin Fowler * **去中心化治理** 整體式應用往往傾向于采用單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每個微服務可以考慮選用最佳工具完成\(如不同的編程語言\)。微服務的技術標準傾向于尋找其他開發者已成功驗證解決類似問題的技術 * **去中心化數據管理** 微服務架構倡導采用多樣性持久化\(PolyglotPersistence\)的方法，讓每個微服務管理其自有數據庫，并允許不同微服務采用不同的數據持久化技術； 數據管理的去中心化可以讓數據管理更加細致化，通過采用更合適的技術來讓數據存儲和性能達到最優。但是，由于數據存儲于不同的數據庫實例中后，數據一致性也成為“微服務”架構中急需解決的問題之一。分布式事務的實現，本身難度就非常大，所以在“微服務”架構中，我們更強調在各服務之間進行“無事務”的調用，而對于數據一致性，只要求數據在最后的處理狀態是一致的效果；若在過程中發現錯誤，通過補償機制來進行處理，使得錯誤數據能夠達到最終的一致性 * **基礎設施自動化** 云化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度，通過應用持續集成和持續交付等方法有助于達到加速推出市場的目的； 在“微服務”架構中，請務必從一開始就構建起“持續交付”平臺來支撐整個實施過程，該平臺需要兩大內容，不可或缺： 1. 自動化測試：每次部署前的強心劑，盡可能的獲得對正在運行軟件的信心； 2. 自動化部署：解放繁瑣枯燥的重復操作以及對多環境的配置管理； 3. **容錯設計** 微服務架構所帶來的一個后果是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及業務相關指標的實時監控和日志機制； 在單體應用中，一般不存在單個組件故障而其他還在運行的情況，通常是一掛全掛。而在“微服務”架構中，由于服務都運行在獨立的進程中，所以是存在部分服務出現故障，而其他服務都正常運行的情況，比如：當正常運作的服務B調用到故障服務A時，因故障服務A沒有返回，線程掛起開始等待，直到超時才能釋放，而此時若觸發服務B調用服務A的請求來自服務C，而服務C頻繁調用服務B時，由于其依賴服務A，大量線程被掛起等待，最后導致服務A也不能正常服務，這時就會出現故障的蔓延。 所以，在“微服務”架構中，快速的檢測出故障源并盡可能的自動恢復服務是必須要被設計和考慮的。通常，我們都希望在每個服務中實現監控和日志記錄的組件，比如：服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等 * **演進式設計** 微服務應用更注重快速更新，因此系統的計會隨時間不斷變化及演進。微服務的設計受業務功能的生命周期等因素影響。如某應用是整體式應用，但逐漸朝微應用架構方向演進，整體式應用仍是核心，但新功能將使用應用所提供的API構建。再如在某微服務應用中，可替代性模塊化設計的基本原則，在實施后發現某兩個微服務經常必須同時更新，則這很可能意味著應將其合并為一個微服務