Temporal 的起源

Temporal 的起源可以追溯到 2004 年，當時兩位創辦人在 AWS 共同參與了 SQS message queue 的基礎建設，並打造了 Simple Workflow Service (SWF)。他們在那個階段就意識到：單純的 Queue-based 並不是理想的系統構建方式。

之後，他們持續投入與 queue 和 workflow 相關的專案，直到在 Uber 再度合作，開發出 Cadence —— Temporal 的前身。後來兩位創辦人認為這個模式可行，便共同創立公司並進行大幅改寫並維持開源。雖然 Temporal 在 2019 年才正式誕生，算是相對年輕的專案，但背後其實凝聚了多年累積的經驗。

有趣的是，SQS 在 2004 就推出，雲端服務商帶動了微服務的熱潮，但事實上連他們的工程師也還沒真正搞懂微服務...嗎？而另一方面，BPM 陣營在 2000 年前後就已經發展了 Workflow Engine，只是那時並沒有針對 大規模分散式系統 (massive scale) 的挑戰去設計。

架構簡介

1. 部署模式
   • Temporal 可以自己架（Self-hosted），也可以直接用官方的 Cloud。
   • 本機安裝測試也很方便。Quickstart - Setup
2. Temporal Service 的角色
   • 中間的 Temporal Service 就是流程引擎。
   • 它把分散式系統最麻煩的四件事（Queue、狀態儲存、Retry、Timer）都內建好。
   • 同時還會保存 完整 Event History，支援決定性重播 (deterministic replay)。
   • 開發者只要專注在寫流程邏輯，不必自己實作這些基礎設施。
3. Worker 的角色
   • 透過 SDK 我們會建立 Worker。
   • Worker 可以負責推進 Workflow，或者負責處理實際工作單元 Activity。
   • 它會透過 gRPC long polling 連到 Server 的 Task Queue，領取任務並執行。
   • Workflow 在 Worker 裡以「單執行緒，決定性重播」方式執行，確保順序一致。
4. Workflow Operations（左邊）
   • 也是用 SDK 撰寫：啟動流程、與流程互動 Signal、Query、Update、Cancel。
   • 這些操作都會進到 Temporal Service，轉成任務放進 Task Queue，由對應的 Worker 處理。
   • 所有輸入和輸出都會被寫進 Event History，確保有序且冪等。
5. 跟傳統流程引擎的不同
   • 流程圖是上傳到引擎，由引擎內部執行。先前提到的 BPM, Conductor 等皆是以這樣的方式執行。
   • Temporal：流程定義寫在 Worker（程式碼）裡，Server 負責協調 Queue、狀態、Retry、Timer。
   • 好處：把「流程定義」外推到 Worker，水平擴展更容易，不會被單一流程引擎卡住效能瓶頸。並且程式碼版本控制、測試、CI/CD 更接近開發者的平時的操作方式。

Temporal SDK 介紹

Temporal 的 SDK 不只是「連線 Server 的用戶端」，使用起來更像是一個框架（framework）：它提供 Worker 執行環境、決定性 Workflow 引擎、Activity 呼叫抽象、重試/超時/計時器、互動（Signal/Query/Update）等完整能力。因此需要學習它的 API 與設計方法。

1. 為什麼 SDK 是重點
   • 不只是通訊層：SDK 內建 Workflow 執行模型與「決定性重播」，不是薄薄的一層 RPC。
   • 抽象複雜度：把 Queue、狀態、重試、Timer、互動通道抽象成直覺 API，讓流程用「可持久的程式碼」描述。
   • 一致的開發體驗：同樣的概念在多語言實作（型別/語法不同），降低跨語言協作成本。
2. SDK 提供的核心能力
   • Worker 執行環境：連到 Task Queue、領取/回報任務、心跳與心跳超時、健全關閉。
   • Workflow 執行引擎：單執行緒、決定性、虛擬時間（time skipping）、重播還原進度。
   • Activity 抽象：透過 stub 呼叫，支援重試、各類超時（schedule/start/heartbeat），心跳回報長任務進度。
   • 互動機制：Signal（外部事件）、Query（唯讀查詢）、Update（具狀態變更且可驗證）。
   • 子流程與並行：Child Workflows、並行/扇出扇入、補償/Saga 等協調樣式。
   • 時間與排程：Timer、sleep、cron workflow。
   • 資料轉換與相容性：DataConverter/PayloadCodec（序列化、壓縮/加解密）、Workflow 版本化/patch 指南。
   • 測試工具：本地測試環境、虛擬時間加速、斷言 Event History。
   • 可觀測與攔截：Logging/metrics/tracing、Interceptors 中介管線。
   • 連線與安全：TLS/mTLS、Namespace 與 Worker 客戶端設定。
3. 語言支援
   • 官方 SDK：Go、Java、TypeScript、Python、.NET。

基本運作原理介紹

1. 流程架構概念

   • Temporal 和傳統流程引擎一樣，以 引擎為核心跑流程。
   • Client 呼叫 Start → Temporal Service 收到請求，放入 Task Queue。
   • 不同的是，Temporal Service 不只是分派任務，它還會把每個事件記錄在 Event History 裡，讓流程能完整追蹤與還原。

2. Workflow 與 Activity 的執行模式

   • Workflow 不會「一次把方法跑到底」。
   • 每一行呼叫 Activity 的程式碼，都會先通知 Temporal Service → 放進 Task Queue → 再由對應的 Worker 取回執行。
   • 執行結果再回報給 Service，Workflow 才會往下一步。

3. Event History（事件歷史）

   • Temporal 會把每一步的 輸入、輸出、狀態都寫進 Event History：
     • 哪個 Activity 開始/完成
     • 哪個 Timer 還在等待
     • Workflow 當下的進度
   • 這確保：
     • Workflow 可以在 Worker 重啟後 重放 (replay)，還原當下進度。
     • 所有事件的順序都是 可驗證、有序的。

4. 錯誤處理與重試

   • 如果步驟失敗，不需要自己寫 try/catch。
   • Temporal 會根據 Workflow/Activity 的 Retry 設定自動重試，直到成功或達到上限。
   • 這也是為什麼程式碼看起來很「乾淨」──因為錯誤處理等抽象化交給 Temporal。

結語

本篇介紹了 Temporal 基本架構、SDK 及基本運作原理，希望讀者在還沒開始寫扣之前，就對這個框架級的工具有一定的了解，下一篇就來建立第一個 Workflow 吧！