0 關鍵收穫
- 單元化架構提高了微服務的彈性和容錯性。
- 可觀察性對於開發和運營單元化架構至關重要。
- 單元路由器是單元基礎架構的關鍵元件，它需要快速響應單元可用性和健康變化。
- 要成功採用單元化架構，需要全面和綜合的方法來實現可觀察性。
- 單元化架構利用與微服務相同的可觀察性支柱，但需要定製以適應這種架構特有的元素。
在過去的幾年中，單元化架構作為一種新興的正規化，公司如:
- Slack（將最關鍵的使用者服務從單體架構遷移到單元化架構）
- Flickr（採用聯邦方法在許多服務的分片或叢集上儲存使用者資料）
- Salesforce（設計了一個基於50個節點的自我包含功能的pod解決方案）
- 以及Facebook（提出了由叢集、後設資料儲存和Zookeeper中的控制器組成的服務單元稱為單元的構建塊）
他們使用這些架構來解決彈性和容錯的挑戰。受歡迎的原因包括故障隔離、可擴充套件性提高、維護簡化、容錯性增強、靈活性和成本效益。
在實現彈性和容錯的旅程中，基於單元架構的倡導者依賴於可觀察性，這在補充實現中發揮了關鍵作用。對於Interact來說就是這種情況，它是最早記錄可觀察性對保證健康的單元化架構至關重要的公司之一。Interact的工程團隊使用可觀察性來提供對系統行為的深入洞察，使他們能夠主動發現問題，並在故障發生時促進更快的恢復。具體來說，他們使用了每個單元託管的最大客戶端數量和每個單元每天的最大請求數量來建立新的基礎架構以及現有架構。
本文深入探討了採用單元化架構的彈性和容錯優勢，重點關注可觀察性方面。
- 第一部分回答了一個常見問題：如果微服務已經具有彈性和容錯性，為什麼還要使用單元化架構？
- 有了這個解釋，第二部分專注於可觀察性以及分析單元化架構的輸入和輸出的考慮因素
- 最後，它介紹了實現所需的最佳實踐和收穫，以便早期發現問題，快速診斷問題，並做出明智的決策，以增強彈性和容錯性。
1 為啥還用單元化架構？
微服務已具有彈性和容錯性，為啥還用單元化架構？微服務確實降低了單個錯誤可能使整個系統崩潰的風險，因為它們使用更小的獨立部署單元。這種正規化允許微服務中的故障不影響整個應用程式。然而，處理服務間通訊的複雜性也降低了彈性和容錯水平也是一個現實。雖然微服務非常適合處理以模組化和管理性為重點的大型企業應用程式，但在需要極端模組化、可擴充套件性和資源效率的場景中，單元化架構提供了優勢。這就是為什麼Tumblr，一個從初創公司到幾個月內非常成功的公司，選擇從單體架構遷移到單元化架構而不是微服務。可擴充套件性是他們的優先事項，因為他們不得不在處理每月流量大幅增加的同時發展他們的基礎設施。
1.1 單元化策略：高可用性以滿足快速增長的需求
選擇基於微服務的架構需要仔細分析其優點和缺點之間的平衡。雖然它提供了改進的可擴充套件性、容錯性和更容易的操作，但它也引入了實現和管理的複雜性。然而，單元化架構非常適合優先考慮高可用性、需要快速增長或能夠縮放單個元件和隔離故障的系統。
單元化架構不是萬能解決方案，而是一種與特定業務和技術需求一致的戰略選擇。下圖說明基於微服務的架構如何將更大的系統分割成包含有界上下文業務領域的元件。
基於微服務的架構：
下圖顯示了單元化架構如何簡化與這些服務之間的通訊複雜性，其中每個單元都是相同的，並且表示一個獨立縮放的整個棧
單元化架構：
關於上圖，實現單元化架構有兩種視角：
-
一種是單元是不可變的元件，共同提供服務
在第一種視角中，單元可以相互通訊。
-
另一種是每個單元都是相同的，並且代表一個整個服務
第二種視角中，單元作為完整的單元獨立構建、部署和管理，因為單元之間沒有通訊。
單元化架構可以提供改進的彈性和容錯性，但操作員如何確定系統是否提供了這些好處？答案是可觀察性。
2 觀察單元化架構的考慮因素
單元化架構透過隔離、自主和複製的核心原則提供了構建彈性系統的健壯方法。每個單元獨立操作，管理其資源並自主做出決策。資料和關鍵服務在單元內複製以增強可用性。
這些架構在多個區域或資料中心分佈單元，以確保彈性和容錯性，保護免受區域性中斷的影響。連續的健康檢查和監控可以及早發現故障，而斷路器可以防止級聯故障。負載均衡確保高效流量分配，優雅降級優先考慮在部分故障期間的重要功能。混沌工程透過模擬故障定期測試彈性，識別弱點。
可觀察性是理解當前實現狀態和內部工作狀態的最先進工具。儘管沒有它系統也可以工作，但收集、處理、聚合和顯示實時定量指標可以提高彈性和容錯性。這正是將其作為網站可靠性工程中的一個原則的原因之一。
2.1 可觀察性是優秀架構的支柱
除了作為理解系統行為的策略外，可觀察性對於實現良好架構的目標至關重要，特別是在運營卓越、可靠性和效能效率方面。圖3說明了良好架構框架的共同支柱，並使它們的可觀察性關係可見。在運營卓越方面，可觀察性提供了理解系統效能、識別潛在問題以及做出最佳化決策所需的洞察。為了實現效能效率，可觀察性使組織能夠識別其系統中的瓶頸和低效，並採取行動提高效能並降低成本。最後，透過監控系統行為和及早發現異常，可觀察性有助於防止故障並最小化停機時間。
良好架構框架 + 可觀察性：
在觀察單元化架構的過程中，第一步是定義目標並確定適合評估彈性和容錯水平的指標，如平均故障間隔時間（MTBF）、平均修復時間（MTTR）、可用性和恢復時間目標（RTO)。一旦指標清晰，下一個活動是提供結合日誌記錄、指標收集、跟蹤和事件跟蹤的儀器機制，以收集相關資料。然後建立強大的基礎設施，以高效地收集和聚合這些資料。此時，觀察員通常將收集的資料儲存在適當的儲存庫中，如時間序列資料庫，並透過過濾、轉換和豐富處理它。分析工具和視覺化提供洞察力，識別模式，並檢測異常。這些洞察力被整合到開發和操作工作流程中，建立反饋迴圈，推動系統設計和效能改進。最後，該過程根據反饋和不斷演變的要求進行迭代細化。圖4完整地說明了整個過程。
2.2 為單元化架構定製可觀察性
基於單元架構的可觀察性需要定製方法來解決這種分散式系統設計所呈現的獨特挑戰和機會。考慮到可觀察性是關於監控、跟蹤和日誌記錄，單元感知儀器包括在單元級別收集指標，即通常捕獲資源利用率（CPU、記憶體、網路）、請求延遲、錯誤率和與每個單元功能相關的自定義業務指標。分散式跟蹤是關於實現跟蹤以跟蹤跨單元邊界的請求，提供對互動流的洞察，並確定瓶頸。最後，日誌聚合應該來自各個單元到一個集中的系統，允許跨整個架構進行相關性和分析。
第二個考慮因素是建立針對每個單元的特定功能和KPI量身定製的單元級儀表板，使適當的監控和故障排除成為可能。有了這種配置，基於單元特定閾值和異常的單元特定警報確保及時通知影響單個單元的問題。
第三個與可觀察性最佳實踐相關的考慮因素是需要一個獨特的專案，將來自各種單元級可觀察性工具的資料整合到一個集中的平臺中，以進行整體監控和分析。這使得利用集中平臺跨單元相關事件和指標，揭示依賴關係和潛在的級聯故障變得更加容易。
針對單元化架構的可觀察性提出的框架：
最後一個考慮因素是單元隔離，它測試各個單元以識別特定於其功能的的效能瓶頸和故障模式。在這個考慮因素中，混沌實驗預計將被設計和開發，以允許在單元級別進行受控中斷（例如，網路延遲、資源限制），以評估彈性並識別弱點。
透過實施這些實踐，組織可以獲得對其基於單元架構行為的深入瞭解，實現主動監控、快速故障排除和改進的整體系統可靠性和效能。始終記住，單元本身的組成可能因業務而異，這可能是一個優勢，因為多樣性正是基於單元架構的好處之一。
3 路由層咋提供彈性、容錯性和可觀察性
除了單元和控制平面之外，單元路由在提供單元化架構的彈性和容錯性方面至關重要。它的任務是根據分割槽鍵將請求分發到正確的單元，並向客戶端呈現一個單一的端點。根據DoorDash的說法，這個元件提供了包括在服務跨可用性區域不均勻分佈時保持流量平衡在內的多種好處。這使得動態設定pods之間的流量權重成為可能，消除了手動操作，並減少了單個或多AZ故障的影響範圍，這在容錯和降低流量延遲方面至關重要，因為呼叫服務連線到更近的被呼叫者。
為了實現網路中的容錯，路由層使用了一些機制，這些機制已被記錄為提供彈性的創新解決方案。其中之一是路徑冗餘，路由協議發現並維護到目的地的多條路徑；透過這種方式，如果主路徑失敗，流量將自動透過備用路徑重新路由。另一種策略是快速重新路由，旨在快速檢測故障並收斂到新的路由解決方案，最小化停機時間和服務中斷；經典的負載均衡在多條路徑上分配流量，防止擁塞並最佳化網路資源利用。最後，故障檢測和恢復，一旦檢測到故障，路由協議觸發恢復過程以找到備用路徑。
3.1 路由層在架構可觀察性中的作用
由於單元化系統是分散式的，路由層也顯著影響可觀察性。由於它是一個集中操作單元的元件，它是提供整個系統健康和效能洞察的最佳候選者。從這個元件觀察架構允許在網路的各個點進行流量模式、延遲和錯誤觀察。這使得操作員能夠準確定位瓶頸、識別失敗的元件，並最佳化路由決策以獲得更好的效能。
此外，路由層可以被儀器化以收集詳細的指標和日誌，為故障排除和根本原因分析提供有價值的資料。例如，跟蹤請求在多個單元中的路徑可以揭示延遲發生或錯誤起源的位置。這種細粒度的可見性對於維護複雜的單元化應用程式的可靠性和效率至關重要。
總之，基於單元架構中的路由層不僅負責指導流量，還作為可觀察性的關鍵元件。監控和分析流量模式提供了對系統行為的有價值洞察，使主動故障排除和最佳化成為可能。這確保了單元化系統保持彈性和可擴充套件性，並在不同的工作負載下表現最佳。
4 為單元化架構提供彈性、容錯性和可觀察性的最佳實踐
基於單元架構的可觀察性對於維護系統健康和效能至關重要。一個基本的最佳實踐是集中日誌記錄，將來自所有單元的日誌聚合到一個統一的儲存庫中。這種整合簡化了故障排除和分析，使操作員能夠快速識別和解決整個系統的問題。結構化日誌格式進一步提高了這一過程，使日誌資料的高效查詢和過濾成為可能。
4.1 指標和監控
指標和監控是可觀察性的同等重要組成部分。收集有關單元效能、資源利用率和錯誤率的詳細指標為系統行為提供了寶貴的洞察。根據這些指標設定儀表板和警報，可以主動識別異常和潛在瓶頸。像Grafana這樣的視覺化工具可以有效地顯示這些指標，更容易發現可能表明潛在問題的趨勢和模式。
4.2 分散式跟蹤
分散式跟蹤是理解請求流經基於單元架構的另一個重要實踐。透過跟蹤跨多個單元移動的請求，操作員可以準確定位效能瓶頸、延遲問題以及微服務互動中的故障。像Jaeger、Zipkin或AWS X-Ray這樣的分散式跟蹤工具可以幫助視覺化這些複雜的互動，使診斷和解決單元間通訊中出現的問題變得更加簡單。
4.3 警報和事件管理
警報和事件管理是全面可觀察性策略的一個組成部分。根據日誌和指標中的預定義閾值或異常配置警報，可以及時通知潛在問題。這些警報可以透過各種渠道傳送，如電子郵件和簡訊，或整合到像PagerDuty這樣的事件管理平臺中。擁有明確定義的事件管理流程，確保對警報的快速和有組織的響應，最小化停機時間和對整個系統的影響。
4.4 可觀察性的全面方法
除了這些核心實踐之外，採用全面的可觀察性方法也是有益的。這包括定期審查和完善日誌記錄、監控和跟蹤配置，以適應不斷演變的系統需求。此外，將事件事後分析的反饋納入考慮，可以幫助識別可觀察性策略改進的領域。透過不斷提升可觀察性，組織可以確保其單元化架構保持彈性、效能良好且易於管理。
5 總結
本文由“[單元化架構：如何構建可擴充套件和彈性系統]”文章系列的一部分。在這個系列中，我們展示了一個發現之旅，並提供了對單元化架構的許多關鍵方面的全面概述和深入分析，以及將這種方法應用於現有和新架構的實用建議。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！