0 前言
除非你一直生活在岩石下面，否則你可能已經知道微服務是當今流行的架構趨勢。與這一趨勢一同成長，Segment早期就採用了這種最佳實踐，這在某些情況下對我們很有幫助，但正如你將很快了解到的，在其他情況下則並非如此。
簡單來說，微服務是一種面向服務的軟體架構，其中伺服器端應用程式透過組合許多單一用途、低開銷的網路服務構建。微服務的好處包括:
- 提高模組化
- 減少測試負擔
- 改進功能組合
- 環境隔離
- 開發團隊自治
與之相對的是單體架構，在單體架構中，大量功能存在於一個服務中，該服務作為一個單元進行測試、部署和擴充套件。
2017年初，我們的核心產品之一達到了一個臨界點。看起來我們從微服務樹上掉下來，碰到了每一個分支。小團隊不僅沒能更快推進工作，反而陷入不斷增加的複雜性。微服務架構本質優勢變成負擔。開發速度急劇下降，缺陷率迅速上升。
最終，團隊發現自己無法取得進展，三名全職工程師大部分時間都在維持系統正常執行。須做出改變。本文講述了我們如何退一步，採用一種更符合我們產品需求和團隊需求的方法。
1 微服務的優勢
Segment的客戶資料基礎設施每秒處理數十萬個事件並將其轉發到合作伙伴的API，稱之為伺服器端目的地。有超過一百種這樣的目的地，如Google Analytics、Optimizely或自定義webhook。
幾年前，當產品首次推出時，架構非常簡單。有一個API接收事件並將其轉發到一個分散式MQ。事件在這裡指由Web或APP生成的JSON物件，包含有關使用者及其行為的資訊。
1.1 一個示例負載
當事件從佇列中被消費時，會檢查客戶管理的設定以決定哪些目的地應接收該事件。然後，事件依次傳送到每個目的地的API，這對開發人員很有用，因為他們只需將事件傳送到一個端點，即Segment的API，而無需構建多個整合。Segment負責向每個目的地端點發出請求。
若對某個目的地的請求失敗，有時會嘗試在稍後時間再次傳送該事件。有些失敗可重試，而有些不行：
- 可重試的錯誤是那些可能被目的地接受的錯誤，如HTTP 500、速率限制和超時
- 不可重試的錯誤是那些我們確定目的地永遠不會接受的請求，如無效憑據或缺少必填欄位的請求
此時，一個佇列包含最新的事件及那些可能已重試多次的事件，涉及所有目的地，導致隊首阻塞。即若一個目的地變慢或當機，重試請求會充斥佇列，導致所有目的地的延遲。
假設目的地X出現臨時問題，每個請求都會超時。這不僅會建立一個大的請求積壓，還會導致每個失敗的事件在佇列中重試。雖然我們的系統會自動擴充套件以應對增加的負載，但佇列深度的突然增加會超出擴充套件能力，導致最新事件的延遲。所有目的地的交付時間都增加，因為目的地X出現短暫故障。客戶依賴於交付的及時性，所以我們不能在管道的任何地方容忍等待時間的增加。
為解決隊首阻塞，團隊為每個目的地建立一個單獨的服務和佇列。這種新架構包括一個額外的路由程序，該程序接收入站事件並將事件的副本分發到每個選定的目的地。
現在，若一個目的地異常，只有其佇列會積壓，其他目的地不影響。這樣的微服務架構將各目的地隔離，這在一個目的地頻繁出現問題時尤其重要。
2 獨立程式碼庫的理由
每個目的地API使用不同的請求格式，需要自定義程式碼將事件轉換為匹配的格式。一個基本的例子是目的地X需要將生日傳送為traits.dob，而我們的API接受traits.birthday。目的地X的轉換程式碼可能如下：
許多現代目的地端點採用Segment的請求格式，使得某些轉換相對簡單。然而，這些轉換可能非常複雜，具體取決於目的地API的結構。如一些較舊且龐大的目的地，我們需要將值插入手工製作的XML負載。
最初，當目的地被分成單獨服務時，所有程式碼都在一個程式碼庫。一個巨大挫折點是單個失敗的測試會導致所有目的地的測試失敗。當我們想部署一個更改時，即使這些更改與初始更改無關，也須花時間修復失敗的測試。為此，決定將每個目的地的程式碼拆分到各自程式碼庫。所有目的地已分離成各自的服務，所以這一轉變很自然。
拆分成獨立的程式碼庫使我們能夠輕鬆地隔離目的地的測試套件。這種隔離使開發團隊在維護目的地時能夠快速行動。
3 擴充套件微服務和程式碼庫
隨時間推移，新增50多個新目的地，意味著50多個新程式碼庫。為減輕開發和維護這些程式碼庫的負擔，建立共享庫，以便在所有目的地之間簡化常見的轉換和功能，如HTTP請求處理。
如若想從事件獲取使用者的名字，可在任何目的地的程式碼中呼叫event.name()。共享庫會檢查事件中的屬性鍵name和Name。若這些不存在，它會檢查firstName、first_name和FirstName。對於姓氏，它會以相同方式檢查這些屬性，並將兩個名字組合形成全名。
共享庫使構建新目的地變得快捷。統一的一組共享功能帶來的熟悉感使維護變得不再頭疼。
3.1 新問題開始出現
測試和部署這些共享庫的更改影響了我們所有的目的地。維護這些程式碼庫需要大量精力。改進時，需要測試和部署幾十個服務，這是高風險任務。時間緊迫時，工程師們只會在單個目的地的程式碼庫中包含更新版本的共享庫。
隨時間推移，這些共享庫的版本在不同目的地的程式碼庫之間開始分化。我們曾在減少定製化方面的巨大優勢開始逆轉。最終，所有目的地都在使用不同版本的共享庫。本可構建工具來自動化部署更改，但此時，不僅開發人員的生產力受到了影響，還遇到微服務架構其他問題。
另一個問題是
3.2 每個服務都有不同負載模式
一些服務每天處理少量事件，而其他服務每秒處理數千個事件。對於處理少量事件的目的地，每當負載出現意外峰值時，操作員必須手動擴充套件服務。
雖然有了自動擴充套件，但每個服務所需的CPU和記憶體資源不同，使得自動擴充套件配置更像是一門藝術而非科學。
隨著目的地數量迅增，團隊平均每月增加三個目的地，這意味著更多程式碼庫、更多佇列和更多服務。微服務架構導致操作開銷與增加的目的地數量成線性增長。因此，決定退一步，重新思考整個管道。
4 放棄微服務和佇列
計劃列表上的第一項是將現在超過140個服務合併為一個服務。管理所有這些服務的開銷對我們的團隊來說是一個巨大負擔。我們的工程師經常因為負載峰值被叫醒，導致無法安睡。
然而，當時的架構使得遷移到單一服務變得具有挑戰性。每個目的地都有一個單獨的佇列和服務。這意味著我們必須重構每個佇列中的訊息處理邏輯。我們決定從零開始構建一個新的目的地系統。
目標是建立一個單一的、共享的佇列，所有事件在這裡排隊，並由一個共享的目的地處理器進行處理。新架構避免了我們在微服務架構中遇到的隊首阻塞和佇列深度增加的問題。
然而，當時的架構使得轉向單一服務具有挑戰性。由於每個目的地都有一個單獨的佇列，每個工作人員都必須檢查每個佇列的工作情況，這會給目的地服務增加一層複雜性，而我們對此感到不舒服。這是離心機的主要靈感。 Centrifuge 將取代我們所有的單獨佇列，並負責將事件傳送到單個整體服務。
5 遷移到 Monorepo
鑑於只有一項服務，將所有目的碼移至一個儲存庫中是有意義的，即將所有不同的依賴項和測試合併到一個儲存庫中。我們知道這會很混亂。
對於 120 個獨特依賴項中的每一個，我們致力於為所有目的地提供一個版本。當我們移動目的地時，我們會檢查它正在使用的依賴項並將其更新到最新版本。我們修復了目的地中與新版本不符的任何內容。
透過這種轉變，我們不再需要跟蹤依賴版本之間的差異。所有的目的地都使用相同的版本，這顯著降低了程式碼庫的複雜性。現在，維護目的地變得更省時、風險更低。
我們還想要一個測試套件，使我們能夠快速輕鬆地執行所有目標測試。在更新我們之前討論的共享庫時，執行所有測試是主要障礙之一。
幸運的是，目的地測試都有相似的結構。他們進行了基本的單元測試，以驗證我們的自定義轉換邏輯是否正確，並向合作伙伴的端點執行 HTTP 請求，以驗證事件是否按預期顯示在目標中。
6 覆盤
將每個目的碼庫分離到自己的儲存庫中的最初動機是為了隔離測試失敗。然而，事實證明這是一個虛假的優勢。發出 HTTP 請求的測試仍然經常失敗。由於目的地被分成自己的儲存庫，因此沒有動力去清理失敗的測試。這種糟糕的衛生狀況導致了令人沮喪的技術債務的持續來源。通常，原本只需要一兩個小時的小改變最終需要幾天到一週的時間才能完成。
7 構建彈性測試套件
測試執行期間對目標端點的出站 HTTP 請求是測試失敗的主要原因。諸如過期憑證之類的不相關問題不應導致測試失敗。根據經驗，我們還知道某些目標端點比其他端點慢得多。某些目的地需要長達 5 分鐘的時間來執行測試。對於 140 多個目的地，我們的測試套件可能需要長達一個小時才能執行。
為了解決這兩個問題，我們建立了 Traffic Recorder。 Traffic Recorder構建在yakbak之上，負責記錄和儲存目的地的測試流量。每當測試第一次執行時，任何請求及其相應的響應都會記錄到檔案中。在後續測試執行中，將回放檔案中的請求和響應，而不是請求目標端點。這些檔案被簽入儲存庫，以便測試在每次更改中保持一致。現在測試套件不再依賴於網際網路上的這些 HTTP 請求，我們的測試變得更加有彈性，這是遷移到單個儲存庫的必備條件。
我記得在我們整合了 Traffic Recorder 之後，第一次對每個目的地進行了測試。我們花了幾毫秒的時間才完成對所有 140 多個目的地的測試。過去，只需幾分鐘即可完成一個目的地。感覺就像魔法一樣。
8 單體系統的工作原理
一旦所有目的地的程式碼都集中在一個版本庫中，它們就可以合併到一個服務中。由於每個目的地都在一個服務中，我們的開發人員的工作效率大大提高。我們不再需要為了修改一個共享庫而部署 140 多個服務。一名工程師就能在幾分鐘內部署服務。
速度的提高就是最好的證明。2016 年，當我們的微服務架構還在執行時，我們對共享庫進行了 32 次改進。就在今年，我們進行了 46 項改進。在過去 6 個月中，我們對庫的改進比 2016 年全年都要多。
這一變化也讓我們的運營故事受益匪淺。由於每個目的地都在一個服務中，我們擁有 CPU 和記憶體密集型目的地的良好組合，這使得擴充套件服務以滿足需求變得更加容易。龐大的工人池可以吸收峰值負載，因此我們不再為處理少量負載的目的地分頁。
9 Trade Offs
從我們的微服務架構轉變為單體架構總體上是一個巨大的進步，但是，這其中也有取捨：
- 故障隔離很困難。由於所有服務都在單體中執行，如果某個目的地出現錯誤導致服務崩潰，那麼所有目的地的服務都會崩潰。我們有全面的自動測試，但測試只能到此為止。我們目前正在開發一種更強大的方法，以防止一個目的地導致整個服務當機，同時仍將所有目的地保持在一個整體中
- 記憶體快取的效果較差。以前，由於每個目的地只有一個服務，我們的低流量目的地只有少量程序，這意味著其控制平面資料的記憶體快取會一直處於熱狀態。而現在，快取分散在 3000 多個程序中，被攻擊的可能性大大降低。我們可以使用像 Redis 這樣的東西來解決這個問題，但這又是一個我們必須考慮的擴充套件問題。最終，考慮到可觀的執行效益，我們接受了這種效率損失
- 更新依賴關係的版本可能會破壞多個目的地。雖然將所有內容轉移到一個版本庫中解決了之前依賴關係混亂的問題，但這也意味著如果我們想使用最新版本的庫，就有可能需要更新其他目的地才能使用新版本。不過我們認為，這種方法的簡便性值得權衡利弊。有了我們全面的自動測試套件，我們就能快速瞭解更新依賴版本後會出現哪些問題
8 總結
我們最初的微服務架構執行了一段時間，透過將目的地相互隔離，解決了管道中的直接效能問題。但是，我們的架構並不適合擴充套件。在需要進行批次更新時，我們缺乏測試和部署微服務的適當工具。因此，我們的開發人員工作效率迅速下降。
轉向單體後，我們擺脫了管道的執行問題，同時顯著提高了開發人員的工作效率。但我們並沒有輕率地完成這一轉變，我們知道要想成功，我們必須考慮一些事情。
我們需要一個堅如磐石的測試套件，將所有東西都放到一個 repo 中。如果不這樣做，我們就會陷入與最初決定將它們分開時同樣的境地。過去，不斷失敗的測試損害了我們的工作效率，我們不希望這種情況再次發生。
我們接受了單體架構中固有的取捨，並確保為每種架構編寫了一個好故事。我們必須接受這種改變所帶來的一些犧牲。
在決定使用微服務還是單體架構時，需要考慮的因素各有不同。在我們基礎架構的某些部分，微服務執行良好，但我們的伺服器端目的地是一個完美的例子，說明了這種流行趨勢實際上會損害生產率和效能。事實證明，我們的解決方案是單體。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都技術專家，多家大廠後端一線研發經驗，在分散式系統、和大資料系統等方面有多年的研究和實踐經驗，擁有從零到一的大資料平臺和基礎架構研發經驗，對分散式儲存、資料平臺架構、資料倉儲等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&優惠券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
目前主攻降低軟體複雜性設計、構建高可用系統方向。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！