服務(wù)粒度

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

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

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

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

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

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

拆分方法

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

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

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

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

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

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

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

圖片

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

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

雖然建設(shè)完善的微服務(wù)基礎(chǔ)設(shè)施是一項(xiàng)龐大的工程，但不必因?yàn)閳F(tuán)隊(duì)規(guī)模較小或公司規(guī)模不大而放棄微服務(wù)的實(shí)施。首先，開源社區(qū)已經(jīng)提供了一些成熟的微服務(wù)基礎(chǔ)設(shè)施解決方案，比如知名的 Spring Cloud 項(xiàng)目，包含了服務(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. 自動化部署、自動化測試、配置中心：主要是為了提升測試和運(yùn)維效率。

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

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