幾乎每個工程團隊都考慮過在某個時候轉向微服務，它們在帶來好處的同時也讓團隊付出了代價。
在QCon倫敦大會上，Alexandra Noonan講述了Segment如何將單體分解成微服務，然後幾年後又迴歸單體架構。用Noonan的話說，“如果微服務的實現不正確，或者在沒有解決系統中一些根本缺陷的情況下，把微服務當創可貼使用，那麼你將無法進行新產品開發，因爲你將淹沒在巨大的複雜性中。”
微服務的引入首先是爲了解決Segment單體應用的有限故障隔離問題。然而，隨着公司的發展壯大，外部服務集成越來越多，支持微服務的運營開銷變得難以承受。在決定迴歸單體時，他們提出了一個新的架構，充分考慮了公司發展過程中的擴展之痛。儘管在模塊化、環境隔離和可見性方面做出了犧牲，但單體解決了運營開銷這個主要的問題，讓工程團隊可以重回新特性開發。
Noonan解釋了Segment架構發展的幾個關鍵點。在任何有經驗的軟件工程師看來，他們所面臨的問題以及當時所做的決定都不陌生。事後，我們才能清楚哪些決定本可以更好。Noonan通過一個時間軸逐個介紹了主要的決策點，並指出了系統架構每個狀態的優缺點。
2013年，Segment開始採用單體架構。它運營開銷比較低，但缺少環境隔離。Segment的功能基礎是集成來自許多不同提供商的數據。在單體中，到一個提供商目的地的連接有問題，就可能會對到所有提供商目的地的連接和整個系統產生不利影響。
遷移到微服務（每個目的地一個worker服務）解決了單體內部缺少隔離的問題。微服務還改進了整個系統的模塊化和可視性，使團隊可以輕鬆地查看隊列長度和識別有問題的worker。Noonan指出，可見性也可以構建在單體應用上，但在微服務中不需要付出額外的成本。然而，微服務帶來了更多的運營開銷和代碼重用相關的問題。
在2016年至2017年間，Segment的市場飛速增長，新增50多個目的地，平均每月新增3個。對於少數目的地worker來說，每個服務一個代碼庫是可管理的，但是隨着規模的擴大，這就變成了一個問題。對於所有worker中都有的類似行爲，他們創建了共享庫。然而，這產生了一個新的瓶頸，對共享代碼的更改可能會花掉開發人員一週的時間，這主要是由於測試限制。創建多個版本的共享庫可以加快代碼更改的實現速度，但是也會抵消共享代碼所帶來的好處。
Noonan指出了他們在微服務中採取一刀切方法的侷限性。因爲僅僅是添加新服務就需要大量的工作，所以其實現不是定製化的。儘管每個服務的負載和CPU資源需求有很大的不同，但所有服務都應用了同一個自動擴展規則。此外，對於真正的故障隔離，恰當的解決方案應該是每個客戶每個隊列一個微服務，但這將需要超過1萬個微服務。
2017年，在做了各種權衡之後，包括失去微服務所帶來的好處，他們重歸單體。新架構被命名爲Centrifuge，它能夠處理每天發送給數十個公共API的數十億條消息。現在，他們有一個代碼存儲庫，所有的目的地worker都使用共享庫的同一個版本。較大的worker能夠更好地處理峯值負載。新增目的地不會再增加運營開銷，而部署只需幾分鐘。對企業來說，最重要的是，他們能夠重新開始開發新產品。與微服務相比，新架構的模塊化、環境隔離和可見性降低了，但Segment的團隊認爲，上述所有這些好處值得他們這樣做。
這個演講聽起來就像是一名傳統的工程師加入了一個有着悠久歷史的項目。與會者對此展開了討論，有人說，“好啦，很明顯你不應該做他們做過的事”，類似這樣的短評遭到了經驗豐富的人士的反駁，他們認爲，Segment的大多數決定都是基於當時所能獲得的最佳信息做出的。其中一個重要的結論是，花幾天或幾周時間做更多的分析，可以避免出現需要幾年時間才能糾正的情況。
原文鏈接：
To Microservices and Back Again - Why Segment Went Back to a Monolith