概述

目前微服務已經火了一段時間了，各大互聯網公司都普遍採用了微服務技術作為大型系統架構的解決方案，今天主要對於微服務做個簡單總結。

什麼是微服務

微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每個小型服務都運行在自己的進程中，並經常採用HTTP資源API這樣輕量的機制來相互通信。這些服務圍繞業務功能進行構建，並能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，並且可以使用不同的數據存儲技術。對這些微服務我們僅做最低限度的集中管理。

總結一下上面的話，可以看出，微服務有以下特性：

1.每一個微服務可獨立運行在自己的進程裡

2.一系列獨立運行的微服務共同構建起了整個系統

3.每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，如“訂單管理”、“用戶管理”等。

4.微服務之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。

微服務與單體服務的對比

下圖左側是一個單體服務，右側是一個微服務群：

左側的單體架構，所有的模塊放在一起，共享UI以及數據庫等資源。

右側的微服務，每個模塊單獨運行，並且每個模塊有自己的數據庫。例如訂單模塊是IO密集的，它的數據可能使用Redis進行存儲；而電影模塊的數據適合使用關係型數據庫，那麼它的數據可能使用Mysql進行存儲。它們相互之間通過一系列輕量級的通信機制進行通信。

所以這裡可以得出，微服務的特點為：

●易於開發和維護
●啟動較快
●局部修改容易部署
●技術棧不受限
●按需伸縮
●DevOps
●運維要求更高
●分佈式的複雜性
●接口調整成本高
●重複勞動

微服務的設計原則

瞭解了微服務的細節後，接下來看看微服務的設計原則

微服務的設計原則如下：

●單一職責原則

指的是每一個微服務模塊，只關心自己的業務規則。例如訂單模塊只關心訂單的相關業務，不牽扯其他業務的邏輯。

●服務自治原則

每一個微服務模塊的開發，需要有自己的開發、測試、運維、部署這一條獨立的棧，並且有自己的數據庫等一切，完全把其當成一個單獨的項目來做，不牽扯到其它無關業務。

●輕量級通信原則

微服務的通信協議需要跨平臺、跨語言的通信協議，因為微服務是不綁定技術棧的，不論使用Java、PHP還是.net去開發Web系統，它們之間的通信一定是去語言特色的。

●接口明確原則

前面提到了微服務的“接口調整成本高”，那麼怎麼去避免它呢？我們一開始就應該規劃好微服務的模塊是一種什麼樣的模型，儘量去避免A接口的改動會導致B接口的改動這種情況。

後面小編會分享更多devops和DBA方面內容，感興趣的朋友走一波關注哩~