微服務(wù)的好處有好多，易于擴(kuò)展，發(fā)布簡(jiǎn)單，技術(shù)異構(gòu)，便于重構(gòu)等等，但今天我們的主題不是說(shuō)好處，而是我們需要知道微服務(wù)同樣也會(huì)帶來(lái)痛，我覺(jué)得我們更要重視，提出問(wèn)題，定義問(wèn)題比解決問(wèn)題更加的重要。

（1）微服務(wù)職責(zé)劃分

微服務(wù)的難點(diǎn)在于無(wú)法對(duì)一些特定職責(zé)進(jìn)行清晰劃分，比如這個(gè)職責(zé)歸屬于A還是屬于B，舉例如下：

• 一個(gè)能根據(jù)商品ID找出商品信息的接口，將他放在商品服務(wù)中，再比如單個(gè)用戶的所有訂單，我們就把他放在訂單服務(wù)中
• 業(yè)務(wù)邏輯服務(wù)歸屬和業(yè)務(wù)人員的劃分可能存在關(guān)系，比如每個(gè)商品在每個(gè)門店的庫(kù)存應(yīng)該放在商品服務(wù)還是門店服務(wù)呢？因?yàn)楦髯蚤T店的商品庫(kù)存是由各自門店的運(yùn)營(yíng)人員管理，最終我們決定把它放在門店系統(tǒng)中。
• 業(yè)務(wù)邏輯服務(wù)歸屬還與組織架構(gòu)可能存在關(guān)系，通過(guò)康威定律我們很快就能明白

Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

康威是個(gè)程序員，他提出:設(shè)計(jì)系統(tǒng)的組織在設(shè)計(jì)系統(tǒng)的時(shí)候，會(huì)設(shè)計(jì)出基于這些組織的溝通結(jié)構(gòu)的系統(tǒng)。

上面的例子說(shuō)明，在現(xiàn)實(shí)的場(chǎng)景中，微服務(wù)職責(zé)劃分會(huì)受到太多因素的影響。我們需要慎重考慮。

（2）微服務(wù)粒度劃分

舉例一個(gè)新零售系統(tǒng)，剛開(kāi)始只有登錄和信息管理。這些功能放在一個(gè)服務(wù)就行了，隨著加盟商的加入，因?yàn)榧用松虦?zhǔn)入，開(kāi)店，退出都設(shè)計(jì)費(fèi)用問(wèn)題，因此我們又需要增加財(cái)務(wù)功能，比如應(yīng)收、應(yīng)付、實(shí)收、實(shí)付，退款，對(duì)賬等，緊接著又要對(duì)加盟商員工管理(員工管理、部門管理、權(quán)限管理等)返點(diǎn)、加盟商子門店管理等功能，而此時(shí)的加盟商管理系統(tǒng)只有一個(gè)服務(wù)，你覺(jué)得合適嗎？

一般來(lái)說(shuō)，在設(shè)計(jì)新功能之前，我們會(huì)遵循一個(gè)大致的原則：根據(jù)新的微服務(wù)的大小，安排3-4人設(shè)計(jì)即可。

在對(duì)微服務(wù)拆分的時(shí)候，我們還需要考慮另外一個(gè)因素---績(jī)效。大家都知道，開(kāi)發(fā)人員的績(jī)效很難實(shí)現(xiàn)量化，而微服務(wù)可謂是一個(gè)難得的可量化指標(biāo)。

雖然我們不能拿微服務(wù)數(shù)作為KPI，但是開(kāi)發(fā)人員在闡述個(gè)人工作量的時(shí)候會(huì)提及服務(wù)數(shù)。然后潛意識(shí)里就會(huì)細(xì)化微服務(wù)的個(gè)數(shù)，所以我們需要控制服務(wù)數(shù)，這種方法也可以作為服務(wù)拆分的一個(gè)逆向操作。

（3）沒(méi)人知道系統(tǒng)整體架構(gòu)的全貌

不知道你有沒(méi)有碰到過(guò)這種情況：每隔幾個(gè)月或半年，大領(lǐng)導(dǎo)就會(huì)發(fā)話讓我們匯報(bào)下每個(gè)部門的微服務(wù)數(shù)量、公司微服務(wù)總數(shù)量、每個(gè)微服務(wù)都用來(lái)做什么等情況。因?yàn)槠髽I(yè)微服務(wù)數(shù)較多，所以每次給大領(lǐng)導(dǎo)匯報(bào)時(shí)，都是長(zhǎng)長(zhǎng)的一條清單。

在以前的公司，我首先會(huì)把公司的整個(gè)架構(gòu)系統(tǒng)全貌搞清楚，之后一旦出現(xiàn)問(wèn)題，也就容易定位故障點(diǎn)了。可是自從來(lái)到這家使用微服務(wù)的公司后，我便再也沒(méi)有這樣的沖動(dòng)了，只要求搞懂自己的一畝三分地就行，如果出現(xiàn)問(wèn)題臨時(shí)學(xué)習(xí)一下相關(guān)系統(tǒng)就好了。

因此，在實(shí)際工作中，很難找到這么一個(gè)人，他能知道系統(tǒng)整體架構(gòu)的全貌，這就是微服務(wù)的一個(gè)痛點(diǎn)。

(4)重復(fù)代碼多

比如某個(gè)團(tuán)隊(duì)做了一個(gè)日志自動(dòng)埋點(diǎn)的功能，它能自動(dòng)記錄一些特定方法的調(diào)用。但是第一個(gè)吃螃蟹的團(tuán)隊(duì)使用后，立馬報(bào)出了一個(gè) JAR 版本沖突問(wèn)題，自動(dòng)埋點(diǎn)團(tuán)隊(duì)又重新設(shè)計(jì)了一版埋點(diǎn)的 JAR，并去掉了一些特定 API 的使用，最終 2 個(gè)團(tuán)隊(duì)終于可以正常使用了。不過(guò)呢，第三個(gè)使用埋點(diǎn)的 JAR 的團(tuán)隊(duì)又匯報(bào)了一個(gè) JAR 版本沖突問(wèn)題，又開(kāi)始重復(fù)了上面的操作。

后來(lái)我們復(fù)盤了下，得出結(jié)論：重用 JAR 本身沒(méi)有錯(cuò)，錯(cuò)就錯(cuò)在我們使用的 JAR 版本太多了，必須改變這個(gè)局面。

不過(guò)，維護(hù)這些小小的重復(fù)代碼總比統(tǒng)一排期做重構(gòu)、統(tǒng)一評(píng)審 JAR 版本的成本低得多。

（5）分布式事務(wù)

分布式事務(wù)是微服務(wù)永久的痛，事務(wù)出錯(cuò)，是哪些回滾，哪些不會(huì)滾等等問(wèn)題。

因此在這種情況下，大部分場(chǎng)景下我們不考慮回滾和重試，只考慮Happy Path，如果報(bào)錯(cuò)就記個(gè)異常日志，再線下處理。也是So easy！

(6)耗費(fèi)更多的服務(wù)器資源

有時(shí)候?yàn)榱诉\(yùn)維更好的定位問(wèn)題，我們把服務(wù)各自分配到每一個(gè)節(jié)點(diǎn)上，同樣這樣就會(huì)耗掉很多的服務(wù)器。

總結(jié)：

1. 微服務(wù)的職責(zé)劃分
2. 服務(wù)的拆分
3. 沒(méi)人知道系統(tǒng)的架構(gòu)全貌
4. 重復(fù)代碼多
5. 分布式事務(wù)
6. 耗費(fèi)更多的服務(wù)器資源