Newbe.Claptrap 框架中為什麼用 Claptrap 和 Minion 兩個詞?最近整理了一下專案的術語表。今天就談談為什麼起了 Claptrap 和 Minion 兩個名字。
Claptrap
Claptrap 是本框架定義的一種特殊 Actor。除了上文中提到 Actor 兩種特性之外,Claptrap 還被定義為具有以下特性:
狀態由事件進行控制。Actor 的狀態在 Actor 內部進行維護。Claptrap 同樣也是如此,不過改變 Claptrap 的狀態除了在 Actor 之外,還限定其只能通過事件進行改變。這就將事件溯源模式與 Actor 模式進行了結合。通過事件溯源模式保證了 Actor 狀態的正確性和可追溯性。這些改變 Claptrap 狀態的事件是由 Claptrap 自身產生的。事件產生的原因可以是外部的呼叫也可以是 Claptrap 內部的類觸發器機制產生的。
Claptrap 是 newbe36524 曾經玩過的一款老遊戲中的經典角色。點選此處瞭解
Minon
Minion 是本框架定義的一種特殊 Claptrap 。是在 Claptrap 基礎上做出的調整。其具備以下特性:
從對應的 Claptrap 讀取事件。與 Claptrap 相同,Minion 的狀態也由事件進行控制。不同的是,Minion 就像其字面意思一樣,總是從對應的 Claptrap 處獲取事件,從而改變自身的狀態。因此,其可以非同步的處理 Claptrap 產生事件之後的後續操作。
Minion 一詞出自 newbe36524 玩的一款運氣遊戲《爐石傳說》,其中 “隨從” 在英文版中的描述即為 “minion”。
Claptrap 故事化描述
以下是關於 Claptrap 的故事化描述,用於輔助理解。不必太過在意。
Claptrap 是一種結構簡單、功能簡單的機器人。雖然它能夠完成各種各樣的任務,但是它卻有一些限制。
Claptrap 是一種單執行緒的機器人,它每次只能進行一個任務。如果你想要交給它多個任務的話,它會按照事情安排的先後順序逐個處理。
Claptrap 工作的時候大概的過程是這樣的。當他接受到一個任務時,他會先考慮這個事情是否是他能夠百分之百完成的。如果這件事情他能夠百分之百完成,那麼那就將這件事情寫入到他的備忘錄當中,然後完成這件事情。然後接下來處理下一個事情。
每天早上一起來,Claptrap 做的第一件事情就是找回迷失的自我。找回昨天那個棒棒的自己。首先它會嘗試看看有沒有昨天的靚照,如果有的話,它將復刻昨天的樣貌。接下來,從手中的備忘錄當中閱讀昨天拍照之後發生的種種事情,逐漸的恢復自己的記憶。這樣就成功的找回的自己。
Claptrap 是一種標準化的機器人。它們都產出於 Claptrap 工廠的生產線。工廠會按照 Claptrap 設計圖使用標準化的元件來組裝一個 Claptrap 機器人。這些必要的元件主要包括了:記憶體、手持型備忘錄、多功能任務處理器和記憶體印表機。
記憶體。Claptrap 配備有一個定製化大小的記憶體,用於儲存當前整機的狀態資料。由於記憶體資料的斷電易失性,所以假如 Claptrap 斷電了,那麼記憶體中的資料也就丟失了。
多功能任務處理器。基於成本的考慮,每個 Claptrap 配備的多功能任務處理器都是為了特種的任務定製過的。例如:專門用於消防的 Claptrap ,在它們的多功能任務處理器中基本上包含的都是和消防有關的功能。但是它就無法處理家政相關的任務。
手持型備忘錄。Claptrap 在做每件任務之前都會用手持型備忘錄記錄任務相關的一切細節,來確保任務的每個細節都準確無誤。
記憶體印表機。可以將記憶體當中的資料列印成一份可以持久化儲存的物理格式,在實際生產中用的比較多的是 DNA 記憶體。由於記憶體資料的斷電易失性,所以重啟之後記憶體當中的資料只能通過備忘錄記錄來逐個找回。但由於備忘錄資料有可能很大,這樣恢復起來會比較的緩慢。有了記憶體印表機的幫助,便可以將某一時刻的記憶體狀態完全列印出來,這樣在重啟恢復時將加快記憶體資料恢復的速度。
Minon 故事化描述
以下是關於 Minion 的故事化描述,用於輔助理解。不必太過在意。
對於較為複雜的任務來說單個 Claptrap 完成起來會比較困難。因此,在設計此類 Claptrap 的時候會按照需求給這個 Claptrap 追加幾個小弟來協助它完成手頭的任務。這些小弟被稱為 Minion 。Minion 的本質也是一臺 Claptrap 機器人,但是它們相對於完整版的 Claptrap 來說,減少了手持型備忘錄這個裝置。這是源於其工作方式和 Claptrap 略有不同的原因。
Minion 只能通過協同 Claptrap 來完成任務,它們不能決定是否要做某個任務。所以記錄任務詳細資訊的手持型備忘錄只要有 Claptrap 持有就可以了。
當 Claptrap 完成一件任務時,它會通知他的 Minion 們關於此次任務的細節。這樣 Minion 便可以同步的獲得任務內容,並藉此來更新自己的記憶。以下我們來通過一個例子來解釋這種工作模式。
假設我們現在在某個小區投放了一臺 Claptrap 機器人來作為門衛機器人。它的工作職責包括有以下這些:
- 負責對門房的車輛進行檢查和放行
- 負責對付來自路人的各種詢問
我們現在知道,Claptrap 機器人在工作的時候只能同時處理一件事情。也就是說,假如它正在為某臺車輛進行檢查和放行,那麼它就無法處理路人的詢問。同樣地,假如它正在接受路人的詢問,那麼它就無法處理車輛的檢查和放行。這麼做效率並不高。因此,我們為這臺 Claptrap 增加一臺 Minion 來協助其完成接受路人詢問的任務。
具體的工作方式是這樣的:每天,Claptrap 都會對小區周圍的情況進行檢查並且將具體的資訊全部都記錄在手持型備忘錄當中。並且它會將這些任務的細節通知給它的 Minion 。於是 Minion 就也知道了關於這個小區的所有細節,因此它就能夠輕鬆的應付路人的詢問了。
通過這樣的合作,就能使得 Claptrap 更加高效的專注於車輛的檢查和放行,而路人的詢問則交給 Minion 來處理就可以了。
不過,對於一些細節還需要進行補充解釋以便讀者理解:
為什麼不直接增加一臺新的 Claptrap 來直接處理路人的詢問呢?一臺新的 Claptrap 意味著一個新的主體,它能夠獨立的完成任務,這樣會增加管理的成本。但是如果只是新增一臺 Minion ,它則可以由它所屬的 Claptrap 來負責管理,相較而言更容易管理。當然為了增加一點代入感,還可以這麼理解:Minion 相比於常規的 Claptrap 缺少了手持型備忘錄這個裝置。這個裝置的成本佔總硬體成本的 99%。減少成本來完成相同的任務,何樂不為呢?
Claptrap 將任務細節通知給 Minion 的成本會不會很高?不會的。Claptrap 和 Minion 一般都是團伙作業,隨著現在無線網路技術的不斷改善,這種成本將會越來越小。5G 賦能,未來可期。
現在,我們在額外考慮一個場景:假如物業經理希望 Claptrap 每天定時彙報小區的車輛出入情況。同樣,為了增加代入感,我們不妨假設這個小區非常忙碌,一天 24 小時都有車輛進進出出。因此如果讓它拿出時間來彙報車輛出入情況的話,由於 Claptrap 的單執行緒特性,那麼很可能小區門口就堵成長安街了。
有了前面的經驗,我們同樣可以為這臺 Claptrap 配備一臺新的 Minion 來處理向物業經理彙報的這個任務。因為 Claptrap 在進行車輛出去檢查的時候會將相關的細節通知給 Minion。所以 Minion 也就知道了關於今日車輛出入情況的所有細節,做出報表,那就是分分鐘的事情。
我們再來增加一個場景:我們需要普查一下人口數量。那麼只需要在小區門衛 Claptrap 檢查出入人員時,對人員的資訊進行記錄。同樣的,我們新增一臺 Minion 來專門彙總那些核的資料,並且將上級部門。正巧,上級部門也是通過一臺 Claptrap 機器人來接收下級的資料彙報,並且正好其也有一臺 Minion 用來彙總下級彙報上來的資料,並且彙報給它的上級。就這樣 Claptrap1 -> Minion1 -> Claptrap2 -> Minion2 -> Claptrap3 …… 一層一層的向上。於是我們就完成了全國乃至全球的資料彙總。
因此,我們可以總結一下。有了 Minion 的加持,可以為 Claptrap 更好的完成至少三類事情:
- 協助分擔原有的查詢類任務
- 協助完成一些統計、通知等等可以非同步處理的任務
- 協助完成和其他 Claptrap 的協同來完成規模更大的任務
最後但是最重要!
最近作者正在構建以反應式
、Actor模式
和事件溯源
為理論基礎的一套服務端開發框架。希望為開發者提供能夠便於開發出 “分散式”、“可水平擴充套件”、“可測試性高” 的應用系統 ——Newbe.Claptrap
本篇文章是該框架的一篇技術選文,屬於技術構成的一部分。如果讀者對該內容感興趣,歡迎轉發、評論、收藏文章以及專案。您的支援是促進專案成功的關鍵。
如果你對該專案感興趣,你可以通過 github issues 提交您的看法。
如果您無法正常訪問 github issue,您也可以傳送郵件到 newbe-claptrap@googlegroups.com 來參與我們的討論。
點選連結 QQ 交流【Newbe.Claptrap】:https://jq.qq.com/?_wv=1027&k=5uJGXf5。
您還可以查閱本系列的其他選文:
- Newbe.Claptrap - 一套以 “事件溯源” 和 “Actor 模式” 作為基本理論的服務端開發框架
- 十萬同時線上使用者,需要多少記憶體?——Newbe.Claptrap 框架水平擴充套件實驗
- 談反應式程式設計在服務端中的應用,資料庫操作優化,從 20 秒到 0.5 秒
- 談反應式程式設計在服務端中的應用,資料庫操作優化,提速 Upsert
- docker-mcr 助您全速下載 dotnet 映象
- Newbe.Claptrap 專案週報 1 - 還沒輪影,先用輪跑
- Newbe.Claptrap 框架入門,第一步 —— 建立專案,實現簡易購物車
- Newbe.Claptrap 框架中為什麼用 Claptrap 和 Minion 兩個詞?
GitHub 專案地址:https://github.com/newbe36524/Newbe.Claptrap
Gitee 專案地址:https://gitee.com/yks/Newbe.Claptrap
開發文件:http://claptrap.newbe.pro/
- 本文作者: newbe36524
- 本文連結: https://www.newbe.pro/Newbe.Claptrap/Why-Claptrap-And-Minion/
- 版權宣告: 本部落格所有文章除特別宣告外,均採用 BY-NC-SA 許可協議。轉載請註明出處!