微服務(wù)的戰(zhàn)爭(zhēng)：按什么維度拆分服務(wù)

微服務(wù)，這三個(gè)字正在席卷著目前的互聯(lián)網(wǎng)軟件行業(yè)，尤其在近幾年云原生迸發(fā)后，似乎人人都對(duì)微服務(wù)有了更廣泛的使用和理解，張口就是各種各樣的問號(hào)，有著強(qiáng)大的好奇心。

無獨(dú)有偶，我有一個(gè)朋友鯉魚在內(nèi)部微服務(wù)的早期（每個(gè)業(yè)務(wù)組起步）就經(jīng)常遇到下述的對(duì)話：

1. 張三：為什么要拆現(xiàn)在的代碼？

2. 鯉魚：因?yàn)?！@）&&#@！）&#！&）@！&！的原因。

3. 張三：那即將要做的 “微服務(wù)” 是按照什么維度去拆分的服務(wù)？

4. 鯉魚：常見的一般根據(jù) ！@#*@！#&！（@&！@）#@ 的方式來拆分。

5. 張三：照你這么說好像也不大對(duì)，我看每個(gè)業(yè)務(wù)組拆分的維度似乎都不大一樣？

6. 鯉魚：嗯，每個(gè)業(yè)務(wù)組還有自己的見解，不會(huì)完全相同。

7. 張三：。。。所以微服務(wù)的拆分維度到底是什么？

為什么想拆

為什么張三會(huì)有這個(gè)疑問呢，實(shí)際上是因?yàn)檠邪l(fā)內(nèi)部希望從原先的大單體，大倉(cāng)庫(kù)向微服務(wù)體系拆分轉(zhuǎn)換，其原先大單體倉(cāng)庫(kù)結(jié)構(gòu)，類 Monorepo：

但類 Monorepo 又有不少的問題，像是：

1. 單個(gè) Repo 體積過大：導(dǎo)致 Git 無法直接拉取。當(dāng)你設(shè)置完再拉取時(shí)，在網(wǎng)速慢時(shí)還能去泡杯咖啡，并且在開發(fā)機(jī)性能不佳的情況下，IDE 會(huì)比較卡，代碼運(yùn)行起來也慢。

2. 單個(gè) Repo 存在公共函數(shù)/SDK：在代碼倉(cāng)庫(kù)中，必然存在公共依賴。因此在解決代碼沖突時(shí)，若遺留了沖突符，且在動(dòng)態(tài)語言中，不涉及便運(yùn)行正常。但其實(shí)在上線后卻又影響到其他業(yè)務(wù)，可真是糟糕透頂，分分鐘被迫抱著事故。

3. 單個(gè) Repo 模塊職責(zé)/邊界不清：在實(shí)際的軟件開發(fā)中，涉及數(shù)十個(gè)業(yè)務(wù)組同時(shí)在一個(gè)大 Repo 下進(jìn)行開發(fā)，沒有強(qiáng)控邊界的情況下，往往會(huì)逐漸模糊，即使在設(shè)計(jì)時(shí)管得住自己，你也不一定能 100% 防止別人模糊你的邊界。

4. 單個(gè) Repo 包含了所有的源碼：出現(xiàn)公司源代碼泄露時(shí)，會(huì)導(dǎo)致整個(gè) Repo 外泄，相當(dāng)?shù)拇碳ず途哂薪逃饬x。因?yàn)殡m然開放和協(xié)同了，不屬于你們組的業(yè)務(wù)代碼你也有權(quán)限查看了。

當(dāng)然，Monorepo 是否又完全不可行呢？實(shí)際上國(guó)外 Google，F(xiàn)acebook，Twitter 等公司都有在使用 Monorepo，并取得了一定的收益。

其實(shí)做 Monorepo 是需要相應(yīng)的大量工具支撐，若單純只是一個(gè) Repo 塞多個(gè)模塊，基本都做不好，甚至引火燒身。還不如早早拆開，至少能確保各業(yè)務(wù)線服務(wù)的相對(duì)獨(dú)立性。

拆成什么樣

張三在明白了拆的原因后，就出現(xiàn)了第二個(gè)問題，那就是 “微服務(wù)” 要按照什么樣的維度去拆分服務(wù)？

張三公司內(nèi)部對(duì)于這塊的知識(shí)處于模糊不清的階段，因此需要進(jìn)行深入了解，便于后續(xù)的團(tuán)隊(duì)共識(shí)和方法論建立，理所當(dāng)然，十萬個(gè)為什么也就出現(xiàn)了。

大單體變獨(dú)立服務(wù)

最常見的拆分的方式是按照業(yè)務(wù)模塊進(jìn)行服務(wù)的拆解，像是前文所提到的業(yè)務(wù)模塊，在設(shè)計(jì)上邊界非常清晰，這種情況直接拆成各個(gè)服務(wù)就可以了：

而在拆分后，又會(huì)遇到一個(gè)新的問題，也就是張三問第三個(gè)問題 “每個(gè)業(yè)務(wù)組拆分的維度似乎都不大一樣？”。

因?yàn)樵趯?shí)際的執(zhí)行過程中，嚴(yán)謹(jǐn)一些會(huì)由 SM 與 RD 一同開會(huì)探討/規(guī)范初版的服務(wù)劃分，而在持續(xù)的快速的迭代中，往往新服務(wù)的拆分都是由一線 RD 親自操刀。

即使是架構(gòu)師親自操刀，在相對(duì)復(fù)雜的業(yè)務(wù)模型下，不同架構(gòu)師劃分出來的也有可能不完全一致，因此無論是哪種情況，你都會(huì)發(fā)現(xiàn)每個(gè)業(yè)務(wù)組拆分的維度多多少少都不一樣了，畢竟人與人的思想都是不一樣的，一千個(gè)人有一個(gè)千個(gè)哈姆雷特，因此張三的疑惑是正常的。

就像下圖，核心是定義一只魚，在不同人的眼中能演化出各種奇奇怪怪的魚：

大數(shù)據(jù)庫(kù)變獨(dú)立數(shù)據(jù)庫(kù)

在以前早期的大單體快速迭代中，往往是一個(gè)大數(shù)據(jù)庫(kù)包含所有的業(yè)務(wù)數(shù)據(jù)庫(kù)（甚至數(shù)據(jù)庫(kù)賬號(hào)都不分），這種時(shí)候就會(huì)帶來各種問題。

像是某一天，你所負(fù)責(zé)的業(yè)務(wù)模塊數(shù)據(jù)庫(kù)莫名其妙出現(xiàn)了一些奇奇怪怪的值，你可能就要抓破腦袋去各種代碼和 binlog 查了。更甚還有被網(wǎng)絡(luò)攻擊后，數(shù)據(jù)庫(kù)配置被獲取，直接跳板一拖直接整個(gè)脫褲，那可是糟糕透頂了。

因此在常見的應(yīng)用設(shè)計(jì)中，應(yīng)用程序在連接數(shù)據(jù)庫(kù)時(shí)會(huì)指定連接特定的域名（例如：eddycjy-user），方便未來遷移。并且每個(gè)業(yè)務(wù)服務(wù)分別給予獨(dú)立的數(shù)據(jù)庫(kù)只讀權(quán)限，進(jìn)行軟隔離。

而在業(yè)務(wù)量上來后，也會(huì)對(duì)業(yè)務(wù)數(shù)據(jù)庫(kù)進(jìn)行硬隔離，分配特定的 RDS 實(shí)例，就不會(huì)互相影響了。

環(huán)境隔離，獨(dú)立

在服務(wù)拆分后，大多會(huì)采取獨(dú)立部署的方式，將兩者之間的環(huán)境隔離開來，互不干擾，互不影響：

像在云原生中，常見于在 Kubernetes 將一個(gè)業(yè)務(wù)服務(wù)作為一個(gè) Service 部署發(fā)布，再根據(jù)實(shí)際的資源和調(diào)度情況進(jìn)行 Pod 的擴(kuò)縮容就可以了，資源也不會(huì)有直接干擾，且外部/內(nèi)部調(diào)用都是有統(tǒng)一的入口管理。

拆分的陣痛

業(yè)務(wù)接口聚合

在服務(wù)拆分的過程中，總是會(huì)有陣痛出現(xiàn)。

例如在服務(wù)需要獲取 “項(xiàng)目” 和 “房源” 信息時(shí)，到底是由誰來聚合這兩個(gè)服務(wù)的信息。是不是應(yīng)該由 BFF 來聚合：

或是應(yīng)該新寫一個(gè)膠水服務(wù)，用于聚合“項(xiàng)目” 和 “房源” 信息，保證其聚合性，減輕 BFF 的負(fù)擔(dān)：

又或是在量級(jí)越來越多的情況下，是不是要懷疑一下，這兩個(gè)服務(wù)拆分是不是有問題，“項(xiàng)目” 和 “房源” 在當(dāng)前業(yè)務(wù)模型下是否應(yīng)是一家：

顯然在鯉魚的經(jīng)歷中，這三種類型他都見過，不同的人總會(huì)在不同的思想和業(yè)務(wù)模型下選擇了不同的解決方案，還真的沒有絕對(duì)準(zhǔn)確的準(zhǔn)則。

分久必合，合久必分

隨著對(duì)服務(wù)化的進(jìn)程推進(jìn)，常見的會(huì)遇到兩種情況：

• 剛接觸服務(wù)化時(shí)：服務(wù)一個(gè)沒有，偶爾會(huì)有一個(gè)新的小業(yè)務(wù)，居然能拆出好好幾個(gè)微型服務(wù)，并揚(yáng)言要把剩余業(yè)務(wù)直接抄底重構(gòu)了，都拆掉，怎么勸都勸不回頭。

• 隨著業(yè)務(wù)的不斷發(fā)展：快速迭代，服務(wù)越來越多，工期壓縮，多個(gè) RD 交叉背好幾個(gè)業(yè)務(wù)服務(wù)，有點(diǎn)力不從心，發(fā)現(xiàn)拆的好像有點(diǎn)問題，從最新的情況來看，某某幾個(gè)服務(wù)似乎應(yīng)該合在一起。

• 業(yè)務(wù)階段性穩(wěn)定：。。。這，以前這塊好像有點(diǎn)問題，也太難拓展了，不應(yīng)該這么拆，誰調(diào)了我，我的上下游是誰。

大多數(shù)的情況都是第二和第三者，但在實(shí)際操作中也不見得會(huì)合并服務(wù)，大多數(shù) RD 會(huì)選擇吞進(jìn)心里，因?yàn)榉?wù)變遷所帶來的工期延長(zhǎng)和影響面無法直接預(yù)估（且存在歷史代碼，人員可能已經(jīng)離職多年）。即使是服務(wù)拓?fù)湟仓荒懿榭吹揭欢〞r(shí)間內(nèi)的服務(wù)調(diào)用，不會(huì)看到全部，因此上下游均無法 100% 確定。因此綜合來看，弊大于利。

在解決方案上，更多的是在下次新服務(wù)規(guī)劃時(shí)控制劃分變量（因?yàn)橐呀?jīng)有更成熟的經(jīng)驗(yàn)了）。

實(shí)在不行了，才有可能會(huì)新起聚合服務(wù)將原本的多個(gè)服務(wù)聚合，又或是采取版本號(hào)等方式進(jìn)行新老分流。甚至下定決心，螞蟻搬家，起新服務(wù)一個(gè)個(gè)板塊重構(gòu)，一個(gè)個(gè)挪，持續(xù)灰度，“徹底” 解決歷史包袱，完成轉(zhuǎn)化。

拆分準(zhǔn)則

張三又發(fā)話了，你說的我都懂，內(nèi)部微服務(wù)都發(fā)展好幾年了，作為已經(jīng)有豐富研發(fā)經(jīng)驗(yàn)的人，能不能釋出一套微服務(wù)拆分的準(zhǔn)則呢，否則每一個(gè)人都要經(jīng)歷一遍，怎么辦，有沒有什么基本準(zhǔn)則可以遵守呢，你看現(xiàn)在 DDD 那么火，能不能 DDD 一下，讓核心一致呢？

機(jī)智的鯉魚掐指一算，張三肯定想的是讓所有業(yè)務(wù)組的拆分，都能依據(jù)拆分的核心準(zhǔn)則走，實(shí)現(xiàn)你中有我，我中有你，看哪哪都有影子，核心不跑偏就行，建立一套完美的方法核心論：

這種建議右拐 Google “微服務(wù)如何拆分”，網(wǎng)上有超級(jí)多的指導(dǎo)資料，建議先培養(yǎng)在團(tuán)隊(duì)內(nèi)的共識(shí)。畢竟在每次拆服務(wù)時(shí)讓每一個(gè)人都對(duì)照著那一長(zhǎng)串的 “微服務(wù)拆分準(zhǔn)則” 是一件很不科學(xué)的事情，更多的工程師會(huì)依據(jù)自身的經(jīng)驗(yàn)進(jìn)行當(dāng)前其認(rèn)為的最合理拆解。

而準(zhǔn)則，你認(rèn)為的核心 A，在他人眼里并不一定是正確，他可能認(rèn)為是 B，因此在事業(yè)部，業(yè)務(wù)團(tuán)隊(duì)中達(dá)成共識(shí)并把拆分思想融合進(jìn)每位 RD 思想中，長(zhǎng)期的共同分析現(xiàn)在的拆分情況，且讓大家基本認(rèn)同才是最重要的。

同時(shí)讓全公司都依據(jù)一個(gè)準(zhǔn)則來做，在服務(wù)拆分這種無法利用工具流程強(qiáng)控制的情況，本身就是一個(gè)偽命題，更多的會(huì)是人與人之間的妥協(xié)，基本上會(huì)變成一個(gè)少有人看的 “指導(dǎo)” 文檔。

總結(jié)

在微服務(wù)中，服務(wù)的拆分總是能讓人如此細(xì)細(xì)品味，本文并不是具體的講某幾個(gè)知識(shí)點(diǎn)，更多的是闡述在服務(wù)化發(fā)展的歷程中的 “沖突點(diǎn)” 又或是 “矛盾點(diǎn)”，不同的人總有不一樣的理解，希望能夠給大家?guī)硪恍┧伎肌?/p>

且在閱讀微服務(wù)相關(guān)指南時(shí)，更建議看企業(yè)實(shí)踐后拆分的經(jīng)驗(yàn)分享，否則單純看 “指南” 沒有過多的意義，要看具體的公司/團(tuán)隊(duì)情況和業(yè)務(wù)模型。

推薦閱讀

Monorepo：

• Why Google Stores Billions of Lines of Code in a Single Repository

• Monorepos: Please don’t!

• Why might a project/company use a monorepo?

Microservices：

• Nginx Refactoring a Monolith into Microservices