本文是關于 Newbe.Claptrap 項目主體內容的介紹，讀者可以通過這篇文章，大體了解項目內容。

輪子源于需求

隨著互聯網應用的蓬勃發展，相關的技術理論和實現手段也在被不斷創造出來。諸如 “云原生架構”、“微服務架構”、“DevOps” 等一系列關鍵詞越來越多的出現在工程師的視野之中。總結來看，這些新理論和新技術的出現，都是為了解決互聯網應用中出現的一些技術痛點：

更高的容量擴展性要求。在商業成功的基礎前提下，互聯網應用的用戶數量、系統壓力和硬件設備數量等方面都會隨著時間的推移出現明顯的增長。這就對應用本省的容量可擴展性提出了要求。這種容量可擴展性通常被描述為 “應用需要支持水平擴展”。

更高的系統穩定性要求。應用程序能夠不間斷運行，確保商業活動的持續進展，這是任何與這個應用系統相關的人員都希望見到的。但是要做到這點，通常來說是十分困難的。而現今的互聯網應用在面對諸多同類競爭者的情況下，如果在這方面做得不夠健全，那么很可能會失去一部分用戶的青睞。

更高的功能擴展性要求。“擁抱變化”，當人們提到 “敏捷項目管理” 相關的內容時，都會涉及到的一個詞語。這個詞語充分體現了當今的互聯網應用若要成功，在功能性上做到出彩做到成功是多么的重要。也從一個側面體現了當前互聯網環境下產品需求的多變。而作為系統工程師，在應用建立之初就應該考慮這點。

更高的開發易用度要求。這里所屬的開發易用度是指，在應用系統自身在進行開發時的難易程度。要做到越易于開發，在應用自身的代碼結構，可測試性，可部署性上都需要作出相應的努力。

更高的性能要求。這里提到的性能要求，是特指在系統容量增加時的性能要求。避免系統的單點性能問題，讓應用系統具備可水平擴展的特性。通常來說，在性能出現問題時，若可以通過增加物理設備來解決問題，通常來說是最為簡單的辦法。而在不同的系統容量之下，系統性能的優化方案通常是不同的。因此結合應用場景進行技術方案的選型一直都是系統工程師所需要考慮的問題。

本項目，就是基于以上這些系統功能特性要求所總結出來的一套開發框架。這其中包含了相關的理論基石、開發類庫和技術規約。

世界上本也不存在 “銀彈”。一套框架解決不了所有問題。 ——不愿意透露姓名的月落

從需求出發

在講解分布式系統時，常常會用到 “賬號轉賬” 這個簡單的業務場景來配合描述。這里闡述一下這個業務場景。

假設我們需要建設一個具備賬號體系的業務系統。每個賬號都有余額。現在需要執行一次轉賬操作，將賬號 A 的余額中的 300 劃轉給賬號 B。另外，基于上節的基本要求，我們在實現這個場景時，需要考慮以下這些內容：

• 需要應對系統容量的激增。應用初期可能只有 1000 個初始用戶。由于應用推廣效果良好以及機器人賬號的涌入，用戶數量實現了在一個月內實現了三個數量級的攀升，也就是增長到了百萬級別。

• 需要考慮系統的穩定性和可恢復性。盡可能減少系統整體的平均故障時間，即使出現系統故障也應該是盡可能易于恢復的。也就是，要避免出現單點故障。

• 需要考慮業務的可擴展性。后續可能需要增加一些業務邏輯：按照賬戶等級限制日轉賬額、轉賬成功后進行短信通知、轉賬支持一定額度的免密轉賬、特定的賬號實現 “T+1” 到賬。

• 需要考慮代碼的可測試性。系統的業務代碼和系統代碼能夠良好的分離，能夠通過單元測試的手段初步驗證業務代碼和系統代碼的正確性和性能。

輪子的理論

本節將介紹一些和本框架緊密結合的理論內容，便于讀者在后續的過程中理解本框架的工作過程。

Actor 模式

Actor 模式是一種并發編程模型。通過這種編程模型的應用可以很好的解決一些系統的并發問題。這里所提到的并發問題是指計算機對同一數據進行邏輯處理時，可能由于存在多個同時發起的請求可能導致數據出現不正確的問題。這個問題在進行多線程編程時一定會遇到的問題。舉個簡單的例子，假如在不加同步鎖的情況下，使用 100 個線程并發對內存中的一個int變量執行++操作。那么最終這個變量的結果往往小于 100。此處 Actor 模式是如何避免此問題的。

首先，為了便于理解，讀者在此處可以將 Actor 認為是一個對象。在面向對象的語言（Java、C# 等）當中，可以認為 Actor 就是通過new關鍵詞創建出來的對象。不過這個對象有一些特別的特性：

擁有屬于自身的狀態。對象都可以擁有自身的屬性，這是面向對象語言基本都具備的功能。在 Actor 模式中，這些屬性都被統稱為Actor的狀態（State）。Actor 的狀態由 Actor 自身進行維護。

這就強調了兩點：

第一、Actor 的狀態只能由自身進行改變，若要從外部改變 Actor 的狀態，只能通過調用 Actor 才能改變。

第二、Actor 的狀態只在 Actor 內部進行維護，不與當前 Actor 之外的任何對象共享。這里說的不共享也是強調其不能通過外部某個屬性的改變而導致 Actor 內部狀態的變化。這點主要是為了區別于一些具備 “對象引用” 語言特性的編程語言而言的。例如：在 C# 的class的public屬性，假如是引用類型，那么在外部獲得這個class之后是可以改變class中的屬性的。但是這在 Actor 模式當中是不被允許的。

不過從 Actor 內部讀取數據到外部，這仍然是允許的。

單線程。Actor 通常同一時間只能接受一個調用。這里所述的線程不完全是指計算機中的線程，是為了凸顯 “Actor 同一時間只能處理一個請求的特性” 而使用的詞語。假如當前 Actor 正在接受一個調用，那么剩余的調用都會阻塞，直到調用結束，下一個請求才允許被進入。這其實類似于一個同步鎖的機制。通過這種機制就避免了對 Actor 內部狀態進行修改時，存在并發問題的可能。具體一點說明：如果使用 100 個線程對一個 Actor 進行并發調用，讓 Actor 對狀態中的一個int變量進行++操作。最終這個狀態的數值一定是 100。

不過單線程也不是絕對的，在不存在并發問題的請求情況下，允許并發處理。例如讀取 Actor 中的狀態，這通常不會有并發問題，那么此時就允許進行并發操作。

讀到 Actor 單線程特性時，通常讀者會考慮到這是否會導致 Actor 本身處理過慢而產生性能問題呢？關于這點，希望讀者繼續持有這個問題往后閱讀，尋找答案。

事件溯源模式

事件溯源模式是一種軟件設計思路。這種設計思路通常與傳統的采用增刪查改（CRUD）為主的系統設計思路相區別。CRUD 應用通常存在一些局限性：

通常來說 CRUD 應用會采用直接操作數據存儲的做法。這樣的實現方式可能會由于對數據庫優化不足而導致性能瓶頸，并且這種做法會較難實現應用伸縮。

在特定的領域通常存在一些數據需要注意對并發問題進行處理，以防止數據更新的錯誤。這通常需要引入 “鎖”、“事務” 等相關的技術來避免此類問題。但這樣又有可能引發性能上的損失。

除非增加額外的審計手段，否則通常來說數據的變更歷史是不可追蹤的。因為數據存儲中通常保存的是數據最終的狀態。

與 CRUD 做法對比，事件溯源則從設計上避免了上述描述的局限性。接下來圍繞上文中提到的 “轉賬” 業務場景簡述事件溯源的基礎工作方式。

采用 CRUD 的方法實現 “轉賬”。

采用事件溯源的方式實現 “轉賬”。

如上圖所示，通過事件溯源模式將轉賬業務涉及的余額變動采用事件的方式進行存儲。同樣也實現了業務本身，而這樣卻帶來了一些好處：

• 通過事件，可以還原出賬號任何階段的余額，這就一定程度實現了對賬號余額的跟蹤。

• 由于兩個賬號的事件是獨立處理的。因此，兩個賬號的處理速度不會相互影響。例如，賬號 B 的轉入可能由于需要額外的處理，稍有延遲，但賬號 A 仍然可以的轉出。

• 可以通過訂閱事件來做一些業務的異步處理。例如：更新數據庫中的統計數據，發送短信通知等其他的一些異步操作。

當然引入事件溯源模式之后也就引入了事件溯源相關的一些技術問題。例如：事件所消耗的存儲可能較為巨大；不得不應用最終一致性；事件具備不可變性，重構時可能較為困難等。相關的這些問題在一些文章中會有較為細致的說明。讀者可以閱讀后續的延伸閱讀內容，進而進行了解與評估。

系統復雜度是不會因為系統設計變化而減少的，它只是從一個地方轉移到了另外的地方。——總說自己菜的月落

讓輪子轉起來

基于讀者已經大體理解了上節理論的基礎上，本節將結合上述描述的 “轉賬” 業務場景，介紹本框架的工作原理。首先讀者需要了解一下本框架的兩個名詞。

Claptrap

Claptrap 是本框架定義的一種特殊 Actor。除了上文中提到 Actor 兩種特性之外，Claptrap 還被定義為具有以下特性：

狀態由事件進行控制。Actor 的狀態在 Actor 內部進行維護。Claptrap 同樣也是如此，不過改變 Claptrap 的狀態除了在 Actor 之外，還限定其只能通過事件進行改變。這就將事件溯源模式與 Actor 模式進行了結合。通過事件溯源模式保證了 Actor 狀態的正確性和可追溯性。這些改變 Claptrap 狀態的事件是由 Claptrap 自身產生的。事件產生的原因可以是外部的調用也可以是 Claptrap 內部的類觸發器機制產生的。

Minion

Minion 是本框架定義的一種特殊 Actor。是在 Claptrap 基礎上做出的調整。其具備以下特性：

從對應的 Claptrap 讀取事件。與 Claptrap 相同，Minion 的狀態也由事件進行控制。不同的是，Minion 就像其字面意思一樣，總是從對應的 Claptrap 處獲取事件，從而改變自身的狀態。因此，其可以異步的處理 Claptrap 產生事件之后的后續操作。

業務實現

接下來有了前面的基礎介紹，現在介紹一下本框架如何實現上文中的 “轉賬” 場景。首先可以通過下圖來了解一下主要的流程：

如上圖所示，整個流程便是本框架實現業務場景的大體過程。另外，還有一些需要指出的是：

• 圖中 Client 與 Claptrap 的調用等待只有第一階段的時候存在，也就是說，這使得 Client 可以更快的得到響應，不必等待整個流程結束。

• Claptrap A 在處理完自身請求，并將事件發送給 Minion A 之后就可以重新接受請求，這樣提高了 Claptrap A 的吞吐量。

• Minion 不僅僅只能處理 Claptrap 之間的調用代理。在 Minion 當中還可以根據業務需求進行：發送短信，更新數據庫統計數據等其他操作。

• Minion 也可以具備自己的狀態，將部分數據維持在自身的狀態中以便外部可以從自身進行查詢，而不需要從對應的 Claptrap 中進行查詢。例如：統計該賬號最近 24 小時的轉賬變動，以便快速查詢。

業務容量

前文提到本框架需要建設的是一個可以水平擴展的系統架構，只有如此才能應對業務容量的持續增長。在這點上，本框架現階段采用的是微軟開源的?Orleans?和?Service Fabric?搭配，實現應用程序和物理設備的放縮。當然，涉及數據存儲部分時勢必也涉及到數據庫集群等一系列問題。這些屬于技術應用的細節，而非框架理論設計的內容。因此，此處只表明本框架可以基于以上的開源架構進行容量放縮。應用過程中的實際問題，讀者可以在后續的項目內容中尋求解答。

輪廠現狀

當前項目正處于設立初期，主體的體系結構設計與編碼仍在進行中，讀者可以通過項目地址了解項目的最新進展：

Github，主要項目源碼管理：https://github.com/newbe36524/Newbe.Claptrap

Gitee，碼云倉庫地址：https://gitee.com/yks/Newbe.Claptrap

延伸閱讀

以下這些內容都對本框架產生了深遠的影響。讀者可以通過閱讀以下這些內容，增加對本框架的理解。

• 基于 Actor 框架 Orleans 構建的分布式、事件溯源、事件驅動、最終一致性的高性能框架——Ray

• Event Sourcing Pattern

• Event Sourcing Pattern 中文譯文

• Orleans - Distributed Virtual Actor Model

• Service Fabric

• ENode 1.0 - Saga 的思想與實現

原文地址：https://www.cnblogs.com/newbe36524/p/10452831.html

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的Newbe.Claptrap - 一套以 “事件溯源” 和“Actor 模式”作为基本理论的服务端开发框架...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。