本文是關於 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
點擊鏈接QQ交流【Newbe.Claptrap】：https://jq.qq.com/?_wv=1027&k=5uJGXf5
延伸閱讀
以下這些內容都對本框架產生了深遠的影響。讀者可以通過閱讀以下這些內容，增加對本框架的理解。
- 基於Actor框架Orleans構建的分布式、事件溯源、事件驅動、最終一致性的高性能框架——Ray
- Event Sourcing Pattern
- Event Sourcing Pattern 中文譯文
- Orleans - Distributed Virtual Actor Model
- Service Fabric
- ENode 1.0 - Saga的思想與實現
來源: newbe
文章作者: newbe36524
文章鏈接: https://www.newbe.pro/Newbe.Claptrap/Overview-Of-Newbe-Claptrap/
本文章著作權歸作者所有，任何形式的轉載都請注明出處。