本文是關於 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 應用會採用直接操作數據存儲的做法。這樣的實現方式可能會由於對數據庫優化不足而導致性能瓶頸，並且這種做法會較難實現應用伸縮。
- 在特定的領域通常存在一些數據需要注意對併發問題進行處理，以防止數據更新的錯誤。這通常需要引入“lock”、“Transaction”等相關的技術來避免此類問題。但這樣又有可能引發性能上的損失。
- 除非增加額外的審計手段，否則通常來說數據的變更歷史是不可追蹤的。因為數據存儲中通常保存的是數據最終的狀態。
與 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實現應用程式和物理設備的放縮。當然，涉及數據存儲部分時勢必也涉及到資料庫集群等一系列問題。這些屬於技術應用的細節，而非框架理論設計的內容。因此，此處只表明本框架可以基於以上的開源架構進行容量放縮。應用過程中的實際問題，讀者可以在後續的項目內容中尋求解答。
延伸閱讀
以下這些內容都對本框架產生了深遠的影響。讀者可以通過閱讀以下這些內容，增加對本框架的理解。