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

（1）微服務職責劃分

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

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

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.

康威是個程序員，他提出:設計系統的組織在設計系統的時候，會設計出基于這些組織的溝通結構的系統。

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

（2）微服務粒度劃分

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

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

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

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

（3）沒人知道系統整體架構的全貌

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

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

因此，在實際工作中，很難找到這么一個人，他能知道系統整體架構的全貌，這就是微服務的一個痛點。

(4)重復代碼多

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

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

不過，維護這些小小的重復代碼總比統一排期做重構、統一評審 JAR 版本的成本低得多。

（5）分布式事務

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

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

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

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

總結：

1. 微服務的職責劃分
2. 服務的拆分
3. 沒人知道系統的架構全貌
4. 重復代碼多
5. 分布式事務
6. 耗費更多的服務器資源