什么是Microservices

今天就跟大家聊聊有關什么是Microservices，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

什么是 Microservices

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

實際上，業界對于微服務本身并沒有一個嚴格的定義。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 每個服務都可以有自己的開發語言、開發方式，靈活性大大提高。

何時采用 Microservices

對于分布式設計來說，分布式第一定律是“盡量不要使用分布式”。因為系統的分布式一定會帶來性能的開銷。

微服務使得開發變得更簡單，快捷了。以前開發人員耗費時間來搭建環境、熟悉代碼結構，在微服務的世界里會簡單許多。但是，微服務帶來了一系列的非功能性需求，比如說事務、服務治理（注冊，發現，負載，路由，認證授權，隔離）、監控（日志，性能監控，告警，調用鏈路）、部署、測試等。微服務依賴于“基礎設施自動化”。

微服務不是“銀彈”，何時采用微服務還需考慮企業自身的需求。

看完上述內容，你們對什么是Microservices有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。