概述

目前微服務(wù)已經(jīng)火了一段時間了，各大互聯(lián)網(wǎng)公司都普遍采用了微服務(wù)技術(shù)作為大型系統(tǒng)架構(gòu)的解決方案，今天主要對于微服務(wù)做個簡單總結(jié)。

什么是微服務(wù)

微服務(wù)架構(gòu)風(fēng)格這種開發(fā)方法，是以開發(fā)一組小型服務(wù)的方式來開發(fā)一個獨(dú)立的應(yīng)用系統(tǒng)的。其中每個小型服務(wù)都運(yùn)行在自己的進(jìn)程中，并經(jīng)常采用HTTP資源API這樣輕量的機(jī)制來相互通信。這些服務(wù)圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建，并能通過全自動的部署機(jī)制來進(jìn)行獨(dú)立部署。這些微服務(wù)可以使用不同的語言來編寫，并且可以使用不同的數(shù)據(jù)存儲技術(shù)。對這些微服務(wù)我們僅做最低限度的集中管理。

總結(jié)一下上面的話，可以看出，微服務(wù)有以下特性：

1.每一個微服務(wù)可獨(dú)立運(yùn)行在自己的進(jìn)程里

2.一系列獨(dú)立運(yùn)行的微服務(wù)共同構(gòu)建起了整個系統(tǒng)

3.每個服務(wù)為獨(dú)立的業(yè)務(wù)開發(fā)，一個微服務(wù)一般完成某個特定的功能，如“訂單管理”、“用戶管理”等。

4.微服務(wù)之間通過一些輕量級的通信機(jī)制進(jìn)行通信，例如通過REST API或者RPC的方式進(jìn)行調(diào)用。

微服務(wù)與單體服務(wù)的對比

下圖左側(cè)是一個單體服務(wù)，右側(cè)是一個微服務(wù)群：

左側(cè)的單體架構(gòu)，所有的模塊放在一起，共享UI以及數(shù)據(jù)庫等資源。

右側(cè)的微服務(wù)，每個模塊單獨(dú)運(yùn)行，并且每個模塊有自己的數(shù)據(jù)庫。例如訂單模塊是IO密集的，它的數(shù)據(jù)可能使用Redis進(jìn)行存儲；而電影模塊的數(shù)據(jù)適合使用關(guān)系型數(shù)據(jù)庫，那么它的數(shù)據(jù)可能使用Mysql進(jìn)行存儲。它們相互之間通過一系列輕量級的通信機(jī)制進(jìn)行通信。

所以這里可以得出，微服務(wù)的特點(diǎn)為：

微服務(wù)的設(shè)計(jì)原則

了解了微服務(wù)的細(xì)節(jié)后，接下來看看微服務(wù)的設(shè)計(jì)原則

微服務(wù)的設(shè)計(jì)原則如下：

●單一職責(zé)原則

指的是每一個微服務(wù)模塊，只關(guān)心自己的業(yè)務(wù)規(guī)則。例如訂單模塊只關(guān)心訂單的相關(guān)業(yè)務(wù)，不牽扯其他業(yè)務(wù)的邏輯。

●服務(wù)自治原則

每一個微服務(wù)模塊的開發(fā)，需要有自己的開發(fā)、測試、運(yùn)維、部署這一條獨(dú)立的棧，并且有自己的數(shù)據(jù)庫等一切，完全把其當(dāng)成一個單獨(dú)的項(xiàng)目來做，不牽扯到其它無關(guān)業(yè)務(wù)。

●輕量級通信原則

微服務(wù)的通信協(xié)議需要跨平臺、跨語言的通信協(xié)議，因?yàn)槲⒎?wù)是不綁定技術(shù)棧的，不論使用Java、PHP還是.net去開發(fā)Web系統(tǒng)，它們之間的通信一定是去語言特色的。

●接口明確原則

前面提到了微服務(wù)的“接口調(diào)整成本高”，那么怎么去避免它呢？我們一開始就應(yīng)該規(guī)劃好微服務(wù)的模塊是一種什么樣的模型，盡量去避免A接口的改動會導(dǎo)致B接口的改動這種情況。