背景
在分散式系統中非同步建立實體既是挑戰也是優勢，尤其是對於追求可擴充套件性、容錯性和高效使用者體驗的大型企業而言。用於建立實體的非同步（async）管道可以解耦服務、優雅地處理故障並最大限度地減少延遲。這些特性使企業能夠在擴充套件過程中保持靈活、高效能的系統。讓我們深入探討構建有效管道的優勢、挑戰和解決方案。
實體建立中非同步管道的優勢
優雅的故障處理
在複雜的分散式系統中，實體建立過程中的某些任務並不重要。非同步管道允許故障隔離，這意味著非關鍵任務的故障不會中斷整個流程。這些任務既可以重試，也可以忽略，從而使流水線順利進行。
減少延遲和並行性
透過解耦高延遲任務，非同步管道可確保其他任務無需等待即可繼續執行。這種並行性縮短了實體建立的總體時間，尤其是當不相互依賴的任務可以同時執行時，吞吐量和響應速度都會得到提高。
獨立性和可擴充套件性
非同步管道可讓不同的服務獨立工作，並根據需要進行擴充套件。例如，處理通知的服務可能與核心實體建立服務有不同的擴充套件需求。由於服務是鬆散耦合的，因此可以在不中斷管道的情況下對其進行更換、更新或擴充套件，從而增強系統的彈性。
提高容錯性和最終一致性
非同步管道允許在服務停機或延遲時自動重試。雖然某些任務可能需要更長的時間，但系統可確保最終的一致性，保證跨服務的資料即使暫時不同步，最終也會同步。
無阻塞操作
使用非同步系統，服務可以在不等待其他服務響應的情況下繼續執行，從而提高資源利用率和系統響應速度。這種非阻塞特性允許多個任務並行執行，從而提高了系統的整體吞吐量。
松耦合和靈活性
服務間的非同步通訊促進了松耦合架構，不同的服務透過事件流或訊息佇列進行互動。這種分離實現了獨立更新或替換，使大型企業能夠管理複雜的架構並採用持續部署策略。
響應式前端體驗
非同步管道允許前端應用程式向使用者提供即時反饋，即使後端流程需要時間才能完成。具體做法是，在後端執行繁重任務時，通知使用者實體建立正在進行中。實時使用者通知可確保流暢、響應迅速的使用者體驗。
事件驅動架構
非同步管道在事件驅動架構中表現出色，在這種架構中，某些任務（如通知或更新）由特定事件觸發。這些架構能有效處理大量事件，同時保持系統的響應速度。
支援微服務和服務專業化
在基於微服務的體系結構中，每個服務都是獨立管理的，非同步管道允許服務專門處理驗證或日誌記錄等任務，而無需依賴其他服務。這種專業化提高了效能，簡化了大規模維護。
實體建立中的非同步管道挑戰
雖然非同步管道具有顯著的優勢，但也存在一系列挑戰：
最終一致性
分散式系統依賴於最終一致性，這可能會導致服務之間出現暫時的不一致。一些服務可能會識別建立的實體，而另一些服務則不會。在各系統間保持同步資料，尤其是在實體建立過程中，就成了一個挑戰。
錯誤處理和重試
管道的任何步驟都可能發生故障。錯誤處理需要重試和惰性等機制，以避免資料重複或損壞。識別故障點並確保從部分成功中優雅地恢復對系統可靠性至關重要。
競賽條件
當多個服務非同步工作時，可能會出現競賽條件。例如，如果一個服務假定某個實體已經完全建立，那麼它可能會對不完整的資料採取行動。要避免此類問題，服務間的有效協調和協調是必不可少的。
延遲和效能
由於分散式服務之間的通訊，非同步管道可能會引入延遲。如果實體建立過程中的任何一步出現延遲，整個操作的速度就會減慢。這在使用者等待實時響應時尤其容易出現問題。
監控和可觀察性
跟蹤非同步操作的狀態比同步系統更難。適當的日誌記錄、監控和可觀察性對於發現問題和排除故障至關重要，但這些功能通常在非同步管道中更難實現。
依賴實體的協調
當一個實體依賴於另一個實體的成功建立時，非同步協調就會變得複雜。協調失敗會導致依賴關係中斷或死鎖。
模式錯配和演變
模式的更改會破壞非同步管道，尤其是在不保持向後相容性的情況下。回滾模式變更會導致服務間資料不一致。
使用非同步管道建立實體的實用解決方案
為了應對非同步管道的挑戰，我們可以透過以下步驟實現彈性架構：
同步建立主識別符號
實體建立過程從同步建立主識別符號開始，主識別符號是其餘操作的基礎。在整個過程完成之前，實體在資料庫中會被標記為 “未準備好使用”。這樣可以確保使用者不會看到不完整的資料。
實體完成的非同步管道
建立主識別符號後，其他任務（如填充不同的資料儲存）將以非同步方式處理。每個任務都會引用主識別符號，確保整個管道的一致性。
協調層
利用 Temporal 等協調平臺，系統可以管理任務執行、重試和狀態跟蹤。在將實體標記為 “可用於消費 ”之前，協調層會監聽所有任務的成功完成。
實體狀態管理
實施多種狀態，如 “待建立”、“出錯 ”和 “可使用”。這樣可以改進跟蹤，並透過通知或電子郵件更新為使用者提供及時反饋。
日誌和可觀察性
全面的日誌記錄對於診斷問題和跟蹤管道健康狀況至關重要。應使用可觀察性工具來監控非同步操作的狀態，並深入瞭解系統瓶頸。
臨時資料儲存
臨時儲存層可以在管道開始時儲存原始資料 Blob。這樣就能進行資料恢復和任務重試，而不會在服務故障時損壞或丟失資訊。
使用者互動和反饋
透過響應式介面向使用者提供實時反饋對使用者體驗至關重要。實施通知或使用者介面元素等機制，允許使用者重新整理和檢查實體建立請求的狀態。
系統架構解讀
客戶端（Client）：
- 初始點，負責傳送原始資料（raw blob）。
臨時儲存（Temporary Storage）：
- 臨時儲存接收客戶端傳送的原始資料。
- 在訊息佇列處理失敗時，可以重新獲取原始資料。
訊息佇列（Message Queue）：
- 非同步處理機制，用於排隊訊息。
- 觸發非同步任務，並將主識別符號（Primary Identifier）傳遞給任務。
非同步任務（Async Tasks）：
- 包括多個非同步任務（Async Task 1至4）。
- 這些任務可能執行不同的處理流程，如資料清洗、驗證、轉換等。
- 任務完成後，會返回一個完成訊號。
實體生成（Entity Generation）：
- 負責生成或獲取實體的唯一識別符號（ID）。
- 更新實體狀態為“就緒（ready）”。
資料儲存（Datastore）：
- 儲存實體的ID和後設資料。
- 更新實體狀態為“就緒”。
主API（Primary API）：
- 負責儲存ID和後設資料。
- 更新實體狀態為“就緒”。
- 獲取只有“就緒”狀態的實體。
系統架構設計特點：
- 非同步處理：透過訊息佇列和非同步任務處理，系統可以非阻塞地處理大量資料，提高吞吐量。
- 容錯性：臨時儲存可以在訊息佇列處理失敗時重新獲取資料，增強了系統的容錯能力。
- 解耦合：各個元件之間透過訊息佇列和API進行通訊，減少了直接依賴，提高了系統的靈活性和可維護性。
- 可擴充套件性：非同步任務可以根據需要增加或減少，以適應不同的負載。
- 狀態管理：透過實體狀態的更新，系統可以跟蹤資料的處理進度。
可能的應用場景：
- 大資料處理：適用於需要處理大量資料的場景，如日誌分析、事件跟蹤等。
- 微服務架構：在微服務架構中，各個服務可以透過訊息佇列進行通訊，實現服務間的解耦。
- 任務佇列管理：適用於需要排隊和非同步處理任務的場景，如電子郵件傳送、檔案處理等。
- 資料整合：在資料整合過程中，可以將來自不同源的資料進行清洗、轉換，並儲存到統一的資料儲存中。
這個系統架構設計適用於需要高吞吐量、高可用性和可擴充套件性的場景。透過非同步處理和狀態管理，系統可以有效地處理大量資料，同時保持資料的一致性和完整性。
優點
高吞吐量：非同步處理機制可以提高系統的處理能力，允許系統在不阻塞主執行緒的情況下處理大量資料。
可擴充套件性：系統可以透過增加更多的非同步任務處理器來應對增加的工作負載，使得系統易於擴充套件。
容錯性：透過臨時儲存和訊息佇列，系統可以在處理過程中出現故障時重新嘗試，從而提高系統的穩定性。
解耦合：元件之間的通訊透過訊息佇列和API進行，減少了元件之間的直接依賴，使得系統更易於維護和升級。
靈活性：非同步任務可以根據需要進行調整，不同的任務可以並行執行，提高了系統的靈活性。
狀態跟蹤：透過實體狀態的管理，可以跟蹤資料的處理進度，便於監控和除錯。
負載均衡：非同步任務可以在多個處理器之間分配，實現負載均衡，提高資源利用率。
缺點
複雜性：引入非同步處理和訊息佇列會增加系統的複雜性，需要更多的設計和維護工作。
除錯困難：由於系統的非同步性質，除錯和跟蹤問題可能會更加困難，尤其是在分散式環境中。
訊息佇列的瓶頸：如果訊息佇列成為系統的瓶頸，可能會限制整體效能。
資料一致性問題：在分散式系統中，確保資料的一致性是一個挑戰，尤其是在多個非同步任務並行處理資料時。
延遲問題：雖然非同步處理可以提高吞吐量，但在某些情況下，它可能會導致處理延遲，特別是當任務佇列很長時。
資源管理：需要有效的資源管理策略來確保系統在高負載下仍然能夠穩定執行，這可能需要額外的監控和自動化工具。
依賴外部系統：系統的效能和穩定性可能依賴於外部的訊息佇列和資料儲存系統，這可能引入額外的風險。
事務管理：在涉及多個非同步任務和資料更新時，事務管理可能變得複雜，需要額外的機制來保證操作的原子性。
結論
用於實體建立的非同步管道為大型企業提供了強大的優勢，提高了可擴充套件性、彈性和使用者體驗。但是，它們也面臨著與資料一致性、錯誤處理和延遲相關的挑戰。透過採用具有同步識別符號建立步驟、協調層和仔細監控的結構化方法，企業可以克服這些挑戰，構建可擴充套件且可靠的系統。這個系統架構設計適用於需要高吞吐量、高可用性和可擴充套件性的場景。透過非同步處理和狀態管理，系統可以有效地處理大量資料，同時保持資料的一致性和完整性。這個架構在提高系統效能和可擴充套件性方面有很多優點，但也帶來了一定的複雜性和潛在的挑戰。在實際應用中，需要根據具體的業務需求和資源情況來權衡這些優缺點。
今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理，資訊保安，團隊建設 有參考作用 , 您可能感興趣的文章:
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
影片直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續整合/CD
網際網路電商購物車架構演變案例
網際網路業務場景下訊息佇列架構
網際網路高效研發團隊管理演進之一
訊息系統架構設計演進
網際網路電商搜尋架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之效能實時度量系統演變
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：
![image_thumb2_thumb_thumb_thumb_thumb[1]](https://i.iter01.com/images/172772b09c67e13682e4f224f282dd7eb9aaa2028bf4b5397d1dd5e9f2af74d1.png "image_thumb2_thumb_thumb_thumb_thumb[1]")
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。