世界並非靜止不動。 進步帶來了新的技術挑戰。 根據不斷變化的需求，資訊系統的架構必須不斷發展。 今天我們將討論事件驅動架構、並發、並發、非同步，以及如何在 Erlang 中與這一切和平共處。
介紹
根據設計系統的規模和要求，我們開發人員選擇系統中交換資訊的方法。 在大多數情況下，為了組織服務的交互，工作選項可能是帶有代理的方案，例如基於RabbitMQ或kafka。 但有時，事件流、SLA 和系統控制等級使得現成的訊息傳遞不適合我們。 當然，您可以透過負責傳輸層和叢集形成來使系統稍微複雜化，例如使用 ZeroMQ 或 nanomsg。 但如果系統具有足夠的吞吐量和標準 Erlang 集群的功能，那麼引入額外實體的問題需要詳細研究和經濟合理性。
反應式分散式應用程式的主題非常廣泛。 為了保持本文的格式，今天討論的主題將僅是基於 Erlang/Elixir 建構的同構環境。 Erlang/OTP 生態系統讓您以最少的努力實現反應式架構。 但無論如何，我們都需要一個訊息傳遞層。
理論基礎
設計從定義目標和限制開始。 主要目標不是為了發展而發展。 我們需要獲得一個安全且可擴展的工具，在此基礎上我們可以創建，最重要的是，開發各種級別的現代應用程式：從服務於小受眾的單伺服器應用程式開始，然後發展為最多50個的集群-60 個節點，以集群聯合結束。 因此，主要目標是透過降低最終系統的開發和擁有成本來實現利潤最大化。
讓我們重點介紹最終系統的 4 個主要要求：
- С面向事件。
系統始終準備好傳遞事件流並執行必要的操作； - М可擴展性。
各個塊可以垂直和水平縮放。 整個系統必須能夠無限水平增長； - О容錯能力。
所有等級和所有服務都應該能夠從故障中自動恢復； - Г保證回應時間。
時間很寶貴，用戶不應該等待太久。
還記得關於「小引擎可以」的古老童話故事嗎？ 為了使設計的系統成功退出原型階段並不斷進步，其基礎必須滿足最低要求 煙霧.
作為基礎設施工具和所有服務的基礎，訊息傳遞還添加了一點：程式設計師的易用性。
事件導向
為了使應用程式從單一伺服器發展到集群，其架構必須支援松耦合。 非同步模型滿足了這個要求。 其中，發送者和接收者關心訊息的資訊負載，而不用擔心系統內的傳輸和路由。
可擴展性
可擴展性和系統效率是緊密相連的。 應用程式元件必須能夠利用所有可用資源。 我們越有效地利用產能，我們的加工方法越優化，我們在設備上花費的錢就越少。
在單一機器內，Erlang 創造了一個高度競爭的環境。 並發性和平行性之間的平衡可以透過選擇 Erlang VM 可用的作業系統執行緒數和利用這些執行緒的調度程式數來設定。
Erlang 進程不共用狀態並以非阻塞模式運作。 與傳統的基於阻塞的應用程式相比，這提供了相對較低的延遲和更高的吞吐量。 Erlang 的調度程序確保 CPU 和 IO 的公平分配，並且無阻塞允許應用程式即使在峰值負載或故障期間也能做出回應。
在集群層面，也存在處置問題。 重要的是叢集中的所有機器負載均勻且網路不過載。 讓我們想像一種情況：使用者流量到達傳入平衡器（haproxy、nginx 等），它們在可用後端集之間盡可能均勻地分配處理請求。 在應用程式基礎架構中，實作所需介面的服務只是最後一英里，需要請求許多其他服務來回應初始請求。 內部請求也需要路由和平衡。
為了有效地管理資料流，訊息傳遞必須為開發人員提供一個介面來管理路由和負載平衡。 因此，開發人員將能夠使用微服務模式（聚合器、代理、鏈、分支等）來解決標準問題和很少出現的問題。
從業務角度來看，可擴展性是風險管理工具之一。 主要是透過優化使用設備來滿足客戶的要求：
- 當裝備的威力因進步而增加時。 不會因為軟體不完善而閒置。 Erlang 垂直擴展良好，並且始終能夠利用所有 CPU 核心和可用記憶體；
- 在雲端環境中，我們可以根據目前或預測的負載來管理設備數量並確保SLA。
容錯
讓我們考慮兩個公理：「失敗是不可接受的」和「總是會有失敗」。 對企業來說，軟體故障意味著金錢損失，更糟的是聲譽損失。 在可能的損失和開發容錯軟體的成本之間進行權衡，通常可以找到折衷方案。
從短期來看，包含容錯功能的架構可以節省購買現成叢集解決方案的資金。 它們價格昂貴，而且也有缺陷。
從長遠來看，容錯架構在開發的各個階段都會帶來數倍的回報。
程式碼庫內的訊息傳遞可讓您在開發階段詳細計算系統內元件的互動。 這簡化了回應和管理故障的任務，因為所有關鍵元件都會處理故障，並且最終的系統透過設計知道如何在發生故障後自動恢復正常。
反應能力
無論發生什麼故障，應用程式都必須回應請求並滿足 SLA。 現實情況是，人們不想等待，因此企業必須做出相應的調整。 越來越多的應用程式預計將具有高響應能力。
響應式應用程式幾乎是即時運行。 Erlang VM 以軟即時模式運作。 對於某些領域，例如股票交易、醫藥和工業設備控制，硬實時模式很重要。
響應式系統可改善使用者體驗並使業務受益。
初步總結
在計劃這篇文章時，我想分享我創建訊息代理並基於它構建複雜系統的經驗。 但理論和動機部分相當廣泛。
在本文的第二部分中，我將討論實作交換點、訊息傳遞模式及其應用的細微差別。
在第三部分中，我們將考慮組織服務、路由和平衡的一般問題。 讓我們談談系統的可擴展性和容錯性的實際方面。
第一部分結束。
照片 .
來源： www.habr.com