最近我們開發(fā)團隊在開發(fā)計劃中有一個小停頓，技術部門認為現(xiàn)在是將應用從單體架構遷移到微服務的最佳時機。

[[313279]] 

圖片來自 Pexels

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

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

發(fā)現(xiàn)問題以及早期妥協(xié)

我們嚴重依賴第三方

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

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

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

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

我們和第三方合作很緊密，經(jīng)常一起協(xié)作發(fā)布版本。微服務的好處在于每個團隊都可以不受影響獨立發(fā)行服務，而跨公司合作則失去了這種好處。

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

我們不能有效分離微服務

我們實在找不出應該從哪個單體應用下手。于是我們在域模型之間連線，以決定要創(chuàng)建哪些微服務。

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

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

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

唯一能做到的就是為了實現(xiàn)一個標準功能，從而需要將所有相關微服務同時升級，由此要求每個微服務都不能被某個單獨團隊擁有。

共享微服務

我們大約有 12 個開發(fā)人員分布在兩個功能團隊和一個支持團隊。工作波動性很大，沒有專職負責團隊。所有團隊同時接觸同一批代碼很正常，不能將某個微服務指定給一個團隊。

考慮架構時候一定要記得 Conway's Law，其意思是軟件架構會模仿組織和團隊架構增長。

微服務架構對于不同團隊負責不同業(yè)務邏輯是比較有效的，然而，共享代碼功能的工作模式最好采用單體式架構。

平臺并沒有準備好

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

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

因此，我們決定每個微服務都復制與存儲層轉換相關讀服務的共享邏輯。因為不能正常拆分服務，也就意味著必須承擔大量復制工作量。

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

沒有未來清晰圖景

開發(fā)團隊只有六個月內(nèi)粗略的構想，而且業(yè)務更改也很頻繁(業(yè)務更改需求也是司空見慣的事情)，這些讓微服務化更加充滿不確定性，因為即使在短期也無法預知會出現(xiàn)什么鏈接。

微服務之間的復雜性會增加嗎?花了幾個月分離的服務會回到過去嗎?盡管我們今年早些時候做過一些 PoC，但是因為業(yè)務需求的更改不得不放棄。

架構緊耦合

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

因為我們在計劃階段就發(fā)現(xiàn)了很多問題和挑戰(zhàn)，更別說實施階段了，開發(fā)團隊非常有壓力。

缺乏經(jīng)驗

考慮到風險和時間壓力，而且架構師和實施專家也都沒有任何特殊經(jīng)驗，加上沒有標準工具能用，我們只能靠自己來實施，這些都更加惡化了情況。

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

到目前為止，由于時間緊任務重，我們的計劃包括了很多不同于標準微服務的妥協(xié)方案。

因為缺乏專家，這看起來更像一條不歸之路，開發(fā)團隊越來越焦慮。

再次拷問我們的目標

是否解決了痛點

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

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

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

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

潛在收益是什么

這時候我們開始反思微服務一般意義上會帶來什么好處?

自治

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

使團隊更加專注

單體式應用中，團隊可以專注于所有任務。而采用微服務后，則是某項業(yè)務流程的專家。

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

易于擴展

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

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

易于回滾

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

易于迭代

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

微服務可以減少溝通時間和成本，團隊可以各自確定合適時間。

采用最佳技術

團隊依賴微服務可以選擇最佳技術方案。而單體式卻很難升級。

易于升級

大型應用升級都不是一件容易的事情。尤其是要在多個團隊之間協(xié)作。相互隔離的微服務可以每次只升級一個服務，更容易控制風險。

風險保護

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

粒度減小

小型化服務更易于理解，而且可以保持設計一致。對比來看，單體式應用會因為不同團隊的意見不統(tǒng)一帶來不一致性。

優(yōu)勢匯總

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

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

權衡

大炮打蚊子

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

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

如果沒有微服務平臺，我們要自己面對所有上面列出來的問題。因為有痛點才要轉向微服務，但是不但沒法從中獲益，還要面對一堆轉向微服務帶來的問題，我們是何苦來呢?

微服務只是名義

下圖是我們現(xiàn)在單體式應用和微服務的對比。架構上來看，新架構很像單體式，各個組件還是緊耦合，也許我們只是用了微服務的標簽。

 

單體式一定很差嗎

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

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

似曾相識

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

5 個人的小團隊帶領 200 人的開發(fā)者。這是一個巨大的 C# 應用，大概 5% 的工作通過單體式共享，其他的共享兩節(jié)點服務。

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

有時候因為一個從未聽過的同事辭職了從而延遲了整個項目，技術更新因為要和整個公司同步需要幾個月，Pull 申請需要整個系統(tǒng)批復需又要幾個星期。

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

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

技術之外

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

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

• 有沒有專注業(yè)務邏輯的團隊?
• 是否能夠清晰劃分域和微服務?
• 工作在所有團隊之間是否平衡?
• 團隊負載是否均衡?
• 單體式困難是否被分解到其他工作中?

復盤

遷移到微服務是個大爆炸，大家都停下功能開始想如何分解單體引用，即使前提還不具備。

后來證明這不是個好方法，有可能還是個倒退。首先創(chuàng)建所有微服務，然后設置架構并忽略了團隊的架構。

假如我們開始時考慮團隊和業(yè)務邏輯結合，等架構成熟，并等微服務自然顯現(xiàn)，會更好。而且新的業(yè)務需求出現(xiàn)，可以直接被放在一個新服務中。

強制上微服務，也意味著需要選擇每個微服務的大小。一些文章建議每個微服務至少按照一個團隊的支撐設計。其他的則建議越小越好，一旦需要更改，很短時間內(nèi)就可以完成。

領導層決定按照工作域劃分，如果需要再細分。這個決定導致上面出現(xiàn)的問題。后來復盤時發(fā)現(xiàn)如果等待微服務自然出現(xiàn)，其大小其實最合適。

取消

隨著預定時間一天天臨近，我們團隊持續(xù)發(fā)現(xiàn)越來越多的問題。上線四天后，仍然看不到預期的效果。于是召開了一次會議，最終取消了微服務計劃。

取代行動

微服務的熱度消散，也就意味著我們沒有做好必要的調(diào)研。拋棄了微服務后，我們也有精力去調(diào)研其他方案。

最后，我們決定在單體應用內(nèi)部劃分成不同項目，更好地劃分了架構和耦合關系。

另外這種架構使得域模型更加清晰，使得未來考慮微服務更容易。

結論

領導層上微服務的倉促決定并沒考慮清楚挑戰(zhàn)和目前狀態(tài)。評估后，發(fā)現(xiàn)微服務并不適合我們，需要更多的妥協(xié)。

這些折衷方案把微服務帶來的好處都抵消掉了。微服務并不考慮非技術因素，例如團隊結構和工作量。

幾個月調(diào)研后，我們拋棄了微服務嘗試，決定對已有的單體式應用做一些更適合的微調(diào)。