1. 背景

可能存在種種原因，會使得一個工程（或者功能模組）是堆積的，臃腫的，維護困難的。下面說下如何化解這個問題。

2. 走向服務化

把集中式工程進行拆解的一般成熟的套路是：工程模組化，然後搭配（局域）網路完成通訊互動；

2.1 拆分步驟：

2.1.1 從功能上拆分

從功能上拆分後，可以進一步把粒度分的細一些。根據功能拆分，是有一定的判定依據可遵循的（即根據業務線來清晰劃分）。
通過業務線劃分後，可能粒度還是非常大，那麼可以再通過流程裡面的各個功能點進行拆分。

2.1.1.1可能引入的問題

一個功能A需要呼叫功能B，並且B的執行非常耗時（可能理解成像耗時的批處理一樣的情形），後來由於拆分的緣故，將A和B拆分到了兩個服務中，那麼拆分後，A呼叫B時，這個超時時間的把控變得非常重要，如果處理不好，那麼A呼叫B的情況可能並沒有拆解之前要好（畢竟原來是在同一個程序中，少了一個網路通訊的環節）；比如，A呼叫B，如果超時後，A已經感知到超時異常（此時A怎麼辦，重試嗎？），但是此時B還在執行（B要中斷執行嗎？）；

2.1.1.2 應對方法

針對上面的問題，可能是我們服務拆解粒度過度造成的，也可能是服務本身（或者流程上）也有優化的地方。我的建議是先不拆解，暫時保持A和B在在同一個程序中執行。

還有另外一種解決方法，但是A呼叫B的關係需要滿足一定的前提要求：A呼叫B僅僅是A把訊息傳送給B，具體B的執行成功與否，A是不關心的，但是有一個管理的模組在追蹤B的執行狀態。這種情況就是一種離線的流式處理流程。

需要注意的是，我們這裡講的都是線上的實時呼叫，A呼叫B，大多情況都是需要等下去，一直等到得到反饋的，因此後面的解決方法可能不太適合。

3.微服務的一些好與壞

3.1 拆分的好處：

1.可針對性地進行服務擴容，監控等；
2.序列變並行(pipline、無鎖化)（因為作業系統

3.2 拆分的壞處：

1.過度拆分，使得呼叫關係複雜，網路RTT時間的佔比增加；
2.對於request-response型別的呼叫鏈條應該扁平化，如果呼叫鏈非常深，流程太長，可控就越難；