微服務(wù)之服務(wù)拆分策略
通常可以根據(jù)以下兩種策略實(shí)現(xiàn)微服務(wù)的架構(gòu)拆分，其一是根據(jù)業(yè)務(wù)能力進(jìn)行服務(wù)拆分，其二是根據(jù)領(lǐng)域模型進(jìn)行服務(wù)拆分。
根據(jù)服務(wù)能力進(jìn)行業(yè)務(wù)拆分
參考Chris的業(yè)務(wù)拆分定義可以看出，首先要識(shí)別業(yè)務(wù)能力，再根據(jù)業(yè)務(wù)能力定義服務(wù)。這里的服務(wù)其實(shí)可以理解為API或者服務(wù)網(wǎng)關(guān)。
拆分后的微服務(wù)應(yīng)該具備以下幾點(diǎn)特性：
架構(gòu)必須穩(wěn)定，能夠有效支撐系統(tǒng)變更
高內(nèi)聚：服務(wù)必須具有凝聚力，應(yīng)實(shí)現(xiàn)一小組高度相關(guān)的功能。
服務(wù)必須符合共同封閉原則，一起變更的事物應(yīng)打包在一起以確保每次變更僅影響一項(xiàng)服務(wù)。
低耦合：服務(wù)必須是松散耦合的，每個(gè)服務(wù)都是封裝其實(shí)現(xiàn)的API。可以在不影響客戶的情況下更改實(shí)現(xiàn)
服務(wù)具備較高的可測(cè)性
每項(xiàng)服務(wù)應(yīng)該足夠輕小，可以支持一個(gè)敏捷小組開發(fā)（6-10人）。
跨團(tuán)隊(duì)持續(xù)交付：擁有一項(xiàng)或多項(xiàng)服務(wù)的每個(gè)團(tuán)隊(duì)都必須是自治的。一個(gè)團(tuán)隊(duì)必須能夠與其他團(tuán)隊(duì)進(jìn)行最少的協(xié)作來(lái)開發(fā)和部署他們的服務(wù)。
以支付交易清算業(yè)務(wù)為例：
根據(jù)子域進(jìn)行服務(wù)拆分
子域是領(lǐng)域的一部分，領(lǐng)域是DDD中用來(lái)描述應(yīng)用程序問(wèn)題域的一個(gè)術(shù)語(yǔ)。領(lǐng)域驅(qū)動(dòng)為每一個(gè)子域定義單獨(dú)的領(lǐng)域模型。識(shí)別子域的方式跟識(shí)別業(yè)務(wù)能力一樣：分析業(yè)務(wù)并識(shí)別業(yè)務(wù)的不同專業(yè)領(lǐng)域，分析產(chǎn)出的子域定義結(jié)果也會(huì)跟業(yè)務(wù)能力非常接近。DDD把領(lǐng)域模型的邊界稱為邊界上下文（bounded context），邊界上下文包括實(shí)現(xiàn)這個(gè)模型的代碼集合。當(dāng)使用微服務(wù)架構(gòu)時(shí)，每一個(gè)邊界上下文對(duì)應(yīng)一個(gè)或者一組服務(wù)。即，我們可以通過(guò)DDD的方式定義子域，并把子域?qū)?yīng)為每個(gè)服務(wù)，這樣就完成了微服務(wù)架構(gòu)的設(shè)計(jì)。
還是以支付清算系統(tǒng)為例：
真實(shí)的情況是上述拆成的每個(gè)子域里面都會(huì)對(duì)應(yīng)一組服務(wù)，其實(shí)還可以按照實(shí)時(shí)交易和批處理交易拆分兩個(gè)域，每個(gè)域下面在按照功能維度拆成多個(gè)子域，每個(gè)子域下面一般都會(huì)對(duì)應(yīng)一組服務(wù)。可以簡(jiǎn)單的想下，日常開發(fā)中一個(gè)6-10的敏捷開發(fā)小組，都不會(huì)只維護(hù)一個(gè)應(yīng)用服務(wù)的，只要能控制住這個(gè)小組內(nèi)的變更不會(huì)超出自己負(fù)責(zé)的子域，影響到其他子域就可以。
拆分的指導(dǎo)原則
微服務(wù)的拆分沒有標(biāo)準(zhǔn)的答案但是可以根據(jù)行業(yè)經(jīng)驗(yàn)或者一些設(shè)計(jì)模式作為指導(dǎo)原則。
單一職責(zé)原則（Single Responsibility Principle）：改變一個(gè)類應(yīng)該只有一個(gè)理由。
我們?cè)谠O(shè)計(jì)微服務(wù)架構(gòu)時(shí)應(yīng)該遵循SRP原則，設(shè)計(jì)小的、內(nèi)聚的、僅僅含有單一職責(zé)的服務(wù)。這會(huì)縮小服務(wù)的大小提升它的穩(wěn)定性。
閉包原則（Common Closure Principle）：在包中包含的所有類應(yīng)該是對(duì)同類變化的一個(gè)集合，也就是說(shuō)，如果對(duì)包做出修改，需要調(diào)整的類應(yīng)該都在這個(gè)包之內(nèi)。
在微服務(wù)架構(gòu)下采用CCP原則，這樣我們能夠把根據(jù)同樣原因進(jìn)行變化的服務(wù)放在一個(gè)組件內(nèi)。這樣就可以控制服務(wù)的數(shù)量，當(dāng)需求發(fā)生變化時(shí)，變更和部署也更加容易。理想情況下，一個(gè)變更只影響一個(gè)團(tuán)隊(duì)和一個(gè)服務(wù)。CCP是解決分布式單體這種可怕的反模式的法寶。