在介紹業(yè)務(wù)場景之前播玖，我們先來談?wù)剬ξ⒎?wù)的一些理解椎工。

一、單體式架構(gòu) VS 微服務(wù)架構(gòu)

為了快速理解單體式架構(gòu)與微服務(wù)架構(gòu)之間的區(qū)別蜀踏，我們先來看一個(gè)新零售系統(tǒng)的例子维蒙。

比如門店（門店分為自營店和加盟店）想研發(fā)一款新零售系統(tǒng)進(jìn)行商品售賣，它需要包含訂單果覆、營銷颅痊、門店、商品局待、加盟商斑响、會(huì)員等功能模塊。

在搭建新零售系統(tǒng)架構(gòu)時(shí)钳榨，如果我們使用單體式架構(gòu)進(jìn)行設(shè)計(jì)舰罚，它的架構(gòu)圖如下所示：

file

從圖中我們發(fā)現(xiàn)，單體式架構(gòu)將所有模塊的代碼存放在一個(gè)應(yīng)用中薛耻，所有模塊的數(shù)據(jù)存放在一個(gè)數(shù)據(jù)庫中营罢。在這種架構(gòu)模式下，當(dāng)業(yè)務(wù)功能增加到一定程度昭卓，我們只要稍微有點(diǎn)小改動(dòng)愤钾，就有可能影響整個(gè)應(yīng)用的其他功能，這種事情在我們公司實(shí)在了發(fā)生太多次了候醒。

雖然每次不小心把公司系統(tǒng)弄崩后能颁，我們都會(huì)進(jìn)行復(fù)盤總結(jié)，后期需要 Code Review倒淫、合理設(shè)計(jì)伙菊、仔細(xì)評估風(fēng)險(xiǎn)、一起評審方案敌土，但是就算這么做了這種事情還是會(huì)發(fā)生镜硕。因此，隨著風(fēng)險(xiǎn)控制流程的復(fù)雜化返干，代碼發(fā)布的頻率也就越來越慢兴枯，最終導(dǎo)致系統(tǒng)迭代不了了，而別家公司交付新功能的效率卻是我們的 10 倍+矩欠。

面對這種情況财剖，我們必須把各個(gè)模塊的代碼進(jìn)行拆分悠夯，以免相互影響。于是我們把單體式架構(gòu)拆分為如下圖所示的微服務(wù)架構(gòu)躺坟。

file

在上面的架構(gòu)圖中沦补，我們發(fā)現(xiàn) 1 個(gè)應(yīng)用被拆分為了 6 個(gè)應(yīng)用，它們分別負(fù)責(zé)訂單咪橙、營銷夕膀、商品、門店美侦、加盟商产舞、會(huì)員等相關(guān)業(yè)務(wù)邏輯，且每個(gè)模塊的數(shù)據(jù)分別存放在不同數(shù)據(jù)庫中音榜。如果各個(gè)應(yīng)用之間彼此存在依賴關(guān)系庞瘸，我們可以通過接口捧弃、消息赠叼、共享緩存、數(shù)據(jù)庫同步等方式解決违霞。

二嘴办、微服務(wù)的好處

將單體式架構(gòu)遷移到微服務(wù)架構(gòu)后，確實(shí)為我們帶來了諸多便利买鸽，下面我們具體談?wù)勎⒎?wù)的好處有哪些涧郊。

1. 易于擴(kuò)展： 某個(gè)模塊的服務(wù)器處理能力不足時(shí)，我們在那個(gè)模塊所處應(yīng)用的服務(wù)器中增加節(jié)點(diǎn)就行眼五。
2. 發(fā)布簡單： 在單體式架構(gòu)中妆艘，因?yàn)樗写a存放在一個(gè)應(yīng)用中，所以每次發(fā)布代碼時(shí)看幼，我們需要連帶整個(gè)應(yīng)用一起發(fā)布批旺，使得整個(gè)團(tuán)隊(duì)人員都得配合集成測試、統(tǒng)一協(xié)調(diào)排期诵姜。但是遷移到微服務(wù)架構(gòu)后汽煮，我們只需要保證對外契約不變就行，發(fā)布過程變得特別簡單了棚唆。
3. 技術(shù)異構(gòu)： 因?yàn)楦鱾€(gè)服務(wù)之間相互獨(dú)立暇赤、互不影響，所以我們只需要保證外部契約（一般指接口）不變即可宵凌，而內(nèi)部想使用什么語言或框架都行鞋囊。
4. 便于重構(gòu)： 在單體式架構(gòu)中，因?yàn)橄到y(tǒng)重構(gòu)的影響面較大瞎惫，所以在做任何改動(dòng)時(shí)我們都要小心翼翼溜腐，以至于我們不敢嘗試大的重構(gòu)或優(yōu)化坯门，最終出現(xiàn)代碼加速腐爛的情況。但是在微服務(wù)架構(gòu)中逗扒，因?yàn)槲覀儼涯K間的影響進(jìn)行了隔離古戴，所以大大增加了重構(gòu)的靈活性。

三矩肩、微服務(wù)的痛

在產(chǎn)品研發(fā)過程中现恼，我認(rèn)為引入一個(gè)技術(shù)解決一個(gè)業(yè)務(wù)問題并不難，難的是我們能否合理評估技術(shù)風(fēng)險(xiǎn)黍檩，這個(gè)觀點(diǎn)對微服務(wù)同樣適用叉袍。因此，我將通過三篇文章來聊聊微服務(wù)會(huì)帶來哪些問題刽酱，這部分內(nèi)容不管是在面試中還是日常技術(shù)設(shè)計(jì)中喳逛，對我們的幫助都會(huì)非常大。

這一篇文章我們主要聊聊微服務(wù)的兩個(gè)痛點(diǎn)棵里，其他的痛點(diǎn)在后面的文章詳細(xì)介紹润文。

（一）微服務(wù)職責(zé)劃分

微服務(wù)的難點(diǎn)在于無法對一些特定職責(zé)進(jìn)行清晰劃分，比如這個(gè)特定職責(zé)它應(yīng)該歸屬于服務(wù) A 還是服務(wù) B殿怜？為了方便理解這部分內(nèi)容典蝌，下面我們舉幾個(gè)例子說明下。

• 比如一個(gè)能根據(jù)商品 ID 找出商品信息的接口头谜，我們把它放在商品服務(wù)中就行骏掀。再比如單個(gè)用戶的所有訂單，我們把它放在訂單服務(wù)中就行柱告。
• 業(yè)務(wù)邏輯服務(wù)歸屬與業(yè)務(wù)人員的劃分可能存在關(guān)系截驮，比如每個(gè)商品在每個(gè)門店的庫存應(yīng)該放在商品服務(wù)還是門店服務(wù)呢？因?yàn)楦髯蚤T店的商品庫存由各自門店的運(yùn)營人員管理际度，最終我們決定把它放在門店系統(tǒng)中葵袭。
• 業(yè)務(wù)邏輯服務(wù)歸屬與產(chǎn)品人員的劃分可能存在關(guān)系，比如業(yè)務(wù)部門提了一個(gè)新需求甲脏，需要我們設(shè)計(jì)一個(gè)能對商品進(jìn)行相關(guān)設(shè)置的功能眶熬，使得某些門店只能賣某些商品。此時(shí)這個(gè)功能應(yīng)該放門店服務(wù)還是放商品服務(wù)呢块请？這就需要看這個(gè)功能由哪條業(yè)務(wù)線的產(chǎn)品負(fù)責(zé)人負(fù)責(zé)了娜氏，比如由商品系統(tǒng)的產(chǎn)品經(jīng)理負(fù)責(zé)，我們就把它放商品服務(wù)中就行墩新；比如由門店的產(chǎn)品經(jīng)理負(fù)責(zé)贸弥，把它放門店服務(wù)中就行。
• 業(yè)務(wù)邏輯服務(wù)歸屬與工期可能存在關(guān)系海渊，緊接著上面的例子——實(shí)現(xiàn)某些門店只能賣某些商品的需求绵疲，最終我們依據(jù) DDD 中的相關(guān)原則定了一個(gè)劃分邏輯哲鸳，特定門店的特定商品的上架功能放在門店服務(wù)中，因?yàn)樘囟ㄉ唐酚砷T店的運(yùn)營人員負(fù)責(zé)上架盔憨。但是這種劃分邏輯會(huì)出現(xiàn)這么一個(gè)情況：比如門店服務(wù)的開發(fā)人員很忙徙菠，沒空接這個(gè)需求，而商品服務(wù)的開發(fā)人員剛好有空郁岩，但他們對門店服務(wù)的邏輯不了解婿奔。于是，商品的開發(fā)人員提議问慎，如果我們想在 2 周內(nèi)實(shí)現(xiàn)上線這個(gè)需求萍摊，則必須把這個(gè)功能放在商品服務(wù)中。這種方案看起來比較詭異如叼，不過最終他們確實(shí)把這個(gè)功能放在了商品服務(wù)中冰木，因?yàn)樵賰?yōu)雅的設(shè)計(jì)也抵不過業(yè)務(wù)部門要求的上線壓力。
• 業(yè)務(wù)邏輯服務(wù)歸屬還與組織架構(gòu)可能存在關(guān)系笼恰，通過康威定律我們就能很快明白踊沸。

Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. It states that. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

康威是個(gè)程序員，他在 1967 年提出：設(shè)計(jì)系統(tǒng)的組織在設(shè)計(jì)系統(tǒng)時(shí)挖腰，會(huì)設(shè)計(jì)出基于這些組織的溝通結(jié)構(gòu)的系統(tǒng)雕沿。

關(guān)于微服務(wù)職責(zé)劃分的痛，通過前面幾個(gè)例子的介紹猴仑，大家應(yīng)該隱隱約約有所感覺了，接下來我們再說一個(gè)進(jìn)銷存供應(yīng)鏈系統(tǒng)的例子肥哎，讓大家有更深刻的體會(huì)辽俗。

這里的進(jìn)指的是供應(yīng)商的采購，銷指的是門店的銷售單篡诽，存指的是一些中央倉庫的庫存崖飘，且進(jìn)銷存供應(yīng)鏈系統(tǒng)與新零售系統(tǒng)之間緊密結(jié)合，對應(yīng)的架構(gòu)圖如下所示杈女。

file

在這個(gè)架構(gòu)中朱浴，原本門店的商品庫存是由門店運(yùn)營人員（即新零售業(yè)務(wù)）負(fù)責(zé)，中央倉庫庫存由供應(yīng)鏈人員管理达椰。后來翰蠢，不知什么原因領(lǐng)導(dǎo)要求更改供應(yīng)鏈總監(jiān)職責(zé)，此時(shí)供應(yīng)鏈總監(jiān)需要同時(shí)負(fù)責(zé)門店商品庫存+中央倉庫庫存啰劲。

我們先來看看原職責(zé)劃分情況梁沧，對應(yīng)關(guān)系如下圖所示。

file

在圖中我們可以看到蝇裤，在原有的組織架構(gòu)中廷支，新零售業(yè)務(wù)的產(chǎn)研只對接新零售業(yè)務(wù)频鉴，供應(yīng)鏈業(yè)務(wù)的產(chǎn)研只對接供應(yīng)鏈業(yè)務(wù)。現(xiàn)如今恋拍，門店庫存管理職責(zé)需要?jiǎng)澐值焦?yīng)鏈業(yè)務(wù)中垛孔，也就是說新零售業(yè)務(wù)的產(chǎn)研不再負(fù)責(zé)這個(gè)需求，而是交由供應(yīng)鏈業(yè)務(wù)的產(chǎn)研負(fù)責(zé)了施敢。此時(shí)供應(yīng)鏈業(yè)務(wù)的產(chǎn)研會(huì)把門店庫存積極地搬運(yùn)到供應(yīng)鏈的庫存管理中似炎，因?yàn)殚T店庫存管理好了，供應(yīng)鏈業(yè)務(wù)方的績效也就好了悯姊，產(chǎn)研的績效也就高了吵血，年終獎(jiǎng)也就更多了盐肃。

因此，在現(xiàn)實(shí)場景中，微服務(wù)職責(zé)的劃分會(huì)受太多人為因素的影響仗阅，我們也就能理解為什么市面上關(guān)于服務(wù)職責(zé)劃分原則的相關(guān)資料太少了。

（二）微服務(wù)粒度拆分

在我所經(jīng)歷的企業(yè)中嗡害，發(fā)現(xiàn)大家都會(huì)遇到微服務(wù)太多的情況奴拦。因此，我們有必要通過一個(gè)加盟商的例子把服務(wù)粒度的內(nèi)容詳細(xì)介紹下垃僚。

還是以上面的新零售系統(tǒng)為例集绰，剛開始系統(tǒng)只有登錄和信息管理功能，我們把這些功能存放在一個(gè)服務(wù)中就行谆棺，實(shí)現(xiàn)起來比較簡單栽燕。隨著加盟商的加入，因?yàn)榧用松虦?zhǔn)入改淑、開店碍岔、退出都涉及費(fèi)用問題，因此我們又需要增加財(cái)務(wù)功能（如應(yīng)收朵夏、應(yīng)付蔼啦、實(shí)收、實(shí)付仰猖、退款捏肢、對賬等）。

隨著業(yè)務(wù)的逐步開展饥侵，我們又需要增加加盟商員工管理（員工管理鸵赫、部門管理、權(quán)限管理）返點(diǎn)爆捞、加盟商子門店管理等功能奉瘤，而此時(shí)的加盟商管理系統(tǒng)只有一個(gè)服務(wù)，你覺得合適嗎？答案肯定是不合適盗温。那微服務(wù)的粒度到底拆分多少比較合適呢藕赞？比如什么時(shí)候拆分加盟商服務(wù)比較合適？做加盟商的財(cái)務(wù)功能時(shí)還是加盟商的員工管理功能時(shí)卖局？做加盟商的返點(diǎn)功能時(shí)還是加盟商的子門店管理功能時(shí)斧蜕？

一般來說，在設(shè)計(jì)新功能之前砚偶，我們會(huì)遵循一個(gè)大致原則：根據(jù)新的微服務(wù)的大小批销，安排 3-4 人設(shè)計(jì)即可。

但是當(dāng)一個(gè)微服務(wù)設(shè)計(jì)出來后染坯，它的改動(dòng)成本一般不高均芽，除非實(shí)現(xiàn)大規(guī)模重構(gòu)，為了防止開發(fā)人員出現(xiàn)閑置的情況单鹿，公司會(huì)安排他們設(shè)計(jì)新的功能掀宋。而設(shè)計(jì)新功能時(shí)，開發(fā)人員傾向于將獨(dú)立的功能存放在新的服務(wù)中仲锄，導(dǎo)致加盟商的財(cái)務(wù)劲妙、員工管理及返點(diǎn)功能都被獨(dú)立出來了。為了避免這種情況的發(fā)生儒喊，因此镣奋，在對微服務(wù)粒度進(jìn)行拆分時(shí)，我們還需要考慮另外一個(gè)因素——績效怀愧。

大家都知道侨颈，開發(fā)人員的績效很難實(shí)現(xiàn)量化，而微服務(wù)數(shù)可謂是一個(gè)難得的可量化指標(biāo)掸驱。在規(guī)章制度上肛搬，雖然我們不會(huì)把微服務(wù)數(shù)列為一個(gè) KPI（這樣微服務(wù)數(shù)絕對會(huì)爆發(fā)），但是開發(fā)人員在闡述個(gè)人工作量時(shí)偶爾還是會(huì)提微服務(wù)數(shù)毕贼，如果其他同事聽后開始留心，潛意識里也喜歡上做微服務(wù)蛤奢，隨著時(shí)間的推移鬼癣，微服務(wù)就會(huì)越來越多，甚至出現(xiàn)人均 5 個(gè)服務(wù)數(shù)的奇葩情況啤贩。

說到這你可能想說待秃，會(huì)不會(huì)是你們的微服務(wù)分得太細(xì)了？說得太對了痹屹，我們也是這樣認(rèn)為的章郁，于是開始控制服務(wù)數(shù)，這種方式確實(shí)起到了一定的效果。

那服務(wù)的粒度大小控制在什么范圍比較合適呢暖庄？我只能說沒有確切的答案聊替，需要根據(jù)實(shí)際業(yè)務(wù)情況來定。

四培廓、總結(jié)

以上介紹的微服務(wù)的痛點(diǎn)是根據(jù)實(shí)際工作經(jīng)歷總結(jié)出來的惹悄，因此為了便于理解，每個(gè)痛點(diǎn)都會(huì)舉一個(gè)實(shí)際的例子進(jìn)行說明肩钠。其他的痛點(diǎn)我們后面繼續(xù)聊泣港。

感興趣的朋友歡迎關(guān)注微信公眾號：服務(wù)端技術(shù)精選

個(gè)人博客：http://jiangyi.cool