[分享] 系統設計: 如何取消正在執行的工作任務
文字教學: https://bit.ly/3jFMwvS
教學影片: https://bit.ly/3WI0Wdx
範例程式: https://bit.ly/3Z0U6Bt
系統架構圖: https://i.imgur.com/VZyfv0M.png
本篇來聊聊『如何取消正在執行的工作任務』,當系統內有需要處理比較久或較多資源的任務,肯定會將這些任務丟到其他機器再執行,執行過程如果需要取消,會經過如上圖幾個步驟。先假設中間的過程不透過 Message Queue 機制,而是兩個服務進行溝通透過
RESTful 或 gRPC 方式。
## 使用情境
可以看到步驟一是 worker 會先發請求到後端服務,詢問目前正在執行的任務是否取消,這邊可以用一個長連接持續 30 秒或 1 分鐘才斷線。步驟二是 User 從 Web UI 端按下取消的按鈕。步驟三是後端服務接受到取消任務的請求,就回覆 Worker 到請求執行取消任務。
大家可以想看看此情境該如何設計流程,先不考慮多台後端服務的情境,也不考慮使用
Message Queue 的方式來實作。也許大家有想到一種方式,就是當使用者按下取消時 (到步驟三),後端服務將此任務的狀態改成取消。而 Worker 每次來詢問狀態 (步驟一),後端就再查詢一次就可以了 (步驟四),這方式也沒有不對,只是即時性效果比較差,如果是每 30 秒輪詢一次,就有可能 30 秒後才能取消任務,輪詢時間設定很短,又會造成過多不必要的連線請求。除了這種方式外,還有沒有其他方式可以不需要查詢資料庫就可以即時讓 Worker 知道目前任務狀態。
目前先講單機版解法,非常適用於要將服務部署在不同團隊內。
## 心得
本篇最主要是要用 Go 語言的 Channel 特性來處理兩個服務之間的溝通機制,大家可能想到的解法就是用 Message Queue 來處理,但是有時候把架構想的更簡單一點,用 Go
語言的特性來處理,那就減少一個服務的維運,未來要將此架構轉換到其他平台就會更簡單,其他部門有需求會是將整套服務架設在不同團隊內,這時候架構越簡單,除錯時間會越短。
--
AppleBoy Blog: http://blog.wu-boy.com
--
mq夠簡單了吧... 要轉換到其他地方也不難
火山表示___
..哪個語言沒內建mq
樓上那篇怎麼刪文了
mq外部化可以讓上下游達到stateless
subscriber每個語言都有 不太會自己實作多少秒觀察一次
除非服務很簡單,不然用外部mq對維護營運上比較容易
感覺只是為了寫而寫....
語言dependent又不scalable,算什麼系統設計?隨便
哪個mq維護成本也比維護這土炮架構好
MQ 設計好多了吧
25
[心得] 什麼是 gRPC,架構上為什麼要使用 gRPC影片: 由於上一支影片是介紹『三種好用的 gRPC 測試工具[1]』,這次就來錄製什麼是 gRPC,以及為什麼我們要導入此項技術 [1]: 由於團隊專案越來越多,共用的模組跟服務需求也越來越頻繁,故需要導入 gRPC 協定來 解決服務跟服務之間溝通的成本。用簡單的 10 分鐘來跟大家介紹什麼是 gRPC,以及16
[心得] 一套好用的傳輸檔案工具 (Go 語言工具)介紹一套好用的傳輸檔案工具 (用 Go 語言寫的) 各位在公司內部傳檔案時,大家能想到就是透過 Google Driver 或 Line,及其它任何你 想的到的做法,但是這邊會卡在多個問題 1. 沒 Google 帳號或沒在使用 Line 2. 檔案太大沒辦法傳送 (FB 限制)12
[心得] Go 語言管理 Concurrency 的三種方式部落格版: 教學影片: 程式範例: 00:00 三種控制方式 00:56 什麼時候使用 WaitGroup10
[心得] 用 Go 語言實現 Pub/Sub 模式相信大家都知道發布 / 訂閱模式,開發者可以透過第三方開源工具像是 Redis, NSQ 或 Nats 等來實現訂閱機制,本篇則是會教大家如何用 Go 語言寫出一個單機版本的 Pub/Sub 模式,在單一系統內非常輕量級,且不需要靠第三方服務就可以輕易實現。底下 會直接用單一訂閱 Topic 機制來撰寫 Publisher 及 Subscriber。 00:00 為什麼要用 Go 語言實現 Pub/Sub 模式8
[心得] 自動化監控網站運行服務 - Gatus部落格: 影片: ## 前言 不知道大家在部署網站後,怎麼明確讓大家清楚知道現在網站的運行狀況,就像 GitHub 就是提供整體運行的網頁,監控常用的操作指令,像是 Git Operations, Webhooks 或5
[心得] 處理服務讀取多個任務遇到的問題標題: 處理服務讀取多個任務遇到的問題 (Go 語言) 連結: 不同的服務都會有需要處理比較久的任務,這些任務是不能即時執行完成,才回應給前端 ,這樣使用者體驗會非常的差。將類型的任務存在資料庫或放在消息對列就是一種處理方