---
tags: 新人資訊
GA: G-YWCCFEGXSJ
---
[新人資訊](https://hackmd.io/@newman/portal-info)

# 技術-後台類-用 dotnet 建立 background service

玩了一陣子裝置端，偶爾碰碰 Web 端，但其實系統的靈魂還在於後台！後台的複雜度和工作量絕對不亞於前端，前端要面對的五花八門的技術問題，後台又何嘗不是？除了技術問題，後台有更重要的「架構面」考量，後台工作完全體現「運籌帷幄」，看不見又有無所不在的影響力，需要概括承受全部的複雜邏輯，還連結全球網路，資料庫和快取，大量和多階段多型態的數據治理，統計分析和建模預測等的，其實範圍真的是無限大；俗語也說某些厲害人物「後台很硬」！後台明明是的非常高尚的說法，只有閱歷豐富的人才懂！

記得曾經在我的工作報告中用「後台」統稱整塊複雜的架構，結果被嫌不夠「炫炮」，硬要改成雲端大數據 AI 機器學習之類流行的名詞，其實相當不以為然，哈哈哈！裝模作樣的日子已經過去了，現在的我只為自己工作，我自己是我唯一的客戶，有沒有價值我說的算！今天寫這篇時剛好有個覺悟：以我對靈魂自由度的要求程度，這輩子可能很難找到可以貢獻所學的業主或老闆，就不再期望了，謀生的問題我另外解決，做系統的目的就是爽而已，或有夥伴關係而絕無雇傭關係，那就回到主題 Background Service 吧。

大約在 2016 年 (轉眼過了六年而我未改初衷) 大數據與機器學習思潮大爆發，讓我整個人徹底著迷，幻想著有一天一定要做一個神奇機器，可以對我個人能力做「無限的升級強化」！這種概念在電影場景已經屢見不顯，像鋼鐵人，蜘蛛人，穿上特製的衣服，主人立刻變身飛天遁地的超人；另外特務片中主角出任務時，通常會戴著耳機，而指揮中心總是有類似「天眼」這樣的系統可以掌控全局，網路似乎無往不透，隨時可以提供即時情報！這真是太酷了阿。但其實我著眼點並不是打打殺殺的戰爭機器，而是藉由系統輔助讓人完成不可能的任務，這卻適用各種類型的任務，例如「行銷任務」，「效率提升」，「投資決策」等等，機器的能力的確已經慢慢滲透到各工作領域了。相對於好來嗚英雄片，神奇寶貝感覺更親近了，主角小男孩藉由蒐集，培育，訓練神奇寶貝，可以對戰勝利贏得榮譽，他的工作就是訓練師，這對比的概念我覺得酷。


這裡的「機器」意涵絕對不是「製作精美的勞作」！那些年一些廠商做的各種無聊的人型機器人，還有甚至還走在台北街上以假亂真；或有些銀行門口放置了奇怪或裝可愛的服務機器人，永遠答非所問的！這些艮玩幾次就膩了，而我所謂的機器是例如 google map， search，或是三不五時會自動幫你整理回憶相片集的服務這類的，我想現在許多人也許已經離不開了！所以我對軟體部分比較有興趣。當然也有很厲害的硬體，印象中它們應該存在於自動化工廠中，或是我也看過會翻跟斗的機器人，但那不是我玩得起的，也不是我的菜。

整個想法概念是挺大的，不是單一平台或幾支程式就做得完的；其實它永遠做不完，所以我可以終其一生一直開發這個系統，每天都有事做，不無聊，哈哈。今天要搞定 background service 就是先要讓機器「活起來」。甚麼東西可以永遠活著？網站也許可算一半，因為他要隨時預備好某人會開啟瀏覽器打入一串網址送出一套訊息，網站必須做出正確的回應，但它只是活一半，因為若無人 request 它就不會動作，我想要的 background service 是要在正確的時間自動執行對應的動作，或是主動監控「系統狀態」，於特定條件達到時即時觸發動作，或至少做出訊息通知，讓主人決定要是否人意介入。

這種自動化服務在各種作業系統中是基本的存在，雲端服務廠商也一定有提供，如 azure app service 可以設定 web job，用 cron table 格式設定按時觸發，function app 也可設定 timer event，為何要自己幹一個？其實還有諸多考量，因為這服務不僅要活著，還要用統一的介面去「觸發任務的執行」，而觸發的任務不可限定平台。以當前資訊科技眾多工具和程式語言百花齊放的狀況看來，不可能期望用單一工具解決所有問題，有些任務用 python 去解，有些用 dotnet 去解 (我也只會這兩種，哈哈)，難保將來有更適合解特定問題的工具，必須可以一起協同運作，因此切出層次定義出 message queue 當中介就是很自然的設計，以下就是我的設計：


左上角 Heart-beat service 就是觸發一切的源頭，暫時設定一分鐘跳一次，每次跳動時檢查是否有動作需執行，若有則發出執行指示，丟到特定的 queue，各語言 queue listener 作法不一，所以必須依照運算平台各自做一個，如此處的 Dotnet Listener，Python Listener，這些粉紅底色所示的軟體元件就是需要「持續存活」的核心元件，除了 queue 是採用 cloudamqp 的雲端服務，其他就自己做。

以上已經鋪陳夠久，現在試著從無到有來開始實做，畫面依序紀錄：




建立好的範本專案可以直接執行，此 Worker 每秒吐出一則訊息告訴世界它活著。


把範本的 worker 改成 HBService


然後開始改造 HBService 的執行細節，就是查詢資料表，看看這一分鐘有沒有待執行任務，若有則發送訊息到對應的 queue，此動作由另一個物件代勞，cloudamqp 的說明文件很清楚並不困難。


所以此機制要運作還需要一個設定檔存留在資料庫，將來要增減任務只要修改資料即可，當然用個網頁去維護也是很簡單的事：


然後可以仿照 HBService 結構再建立一個 MQListenService，HBService 是一分鐘跳一下 (檢查一次)，MQListenService 則是「訂閱一個 queue」：


若有訊息則需要 parse and trigger job，這個 trigger job 就有學問了，不是直接呼叫某個 class method，而是「動態建立非特定類別的物件」；物件是動態指定的，但介面是固定的 (IJob)，也固定必須實做一個 Trigger() 的方法。當初寫這段搞很久，在 object oriented 的世界這是很基本的做法，但一般的應用開發者可能也不常用，只有「框架開發者」比較會用到，完成這功能也讓我爽很久！哈哈哈。


最後再把這兩個 worker 加到主程式中就大功告成了。


執行起來的樣子如下，這個 background service 丟在一台很爛的舊電腦也可以執行的很好，它不用很強只要「持續活著」，能在正確的時機喚醒對應的任務就是它最重要的角色。

https://youtu.be/L4mmqFa-Pq4

也許一堆雲端服務廠商可以提供這樣的服務，但別忘了我做這件事幾乎「零成本」，除了我的腦袋以外！這就是身為架構設計者和開發者我的價值了。

Python 的作法需要用不同的語法和技術去完成對應的功能，這就有緣再續了。

By Newman Chen 2022/6/11