軟體的發展日新月異，我們都希望在軟體交付和執行的過程中做到效率最高，越來越多的技術貫穿在軟體開發測試上線的各個過程中給予我們最快捷的結果，但是我們發現最本質的問題是改進軟體的架構使得這些技術最大化的利用。微服務的概念應運而生，給了我們更好的方法來構建我們的應用系統。本文是在讀了《微服務設計》一書第一章後的總結，希望明確微服務的定義以及微服務給我們帶來的好處。

什麼是微服務

沒有權威的對微服務的定義，但是大家對微服務的總結都異曲同工：

1、小而專業；

在應用系統中的每一個服務都是微小的，只做一件事情體現了專業性，小到什麼程度其實要因系統而異。書中給了我們一條準則：即把因相同原因而變化的東西聚合到一起。比如可以根據團隊組織結構對服務進行劃分，直到一個服務可以由一個小團隊來支援；比如可以根據重寫這個服務的時間來判斷，大概兩週可以重寫的服務算作微服務；比如可以根據該服務涉及到的功能來判斷，當單一服務完成單一功能時可以判定是微服務。我們可以提供很多“比如”，但是並沒有一個非常明確的準則。同時，當服務細微，我們需要考慮到如何管理大量服務的方法。如何將一個單體應用系統拆分成微服務又涉及到領域驅動設計的專題，我們之後再討論。

2、獨立自治；

一個微服務是一個獨立的實體，我們可以獨立進行開發、運營，不需要其他服務的依賴。服務的部署不能引起服務消費方的變動。某項服務會向其他服務暴露API，服務之間通過網路呼叫進行通訊。服務消費方不能與API的實現技術耦合，也不能與服務實現技術本身耦合。某項服務的修改不會影響到其他的服務這是最重要的一點。

微服務的好處：

1、技術異構：

單體系統中，採用新的語言，資料庫或者框架都會對整個系統產生巨大影響；微服務中，不同的服務可以用不同的技術，以使得我們可以在特定的服務中選用最合適的技術，如圖不同的服務可以採用不同的資料庫和程式語言：

2、彈性：

彈性好指的是如果系統中某個部件不能用了，是否會對其他元件起到非常重要的影響。在單體系統中，服務不可用，所有的功能都不可用，除非增加多個例項執行在不同機器上以降低功能損失概率。在微服務系統中，正如我們前面所述，服務之間是獨立的，服務是否可用並不會相互影響。

3、擴充套件：

單體系統的擴充套件必須整體進行擴充套件，即使可能效能問題只存在與某一小部分。但是微服務的擴充套件可以因服務而異，如圖所示：

我們可以根據服務的不同做出不同的擴充套件。

4、簡化部署：

單體應用即使更改某一行程式碼也要重新進行部署，風險高。為了降低這樣的風險，開發者傾向於完成某個新的功能模組後在進行部署，前後部署差異大，出錯可能性高。

微服務應用各個服務是獨立進行部署的，也可以獨立回滾，也就加快了部署的速度，降低了部署的風險。

5、與團隊組織結構相匹配：

我們可以為每一個微服務團隊分配某個具體的微服務任務，尤其是在專案十分龐大的時候，這樣匹配的分配任務極大提升效率。

6、可組合性：

當使用服務的情況發生改變的時候，我們可以重新對微服務的呼叫情況進行組合，達到快速應對變化的目的。

7、對可替代性的優化：

當你希望對老舊的系統進行更新時，會發現在微服務的系統中可以輕鬆的對某個服務進行更新和刪除。

與其他分解技術的比較：

1、共享庫：

將程式碼庫分解成多個庫，不同的團隊和服務可以通過庫的形式共享功能。但是這麼做有幾點缺點：必須使用同種語言或者平臺；無法獨立擴充套件；當庫更新後需要重新部署。

2、模組：

可以使用模組分解技術對模組的生命週期進行管理，使其在程序執行過程中也能夠做修改。但在同一程序內模組與模組之間的隔離會出現各種問題。

微服務並不是殺手鐗，而要根據專案自身的情況選擇微服務，並要做好有關分散式系統的更多的複雜性。