經(jīng)過一個(gè)月的準(zhǔn)備和調(diào)查，我們?nèi)∠诉w移，仍然使用單體模式。對我們而言，微服務(wù)不僅幫不上忙，反而會(huì)影響到開發(fā)計(jì)劃。

我們了解微服務(wù)大約是在一年前，但是很驚訝地發(fā)現(xiàn)它并不適合我們。本篇文章把我們的經(jīng)歷寫出來，可能會(huì)對大家有借鑒意義。

我們的應(yīng)用是整合外部現(xiàn)有產(chǎn)品和業(yè)務(wù)規(guī)則給用戶展現(xiàn)一個(gè)友好界面的 UI?？蛻羰且患?UWP App，后臺(tái)有相應(yīng)服務(wù)在第三方域和我們之間交換數(shù)據(jù)。

對第三方的依賴嚴(yán)重影響我們選擇微服務(wù)。例如，應(yīng)用經(jīng)常要在不同域之間轉(zhuǎn)換功能，使得第三方域看起來像是完全不同的一個(gè)域，如果在我們之間有一個(gè)單一服務(wù)情況還不算太糟。

然而，整個(gè)域交換在分解成多個(gè)微服務(wù)過程中就看起來很怪異了。

是我們的微服務(wù)跟第三方的分解不同嗎？我們復(fù)制了所有服務(wù)的前后端需求嗎？還是我們分解了自己的微服務(wù)，仍然需要一個(gè)微服務(wù)從第三方獲取信息？所有這些問題看起來都跟微服務(wù)指南相背離。

我們和第三方合作很緊密，經(jīng)常一起協(xié)作發(fā)布版本。微服務(wù)的好處在于每個(gè)團(tuán)隊(duì)都可以不受影響?yīng)毩l(fā)行服務(wù)，而跨公司合作則失去了這種好處。

微服務(wù)另外一個(gè)好處在于，每個(gè)團(tuán)隊(duì)只需要完整設(shè)計(jì)自己的業(yè)務(wù)問題。而我們，作為一個(gè)和第三方完全獨(dú)立的公司團(tuán)隊(duì)，這種重構(gòu)看起來不可行。

我們實(shí)在找不出應(yīng)該從哪個(gè)單體應(yīng)用下手。于是我們在域模型之間連線，以決定要?jiǎng)?chuàng)建哪些微服務(wù)。

然而，一旦這么開始做，發(fā)現(xiàn)很多共享業(yè)務(wù)邏輯影響著微服務(wù)域的劃分。如果將微服務(wù)劃分的更細(xì)小，只能帶來更多的耦合關(guān)系，到處都需要消息總線，消息可能會(huì)出現(xiàn)大爆炸。

原因在于我們的單體式應(yīng)用是為一個(gè)業(yè)務(wù)邏輯服務(wù)的。我們?yōu)橛脩舴奖銊?chuàng)建了跨域和組的很多工作流，本質(zhì)上，UI 在過去四年中就是將各種東西整合到了一起。

另外，我們還誤解了微服務(wù)如何被隔離，以及低估了服務(wù)之間正確邊界選擇的重要性。

唯一能做到的就是為了實(shí)現(xiàn)一個(gè)標(biāo)準(zhǔn)功能，從而需要將所有相關(guān)微服務(wù)同時(shí)升級，由此要求每個(gè)微服務(wù)都不能被某個(gè)單獨(dú)團(tuán)隊(duì)擁有。

我們大約有 12 個(gè)開發(fā)人員分布在兩個(gè)功能團(tuán)隊(duì)和一個(gè)支持團(tuán)隊(duì)。工作波動(dòng)性很大，沒有專職負(fù)責(zé)團(tuán)隊(duì)。所有團(tuán)隊(duì)同時(shí)接觸同一批代碼很正常，不能將某個(gè)微服務(wù)指定給一個(gè)團(tuán)隊(duì)。

考慮架構(gòu)時(shí)候一定要記得 Conway's Law，其意思是軟件架構(gòu)會(huì)模仿組織和團(tuán)隊(duì)架構(gòu)增長。

微服務(wù)架構(gòu)對于不同團(tuán)隊(duì)負(fù)責(zé)不同業(yè)務(wù)邏輯是比較有效的，然而，共享代碼功能的工作模式最好采用單體式架構(gòu)。

各種問題意味著至少六個(gè)月內(nèi)，需要在 IIS 內(nèi)并行運(yùn)行微服務(wù)和單體式應(yīng)用。

我們不會(huì)訪問與微服務(wù)相關(guān)的工具，如容器、Kubernetes、服務(wù)總線、API 網(wǎng)管等，也就意味著與其他微服務(wù)之間通訊有很大障礙。

因此，我們決定每個(gè)微服務(wù)都復(fù)制與存儲(chǔ)層轉(zhuǎn)換相關(guān)讀服務(wù)的共享邏輯。因?yàn)椴荒苷２鸱址?wù)，也就意味著必須承擔(dān)大量復(fù)制工作量。

例如，對于某個(gè)復(fù)雜而且基礎(chǔ)的業(yè)務(wù)邏輯，必須復(fù)制黏貼并維護(hù)至少 4 個(gè)計(jì)劃中的微服務(wù)。

開發(fā)團(tuán)隊(duì)只有六個(gè)月內(nèi)粗略的構(gòu)想，而且業(yè)務(wù)更改也很頻繁（業(yè)務(wù)更改需求也是司空見慣的事情），這些讓微服務(wù)化更加充滿不確定性，因?yàn)榧词乖诙唐谝矡o法預(yù)知會(huì)出現(xiàn)什么鏈接。

微服務(wù)之間的復(fù)雜性會(huì)增加嗎？花了幾個(gè)月分離的服務(wù)會(huì)回到過去嗎？盡管我們今年早些時(shí)候做過一些 PoC，但是因?yàn)闃I(yè)務(wù)需求的更改不得不放棄。

我們只有一個(gè)很窄的時(shí)間窗口，剛好能把單體式應(yīng)用分解成列出來的微服務(wù)，而且沒有冗余時(shí)間應(yīng)付可能出現(xiàn)的改變，也沒有 Plan B，我們被自己給卡住了。

因?yàn)槲覀冊谟?jì)劃階段就發(fā)現(xiàn)了很多問題和挑戰(zhàn)，更別說實(shí)施階段了，開發(fā)團(tuán)隊(duì)非常有壓力。

考慮到風(fēng)險(xiǎn)和時(shí)間壓力，而且架構(gòu)師和實(shí)施專家也都沒有任何特殊經(jīng)驗(yàn)，加上沒有標(biāo)準(zhǔn)工具能用，我們只能靠自己來實(shí)施，這些都更加惡化了情況。

和其他微服務(wù)大拿溝通后，他們也都發(fā)出了很多警告，并給出了不少以前并沒有的架構(gòu)建議，指出了我們在域模型之間畫線的順序。

到目前為止，由于時(shí)間緊任務(wù)重，我們的計(jì)劃包括了很多不同于標(biāo)準(zhǔn)微服務(wù)的妥協(xié)方案。

因?yàn)槿狈＜遥@看起來更像一條不歸之路，開發(fā)團(tuán)隊(duì)越來越焦慮。

一旦前方布滿了困難，就失去了目標(biāo)，我們暫停下來，意識到我們并沒有搞明白為什么要這樣做。

我們沒有列出痛點(diǎn)，而且不清楚這樣做是否可以解決痛點(diǎn)。更甚，微服務(wù)有可能會(huì)給我們帶來新的問題。

我們開始反思，我們從中會(huì)獲得什么好處？能解決什么問題？我們召開了更多會(huì)議討論它，但一直沒有明確的答案。

最后，我們發(fā)現(xiàn)在討論微服務(wù)過程中我們忽略了一個(gè)很重要的痛點(diǎn)，而且沒有足夠的時(shí)間來解決這個(gè)問題，也就是我們不能考慮微服務(wù)或者其他東西了。

這時(shí)候我們開始反思微服務(wù)一般意義上會(huì)帶來什么好處？

微服務(wù)使得團(tuán)隊(duì)可以控制全棧提供一個(gè)功能。這種區(qū)隔會(huì)減少不同團(tuán)隊(duì)之間協(xié)同的次數(shù)，互相不影響對方的工作。

單體式應(yīng)用中，團(tuán)隊(duì)可以專注于所有任務(wù)。而采用微服務(wù)后，則是某項(xiàng)業(yè)務(wù)流程的專家。

他們會(huì)理解自己區(qū)域內(nèi)的業(yè)務(wù)規(guī)則和需求，知道軟件棧如何搭建，當(dāng)發(fā)生改變時(shí)會(huì)非常有信心完成。

有了微服務(wù)，可以根據(jù)性能需求擴(kuò)展服務(wù)規(guī)模。而在單體式應(yīng)用中，盡管也可以水平擴(kuò)展服務(wù)，但是不能獨(dú)立擴(kuò)展單體應(yīng)用的模塊。

微服務(wù)粒度可以增加或者減少服務(wù)能力。也許當(dāng)發(fā)現(xiàn)性能問題時(shí)，可以參與其他工作，或者稍微喘口氣。

每個(gè)功能只需要修改單一微服務(wù)，而且可以不影響其他團(tuán)隊(duì)工作進(jìn)行回滾。另外微服務(wù)還可以減少單一錯(cuò)誤對整個(gè)系統(tǒng)的影響。

如果有一個(gè)擴(kuò)充系統(tǒng)的，每個(gè)發(fā)布都很花時(shí)間并且有風(fēng)險(xiǎn)，那么就需要大量工作處理每次發(fā)行時(shí)的問題。

微服務(wù)可以減少溝通時(shí)間和成本，團(tuán)隊(duì)可以各自確定合適時(shí)間。

團(tuán)隊(duì)依賴微服務(wù)可以選擇最佳技術(shù)方案。而單體式卻很難升級。

大型應(yīng)用升級都不是一件容易的事情。尤其是要在多個(gè)團(tuán)隊(duì)之間協(xié)作。相互隔離的微服務(wù)可以每次只升級一個(gè)服務(wù)，更容易控制風(fēng)險(xiǎn)。

微服務(wù)可以將頻繁變化和很少變化的服務(wù)分隔開，減少意外發(fā)生的風(fēng)險(xiǎn)。

小型化服務(wù)更易于理解，而且可以保持設(shè)計(jì)一致。對比來看，單體式應(yīng)用會(huì)因?yàn)椴煌瑘F(tuán)隊(duì)的意見不統(tǒng)一帶來不一致性。

微服務(wù)有很多優(yōu)勢。但是我們能從中獲得什么？

最終，對于無法改變或者妥協(xié)的架構(gòu)只能放棄這些優(yōu)勢。我們失去了微服務(wù)帶來的隔離性。與第三方的合作減弱了從服務(wù)不相關(guān)性中帶來的好處。

微服務(wù)也并不都是優(yōu)點(diǎn)，有一長串需要考慮的問題。

例如，日志，監(jiān)控，異常處理，容錯(cuò)，回滾，通訊，消息格式，容器，服務(wù)發(fā)現(xiàn)，備份，遙測，報(bào)警，跟蹤，工具，共享，文檔，擴(kuò)展，時(shí)區(qū)，階段，API 版本，網(wǎng)絡(luò)延遲，健康檢查，負(fù)載均衡，CDC測試，等等。

如果沒有微服務(wù)平臺(tái)，我們要自己面對所有上面列出來的問題。因?yàn)橛型袋c(diǎn)才要轉(zhuǎn)向微服務(wù)，但是不但沒法從中獲益，還要面對一堆轉(zhuǎn)向微服務(wù)帶來的問題，我們是何苦來呢？

好像“單體式”就意味著落后，“微服務(wù)”就意味著先進(jìn)。但是從開發(fā)團(tuán)隊(duì)來看，我們的單體式應(yīng)用運(yùn)行良好，基本沒有什么問題。

我們有很好的 CI/CD 配置，易于配置和回滾。分支和測試策略確保問題都被提前解決。

此時(shí)，似乎有些熟悉的感覺。在我以前從業(yè)經(jīng)驗(yàn)也有過類似的經(jīng)驗(yàn)，但從沒稱為微服務(wù)，盡管并不完全符合微服務(wù)的規(guī)則，但是的確解決了問題并帶來類似的好處。

5 個(gè)人的小團(tuán)隊(duì)帶領(lǐng) 200 人的開發(fā)者。這是一個(gè)巨大的 C# 應(yīng)用，大概 5% 的工作通過單體式共享，其他的共享兩節(jié)點(diǎn)服務(wù)。

我們也不喜歡單體式，工作起來很慢，編譯，測試，架構(gòu)改變的很快經(jīng)?？吹讲煌耐鲁霈F(xiàn)。

有時(shí)候因?yàn)橐粋€(gè)從未聽過的同事辭職了從而延遲了整個(gè)項(xiàng)目，技術(shù)更新因?yàn)橐驼麄€(gè)公司同步需要幾個(gè)月，Pull 申請需要整個(gè)系統(tǒng)批復(fù)需又要幾個(gè)星期。

同時(shí)，有兩個(gè)服務(wù)規(guī)模很小，我們可以很好地控制、部署、架構(gòu)它。一旦有性能問題，會(huì)懷疑實(shí)例數(shù)量直到解決底層問題，很少麻煩其他團(tuán)隊(duì)。

我們團(tuán)隊(duì)主導(dǎo)了前后端開發(fā)語言的選擇?？傊?，我們很專注于一個(gè)很窄的業(yè)務(wù)邏輯，每個(gè)人都成為了專家。

越了解微服務(wù)，越發(fā)現(xiàn)其不太適合我們。我們是不是太為了技術(shù)而技術(shù)了？

還有很多其他問題沒考慮：

• 有沒有專注業(yè)務(wù)邏輯的團(tuán)隊(duì)？

• 是否能夠清晰劃分域和微服務(wù)？

• 工作在所有團(tuán)隊(duì)之間是否平衡？

• 團(tuán)隊(duì)負(fù)載是否均衡？

• 單體式困難是否被分解到其他工作中？