近年來，我們發(fā)布了很多文章介紹企業(yè)向微服務(wù)遷移的成敗經(jīng)驗。最近，Segment的Alexandra Noonan寫了一篇文章，講述了他們從單體架構(gòu)遷移到微服務(wù)，之后又退回單體應(yīng)用的經(jīng)歷。文中Alexandra具體介紹了他們從原來的簡單架構(gòu)遷移到微服務(wù)的過程：

\\\

我們原來有個API負(fù)責(zé)攔截事件并將它們轉(zhuǎn)發(fā)到一個分布式的消息隊列中。這里的一個事件指的是由網(wǎng)頁或移動應(yīng)用生成的，包含用戶與用戶動作信息的JSON對象。當(dāng)隊列中的事件被消費(fèi)后，系統(tǒng)會檢查用戶設(shè)置來決定接收事件的目標(biāo)。（……）之后事件被逐個發(fā)送到每個目標(biāo)的API。這樣的流程很合理，因為開發(fā)者只需要將事件發(fā)送到Segment的API這一個目標(biāo)即可，無需創(chuàng)建幾十個集成。

\\\

如果事件交付失敗，就會被系統(tǒng)重新加入隊列，也就是說有時工作者進(jìn)程要一邊發(fā)送新的事件，一邊嘗試重新發(fā)送之前失敗的事件。這樣會導(dǎo)致所有目標(biāo)都出現(xiàn)延遲，Alexandra解釋說：

\\\

為解決最緊迫的阻塞問題，團(tuán)隊為每個目標(biāo)各創(chuàng)建了一個獨(dú)立的服務(wù)和隊列。這一新架構(gòu)包括一個新的路由進(jìn)程，它會接收入站事件并向每個選定的目標(biāo)分發(fā)一份該事件的拷貝。現(xiàn)在如果某個目標(biāo)出現(xiàn)問題，只有它自己的隊列會回溯，不會影響其它目標(biāo)。這一微服務(wù)化的架構(gòu)將各個目標(biāo)獨(dú)立開來，這樣當(dāng)某個目標(biāo)又出現(xiàn)常遇到的問題時就會非常有用。

\\\

文章之后寫到，Segment的開發(fā)團(tuán)隊一開始將所有代碼存放在一起，但這引發(fā)了許多問題：

\\\

最大的麻煩在于，只要一個測試崩潰，那么所有目標(biāo)的測試都會失敗。當(dāng)我們試圖部署一項改動時，我們必須先費(fèi)勁修復(fù)崩潰的測試，就算改動與一開始的變動毫無關(guān)聯(lián)也得這樣做。為了解決這個問題，我們決定將代碼拆分到每個目標(biāo)各自的存儲庫里。

\\\

這樣一來開發(fā)團(tuán)隊的靈活性的確改善了許多。然而隨著目標(biāo)數(shù)量的增加，存儲庫的數(shù)量也在同步增長。為了讓開發(fā)者免受維護(hù)這么多代碼庫的麻煩，Segment團(tuán)隊創(chuàng)建了許多共享庫，存放所有目標(biāo)通用的變換和功能。這組共享庫大大減輕了他們維護(hù)工作的壓力。但這個措施也有不太容易發(fā)現(xiàn)的負(fù)面影響：向共享庫更新并測試改動會花費(fèi)大量時間，還會增加破壞無關(guān)目標(biāo)的風(fēng)險。最后這些庫開始分裂為不同的版本，各自不統(tǒng)一，引發(fā)了之前沒有想到的一個問題：每個目標(biāo)的代碼庫都會依賴不同版本的共享庫。Alexandra承認(rèn)，他們當(dāng)時可以開發(fā)工具來自動將改動更新到這些庫中，但那時他們又遇到了這個微服務(wù)架構(gòu)產(chǎn)生的一些新問題。

\\\

新出現(xiàn)的問題是，每個服務(wù)都有自己的負(fù)載模式。有些服務(wù)一天處理幾個事件，有的服務(wù)每秒就能處理幾千個。如果目標(biāo)只處理很少的事件，工作者線程就得在出現(xiàn)負(fù)載問題時手動擴(kuò)展服務(wù)以滿足需求。

\\\

他們的系統(tǒng)集成了自動擴(kuò)展能力，但因為每個服務(wù)都需要指定CPU和內(nèi)存資源分配，調(diào)整自動擴(kuò)展的設(shè)置“更像玄學(xué)而非科學(xué)”。如前所述，每次存儲庫的數(shù)量增長時他們都要增加目標(biāo)，最后團(tuán)隊平均每月要增加三個目標(biāo)，當(dāng)然還要加上更多的隊列和服務(wù)。

\\\

2017年初，Segment的一個產(chǎn)品的核心部分使我們達(dá)到了峰值負(fù)載。當(dāng)時的情況下我們好像在從微服務(wù)的大樹上摔下來，一路撞上了所有的樹枝。我們這個小團(tuán)隊非但沒有提升效率，反而陷入了愈加復(fù)雜的泥潭。這個架構(gòu)的核心優(yōu)勢都成了負(fù)擔(dān)。我們的速度暴降，故障率卻在暴增。（……）于是，我們決定回退一步，重新考慮整個流程。

\\\

文章最后Noonan回顧了他們?nèi)绾螖[脫這個微服務(wù)架構(gòu)，其中他們還開發(fā)了Centrifuge來替換所有獨(dú)立的隊列，將所有事件都發(fā)送到一個單體服務(wù)上。他們還將所有目標(biāo)的代碼都遷移到一個存儲庫里，不過這一次新增了一些代碼管理的規(guī)則：所有目標(biāo)都要使用同一個版本，每次更新時同步更替到新版本。他們再也不用操心各個獨(dú)立版本之間的差異了，因為所有的目標(biāo)都在使用一個版本，以后也是如此。對于開發(fā)者來說，管理越來越多的目標(biāo)所花費(fèi)的時間減少了，風(fēng)險也降低了。

\\

Noonan的文章還寫了很多內(nèi)容，都是關(guān)于他們退回單體服務(wù)的經(jīng)歷。感興趣的讀者應(yīng)該去仔細(xì)讀一下，文章里面有很多架構(gòu)細(xì)節(jié)、關(guān)于存儲庫架構(gòu)的思考和建立彈性測試集的方法。最后，團(tuán)隊將回退的好處總結(jié)如下：

\\\

2016年時我們還在使用微服務(wù)架構(gòu)，我們?yōu)楣蚕韼鞄砹?2項改進(jìn)。而僅僅今年到現(xiàn)在我們就做出了46項改進(jìn)。過去半年來我們?yōu)閹鞄淼母倪M(jìn)比2016年全年都多。因為所有的目標(biāo)都處于同一服務(wù)內(nèi)，我們可以很好地搭配CPU密集型服務(wù)和內(nèi)存密集型服務(wù)，所以擴(kuò)展服務(wù)以滿足性能需求變得非常容易。更大的工作者池能負(fù)載更多內(nèi)容，所以我們不再需要將處理少量負(fù)載的目標(biāo)掛起到頁面了。

\\\

不過這個架構(gòu)回退過程也有一些負(fù)面影響，包括：隔離錯誤變得更困難（一個目標(biāo)的錯誤導(dǎo)致目標(biāo)崩潰，結(jié)果會傳染到所有目標(biāo)）；升級一個目標(biāo)的版本可能會破壞其它一些目標(biāo)，于是后者也需要升級。Noonan在文章最后寫下了誠懇的總結(jié)：

\\\

在微服務(wù)和單體架構(gòu)之間做選擇時，要注意它們各自都有自己需要考慮的因素。我們的架構(gòu)中有些部分是微服務(wù)表現(xiàn)更出色，但服務(wù)端的目標(biāo)遷移到微服務(wù)后的一系列麻煩是一個很好的教訓(xùn)，證明這一流行趨勢在某些情況下能對生產(chǎn)力和性能有多大負(fù)面影響。結(jié)果對于我們來說，單體架構(gòu)才是最終解決方案。

\\\

其實他們關(guān)于微服務(wù)的某些看法是很眼熟的。今年早些時候我們報道說，ThoughtWorks根據(jù)觀察認(rèn)為微服務(wù)尚未進(jìn)入普及周期。當(dāng)時的報道寫到：“主要原因之一是很多組織并沒有為微服務(wù)做好準(zhǔn)備，他們?nèi)鄙僖恍╆P(guān)于運(yùn)營和自動化的基礎(chǔ)實踐”。此外，Jan在另一篇文章中總結(jié)了多年來微服務(wù)遷移的失敗案例。Berico科技的首席軟件工程師Richard Clayton提到了他們當(dāng)時遇到的一個問題：

\\\

在不同服務(wù)之間共享通用功能代碼，以消滅各個服務(wù)中的重復(fù)功能的努力卻帶來了巨大的負(fù)面影響，最終導(dǎo)致了大規(guī)模回退。

\\\

回到原文，有很多關(guān)于這個話題的討論，比如Hacker News和Reddit上的這些；有些討論者認(rèn)為與微服務(wù)無關(guān)的一些因素可能導(dǎo)致了這些問題。比如，有些評論指出Noonan的文章并沒有引用CI，只有CD，起碼這是一個奇怪的組合。還有評論認(rèn)為不止微服務(wù)會引發(fā)這些問題，所有的分布式系統(tǒng)都是一個樣。關(guān)于這一點我們之前也提到過，有人使用SOA時有過類似的經(jīng)驗：

\\\

我曾在一個類似的代碼庫中工作過，那時他們管它叫SOA，云還沒開始流行。對服務(wù)的每次調(diào)用都會啟動一個完整的服務(wù)實例。我想我們應(yīng)該強(qiáng)制將網(wǎng)絡(luò)延遲規(guī)定為架構(gòu)設(shè)計的要素之一。

\\\

有趣的是很多討論串談到了微服務(wù)中數(shù)據(jù)上下文的問題。這個話題我們探討過很多次，這也是微服務(wù)反對者的主要論據(jù)之一。HackerNews的一條評論舉例說：

\\\

比這還糟呢。據(jù)我觀察多數(shù)微服務(wù)架構(gòu)根本就沒考慮一致性（“我們才不要亂七八糟的事務(wù)！”），盲目地隨大流還樂在其中。我搞不懂為啥子人們會覺得，把軟件模塊拆分開來然后用緩慢不可靠的網(wǎng)絡(luò)和弱爆的手動連接REST處理串起來，就能神奇地讓架構(gòu)面目一新哩？我覺得人們產(chǎn)生這種生產(chǎn)力幻覺的原因是：”我把這些都搞定啦，現(xiàn)在我也有一套’管它是什么即服務(wù)‘的先進(jìn)玩意兒嘍！看看那酷斃的數(shù)據(jù)面板上閃爍的小綠燈吧，我們可是為了它干了好幾個月呢！“

\\\

另外，為微服務(wù)定義域是多年來我們一直強(qiáng)調(diào)的微服務(wù)部署關(guān)鍵環(huán)節(jié)。有一篇PPT介紹了如何使用DDD解構(gòu)單體應(yīng)用，Reddit的一個討論串也談到了這一點：

\\\

建立一個出色的微服務(wù)架構(gòu)是很難的。我現(xiàn)在覺得關(guān)鍵在于恰當(dāng)?shù)胤指裟愕挠?#xff0c;當(dāng)系統(tǒng)進(jìn)化時持續(xù)關(guān)注這一層面。微服務(wù)并不像它的名字那樣，它不必非得那么小，但是要搭配適合這個架構(gòu)的元素。很多人的失敗正是因為忽視了這一點。

\\\

其他人怎么看？比如說，Segment的微服務(wù)架構(gòu)出現(xiàn)的問題能否用其它方式解決，無需退回單體應(yīng)用？或者一開始的單體架構(gòu)是否有辦法進(jìn)化得更好，解決原來的問題，而無需切換到微服務(wù)？

\\

查看英文原文：Why Segment Returned to a Monolith from Microservices? ?

\\

感謝冬雨對本文的審校。

總結(jié)

以上是生活随笔為你收集整理的为什么Segment会从微服务退回单体架构？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。