目前微服務(wù)已經(jīng)火了一段時間了，各大互聯(lián)網(wǎng)公司都普遍采用了微服務(wù)技術(shù)作為大型系統(tǒng)架構(gòu)的解決方案，今天主要對于微服務(wù)做個簡單總結(jié)。
微服務(wù)架構(gòu)風(fēng)格這種開發(fā)方法，是以開發(fā)一組小型服務(wù)的方式來開發(fā)一個獨立的應(yīng)用系統(tǒng)的。其中每個小型服務(wù)都運行在自己的進程中，并經(jīng)常采用HTTP資源API這樣輕量的機制來相互通信。這些服務(wù)圍繞業(yè)務(wù)功能進行構(gòu)建，并能通過全自動的部署機制來進行獨立部署。這些微服務(wù)可以使用不同的語言來編寫，并且可以使用不同的數(shù)據(jù)存儲技術(shù)。對這些微服務(wù)我們僅做最低限度的集中管理。
總結(jié)一下上面的話，可以看出，微服務(wù)有以下特性：
1.每一個微服務(wù)可獨立運行在自己的進程里
2.一系列獨立運行的微服務(wù)共同構(gòu)建起了整個系統(tǒng)
3.每個服務(wù)為獨立的業(yè)務(wù)開發(fā)，一個微服務(wù)一般完成某個特定的功能，如“訂單管理”、“用戶管理”等。
4.微服務(wù)之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調(diào)用。
下圖左側(cè)是一個單體服務(wù)，右側(cè)是一個微服務(wù)群：
左側(cè)的單體架構(gòu)，所有的模塊放在一起，共享UI以及數(shù)據(jù)庫等資源。
右側(cè)的微服務(wù)，每個模塊單獨運行，并且每個模塊有自己的數(shù)據(jù)庫。例如訂單模塊是IO密集的，它的數(shù)據(jù)可能使用Redis進行存儲；而電影模塊的數(shù)據(jù)適合使用關(guān)系型數(shù)據(jù)庫，那么它的數(shù)據(jù)可能使用Mysql進行存儲。它們相互之間通過一系列輕量級的通信機制進行通信。
所以這里可以得出，微服務(wù)的特點為：
了解了微服務(wù)的細節(jié)后，接下來看看微服務(wù)的設(shè)計原則
微服務(wù)的設(shè)計原則如下：
●單一職責(zé)原則
指的是每一個微服務(wù)模塊，只關(guān)心自己的業(yè)務(wù)規(guī)則。例如訂單模塊只關(guān)心訂單的相關(guān)業(yè)務(wù)，不牽扯其他業(yè)務(wù)的邏輯。
●服務(wù)自治原則
每一個微服務(wù)模塊的開發(fā)，需要有自己的開發(fā)、測試、運維、部署這一條獨立的棧，并且有自己的數(shù)據(jù)庫等一切，完全把其當(dāng)成一個單獨的項目來做，不牽扯到其它無關(guān)業(yè)務(wù)。
●輕量級通信原則
微服務(wù)的通信協(xié)議需要跨平臺、跨語言的通信協(xié)議，因為微服務(wù)是不綁定技術(shù)棧的，不論使用Java、PHP還是.net去開發(fā)Web系統(tǒng)，它們之間的通信一定是去語言特色的。
●接口明確原則
前面提到了微服務(wù)的“接口調(diào)整成本高”，那么怎么去避免它呢？我們一開始就應(yīng)該規(guī)劃好微服務(wù)的模塊是一種什么樣的模型，盡量去避免A接口的改動會導(dǎo)致B接口的改動這種情況。
