縱向拆分

是從業(yè)務(wù)維度進(jìn)行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個微服務(wù)，而功能相對比較獨(dú)立的業(yè)務(wù)適合單獨(dú)拆分為一個微服務(wù)。

以社交App為例，你可以認(rèn)為首頁信息流是一個服務(wù)，評論是一個服務(wù)，消息通知是一個服務(wù)，個人主頁也是一個服務(wù)。

橫向拆分

是從公共且獨(dú)立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個其他服務(wù)調(diào)用，且依賴的資源獨(dú)立不與其他業(yè)務(wù)耦合。

繼續(xù)以前面提到的社交App舉例，無論是首頁信息流、評論、消息箱還是個人主頁，都需要顯示用戶的昵稱。假如用戶的昵稱功能有產(chǎn)品需求的變更，你需要上線幾乎所有的服務(wù)，這個成本就有點(diǎn)高了。顯而易見，如果我把用戶的昵稱功能單獨(dú)部署成一個獨(dú)立的服務(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ù)量。

這樣拆分主要是為了提升項(xiàng)目快速迭代的效率，避免在開發(fā)的時候，不小心影響了已有的成熟功能導(dǎo)致線上問題。

基于可靠性拆分

將系統(tǒng)中的業(yè)務(wù)模塊按照優(yōu)先級排序，將可靠性要求高的核心服務(wù)和可靠性要求低的非核心服務(wù)拆分開來，然后重點(diǎn)保證核心服務(wù)的高可用。

基于性能拆分

基于性能拆分和基于可靠性拆分類似，將性能要求高或者性能壓力大的模塊拆分出來，避免性能壓力大的服務(wù)影響其他服務(wù)。常見的拆分方式和具體的性能瓶頸有關(guān)，可以拆分 Web 服務(wù)、數(shù)據(jù)庫、緩存等。例如電商的搶購，性能壓力最大的是入口的排隊(duì)功能，可以將排隊(duì)功能獨(dú)立為一個服務(wù)。

參考文章：

四種常用的微服務(wù)架構(gòu)拆分方式 - 知乎

如今的微服務(wù)是如何把系統(tǒng)劃分成一個個服務(wù)的，都有些什么方法？而原先的SOA架構(gòu)又是如何劃分服務(wù)的？ - 知乎

遺留系統(tǒng)的服務(wù)拆分 - 知乎

如何合理的拆分微服務(wù)_博客微服務(wù)拆分怎么拆分_wh柒八九的博客-CSDN博客?

微服務(wù)拆分的原則、方法和誤區(qū)?