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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有時候為了運維更好的定位問題，我們把服務(wù)各自分配到每一個節(jié)點上，同樣這樣就會耗掉很多的服務(wù)器。

總結(jié)：

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