服務(wù)拆分的幾種方法
縱向拆分（基于業(yè)務(wù)邏輯拆分）
是從業(yè)務(wù)維度進(jìn)行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個微服務(wù)，而功能相對比較獨立的業(yè)務(wù)適合單獨拆分為一個微服務(wù)。
以社交App為例，你可以認(rèn)為首頁信息流是一個服務(wù)，評論是一個服務(wù)，消息通知是一個服務(wù)，個人主頁也是一個服務(wù)。橫向拆分
是從公共且獨立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個其他服務(wù)調(diào)用，且依賴的資源獨立不與其他業(yè)務(wù)耦合。
繼續(xù)以前面提到的社交App舉例，無論是首頁信息流、評論、消息箱還是個人主頁，都需要顯示用戶的昵稱。假如用戶的昵稱功能有產(chǎn)品需求的變更，你需要上線幾乎所有的服務(wù)，這個成本就有點高了。顯而易見，如果我把用戶的昵稱功能單獨部署成一個獨立的服務(wù)，那么有什么變更我只需要上線這個服務(wù)即可，其他服務(wù)不受影響，開發(fā)和上線成本就大大降低了。基于可擴(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)中，例如將“日志服務(wù)”和“升級服務(wù)”放在同一個子系統(tǒng)中；不穩(wěn)定的服務(wù)粒度可以細(xì)一些，但也不要太細(xì)，始終記住要控制服務(wù)的總數(shù)量。
這樣拆分主要是為了提升項目快速迭代的效率，避免在開發(fā)的時候，不小心影響了已有的成熟功能導(dǎo)致線上問題。基于可靠性拆分
將系統(tǒng)中的業(yè)務(wù)模塊按照優(yōu)先級排序，將可靠性要求高的核心服務(wù)和可靠性要求低的非核心服務(wù)拆分開來，然后重點保證核心服務(wù)的高可用。
這樣拆分可以帶來以下好處
- 避免非核心的業(yè)務(wù)故障影響核心業(yè)務(wù)
例如，日志上報一般都屬于非核心服務(wù)，但是在某些場景下可能有大量的日志上報，如果系統(tǒng)沒有拆分，那么日志上報可能導(dǎo)致核心服務(wù)故障；拆分后即使日志上報有問題，也不會影響核心服務(wù)。 - 核心服務(wù)高可用方案可以更簡單
核心服務(wù)的功能邏輯更加簡單，存儲的數(shù)據(jù)可能更少，用到的組件也會更少，設(shè)計高可用方案大部分情況下要比不拆分簡單很多。 - 能夠降低高可用成本
將核心服務(wù)拆分出來后，核心服務(wù)占用的機(jī)器、帶寬等資源比不拆分要少很多。因此，只針對核心服務(wù)做高可用方案，機(jī)器、帶寬等成本比不拆分要節(jié)省較多。
- 基于性能拆分
基于性能拆分和基于可靠性拆分類似，將性能要求高或者性能壓力大的模塊拆分出來，避免性能壓力大的服務(wù)影響其他服務(wù)。常見的拆分方式和具體的性能瓶頸有關(guān)，可以拆分 Web 服務(wù)、數(shù)據(jù)庫、緩存等。例如電商的搶購，性能壓力最大的是入口的排隊功能，可以將排隊功能獨立為一個服務(wù)。
以上幾種拆分方式不是多選一，而是可以根據(jù)實際情況自由排列組合，例如可以基于可靠性拆分出服務(wù) A，基于性能拆分出服務(wù) B，基于可擴(kuò)展拆分出 C/D/F 三個服務(wù)，加上原有的服務(wù) X，最后總共拆分出 6 個服務(wù)（A/B/C/D/F/X）。
