服務(wù)粒度

當團隊實施微服務(wù)架構(gòu)時，可以根據(jù)團隊規(guī)模來劃分微服務(wù)數(shù)量。一個團隊約有 6 個人時，可以劃分為 2 個微服務(wù)。隨著業(yè)務(wù)的擴展和團隊規(guī)模的增加（例如，擴展到 12 個人），可以將已有的 2 個微服務(wù)進一步細分為 4 個微服務(wù)。這種基于團隊規(guī)模的微服務(wù)拆分方法，有助于管理復(fù)雜度，保持開發(fā)效率。

為什么是 3 個人，不是 4 個或者其他數(shù)量呢？

首先，3 個人負責一個系統(tǒng)，每個人都能夠全面理解整個系統(tǒng)，同時又能夠進行分工。如果是 2 個人，系統(tǒng)的復(fù)雜度不夠，開發(fā)人員可能會感到技術(shù)上的挑戰(zhàn)不夠；如果是 4 個人或者更多，系統(tǒng)復(fù)雜度可能會導(dǎo)致開發(fā)人員無法全面了解系統(tǒng)的細節(jié)。

其次，3 個人形成一個穩(wěn)定的備份，即使其中一個人休假或者調(diào)動到其他系統(tǒng)，剩余的 2 個人也可以支撐工作。如果是 2 個人，剩余的 1 個人可能承擔過大壓力；如果是 1 個人，團隊就存在單點故障。

最后，3 個人的技術(shù)小組可以形成有效的討論，快速達成一致意見。如果是 2 個人，可能會出現(xiàn)意見不一致的情況；如果是 1 個人，可能會陷入思維盲區(qū)；如果是 4 個人或者更多，可能會出現(xiàn)參與度不足的情況。

“三個火槍手”的原則主要適用于微服務(wù)設(shè)計和開發(fā)階段。當微服務(wù)經(jīng)過一段時間發(fā)展后，進入維護期，無需太多開發(fā)工作時，平均每個微服務(wù)維護 1 個人或者幾個微服務(wù)都是可以接受的。然而，為了確保人員備份，最好安排每個微服務(wù)由 2 個人維護，每個人可以維護多個微服務(wù)。

拆分方法

基于業(yè)務(wù)邏輯拆分：這種方式是將系統(tǒng)中的業(yè)務(wù)模塊按照職責范圍識別出來，每個單獨的業(yè)務(wù)模塊拆分為一個獨立的服務(wù)。但在實踐過程中最常見的一個問題就是團隊成員對于“職責范圍”的理解差異很大，經(jīng)常會出現(xiàn)爭論，難以達成一致意見。

基于可擴展拆分：將系統(tǒng)中的業(yè)務(wù)模塊按照穩(wěn)定性排序，將已經(jīng)成熟和改動不大的服務(wù)拆分為穩(wěn)定服務(wù)，將經(jīng)常變化和迭代的服務(wù)拆分為變動服務(wù)。穩(wěn)定的服務(wù)粒度可以粗一些，即使邏輯上沒有強關(guān)聯(lián)的服務(wù)，也可以放在同一個子系統(tǒng)中。

基于可靠性拆分：將系統(tǒng)中的業(yè)務(wù)模塊按照優(yōu)先級排序，將可靠性要求高的核心服務(wù)和可靠性要求低的非核心服務(wù)拆分開來，然后重點保證核心服務(wù)的高可用。具體拆分的時候，核心服務(wù)可以是一個也可以是多個，只要最終的服務(wù)數(shù)量滿足“三個火槍手”的原則就可以。

基于性能拆分：基于性能瓶頸將系統(tǒng)中的業(yè)務(wù)模塊進行拆分，將性能要求高或者性能壓力大的模塊拆分為獨立的服務(wù)。例如，電商系統(tǒng)中，搶購功能可能會導(dǎo)致性能瓶頸，可以將該功能獨立為一個服務(wù)。

基礎(chǔ)設(shè)施

大多數(shù)人關(guān)注微服務(wù)的“small”和“l(fā)ightweight”特性，但實際上微服務(wù)的成敗更多取決于被忽視的“automated”（自動化）方面。為什么這樣說呢？因為即使服務(wù)粒度劃分不合理，當團隊遇到問題時，很自然地會考慮重新拆分或合并服務(wù)；但如果與“automated”相關(guān)的基礎(chǔ)設(shè)施不健全，微服務(wù)就會成為一個坑，使得研發(fā)、測試和運維陷入各種微服務(wù)陷阱中。

微服務(wù)基礎(chǔ)設(shè)施如下圖所示：

圖片

看到上面這張圖，相信很多人都會倒吸一口涼氣，說好的微服務(wù)的“輕量級”呢？都這么多基礎(chǔ)設(shè)施還好意思說自己是“輕量級”，感覺比 ESB 還要復(fù)雜??？

確實如此，微服務(wù)并不是很多人認為的那樣簡單和輕量級。要成功實施微服務(wù)，這些基礎(chǔ)設(shè)施是必不可少的，否則微服務(wù)可能會成為一個難以擺脫的泥潭，使業(yè)務(wù)和團隊陷入困境。因此，可以說微服務(wù)并沒有減少復(fù)雜性，而是將復(fù)雜性從ESB（企業(yè)服務(wù)總線）轉(zhuǎn)移到了基礎(chǔ)設(shè)施上。你可以看到，“服務(wù)發(fā)現(xiàn)”、“服務(wù)路由”等實際上都是ESB的功能，只是在微服務(wù)中被剝離出來，成為了獨立的基礎(chǔ)系統(tǒng)。

雖然建設(shè)完善的微服務(wù)基礎(chǔ)設(shè)施是一項龐大的工程，但不必因為團隊規(guī)模較小或公司規(guī)模不大而放棄微服務(wù)的實施。首先，開源社區(qū)已經(jīng)提供了一些成熟的微服務(wù)基礎(chǔ)設(shè)施解決方案，比如知名的 Spring Cloud 項目，包含了服務(wù)發(fā)現(xiàn)、服務(wù)路由、網(wǎng)關(guān)、配置中心等功能。其次，如果微服務(wù)的數(shù)量不是很多，也并非每個基礎(chǔ)設(shè)施都是必需的。因此，我建議按照以下優(yōu)先級來搭建基礎(chǔ)設(shè)施：

1. 服務(wù)發(fā)現(xiàn)、服務(wù)路由、服務(wù)容錯：這是最基本的微服務(wù)基礎(chǔ)設(shè)施。

2. 接口框架、API 網(wǎng)關(guān)：主要是為了提升開發(fā)效率，接口框架是提升內(nèi)部服務(wù)的開發(fā)效率，API 網(wǎng)關(guān)是為了提升與外部服務(wù)對接的效率。

3. 自動化部署、自動化測試、配置中心：主要是為了提升測試和運維效率。

4. 服務(wù)監(jiān)控、服務(wù)跟蹤、服務(wù)安全：主要是為了進一步提升運維效率。

以上 3 和 4 兩類基礎(chǔ)設(shè)施，其重要性會隨著微服務(wù)節(jié)點數(shù)量增加而越來越重要，但在微服務(wù)節(jié)點數(shù)量較少的時候，可以通過人工的方式支撐，雖然效率不高，但也基本能夠頂住。