0 前言 除非你一直生活在岩石下麵，否則你可能已經知道微服務是當今流行的架構趨勢。與這一趨勢一同成長，Segment早期就採用了這種最佳實踐，這在某些情況下對我們很有幫助，但正如你將很快瞭解到的，在其他情況下則並非如此。 簡單來說，微服務是一種面向服務的軟體架構，其中伺服器端應用程式通過組合許多單一 ...
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 發佈！
