簡述 Microservices（微服務）

時間 2019-11-05

標籤簡述 microservices 微服简体版

原文原文鏈接

原文同步至 http://waylau.com/ahout-microservices/html

自 2014 年始，Microservices（微服務）一詞愈來愈火爆，不談 Microservices 似乎就 out 了。那麼什麼是 Microservices？Microservices 架構與傳統的架構有什麼區別？什麼時候應該採用 Microservices？如何構建 Microservices？git

本文，就針對上述提到的問題，來簡單介紹下 Microservices。github

什麼是 Microservices

微服務的誕生並不是偶然: 領域驅動設計指導咱們如何分析並模型化複雜的業務；敏捷方法論幫助咱們消除浪費，快速反饋；持續交付促使咱們構建更快、更可靠、更頻繁的軟件部署和交付能力；虛擬化和基礎設施自動化(Infrastructure As Code)則幫助咱們簡化環境的建立、安裝；DevOps 文化的流行以及特性團隊的出現，使得小團隊更加全功能化。這些都是推進微服務誕生的重要因素。docker

實際上，業界對於微服務自己並無一個嚴格的定義。James Lewis 和 Martin Fowler 對 Microservices 架構作了以下定義：數據庫

簡言之，Microservices 架構風格就像是把小的服務開發成單一應用的形式，運行在其本身的進程中，並採用輕量級的機制進行通訊（通常是 HTTP 資源 API）。這些服務都是圍繞業務能力來構建，經過全自動部署工具來實現獨立部署。這些服務，其可使用不一樣的編程語言和不一樣的數據存儲技術，並保持最小化集中管理。編程

Microservices 包含以下特徵：架構

組件以服務形式來提供：正如其名，微服務也是面向服務的。
圍繞業務功能進行組織：微服務更傾向於圍繞業務功能對服務結構進行劃分、拆解。這樣的服務，是針對業務領域有着關完整實現的軟件，它包含使用接口、持久存儲、以及對旬的交互。所以團隊應該是跨職能的，包含完整的開發技術：用戶體驗、數據庫、以及項目管理。
產品不是項目：傳統的開發模式，是至力於提供一些被認爲是完整的軟件。一旦開發完成，軟件將移交給維護或者實施部門，而後，開發組就能夠解散掉了。而微服務要求開發團隊對軟件產品的整個生命週期負責。這要求開發者天天都關注軟件產品的運行狀況，並與用戶聯繫的更緊密，同時承擔一些售後支持。越小的服務粒度越容易促進用戶與服務提供商以前的關係。Amazon 的理念就是「You build, you run it」，這也正是 DevOps 的文化理念。
強化終端及弱化通道：微服務的應用致力鬆耦合和高內聚，它們更喜歡簡單的REST 風格，而不是複雜的協議（如WS或者BPEL或者集中式框架）。或者採用輕量級消息總線（如 RabbitMQ 或 ZeroMQ 等）來發布消息。
分散治理：這是跟傳統的集中式管理很大區別的地方。微服務把總體式框架中的組件，拆分紅不一樣的服務，在構建它們時將會有更多的選擇。
分散數據管理：當總體式的應用使用單一邏輯數據庫對數據持久化時，企業一般選擇在應用的範圍內使用一個數據庫。微服務讓每一個服務管理本身的數據庫：不管是相同數據庫的不一樣實例，或者是不一樣的數據庫系統。
基礎設施自動化：雲計算，特別是 AWS 的發展，減小了構建、發佈、運維微服務的複雜性。微服務的團隊更加依賴於基礎設施的自動化，畢竟發佈工做至關的無趣。近些年開始火爆的 Docker 也是一個不錯的選擇（能夠參閱《簡述 Docker》）。
容錯性設計：任務服務均可能由於供應商的不可靠而故障。微服務應爲每一個應用的服務及數據中心提供平常故障檢測和恢復。
改進設計：因爲設計會不斷更改，微服務所提供的服務應該可以替換或者報廢，而不是要長久的發展的。

MSA vs. SOA

微服務架構（MSA）與面向服務架構（SOA）類似之處，好比，都是面向服務。一般 SOA 意味着大而全的總體集中式的解決方案。這讓設計、開發、測試、發佈都增長了難度，其中任何細小的代碼變動，都將致使整個系統的須要從新測試，部署。而微服務架構偏偏把全部服務都打散，設置合理的顆粒度，各個服務間保持低耦合，每一個服務都在其完整的生命週期中存活，互相之間影響降到最低。框架

SOA 須要對整個系統進行規範，而 MSA 每一個服務均可以有本身的開發語言、開發方式，靈活性大大提升。運維