本文是關於 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 應用通常存在一些侷限性：

1. 通常來說 CRUD 應用會採用直接運算元據儲存的做法。這樣的實現方式可能會由於對資料庫最佳化不足而導致效能瓶頸，並且這種做法會較難實現應用伸縮。
2. 在特定的領域通常存在一些資料需要註意對併發問題進行處理，以防止資料更新的錯誤。這通常需要引入 “鎖”、“事務” 等相關的技術來避免此類問題。但這樣又有可能引發效能上的損失。
3. 除非增加額外的審計手段，否則通常來說資料的變更歷史是不可追蹤的。因為資料儲存中通常儲存的是資料最終的狀態。

與 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