Temporal: durable execution cho quy trình nghiệp vụ kéo dài và dễ đứt gãy
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Temporal là gì và khi nào đáng cân nhắc cho quy trình kéo dài nhiều ngày
Temporal tự định vị là nền tảng durable execution, tạm hiểu là “thực thi bền vững”: máy chủ chạy các Workflow, tức đơn vị logic nghiệp vụ, sao cho quy trình tự vượt qua lỗi gián đoạn và tự thử lại thao tác thất bại. Kho này chứa mã máy chủ viết bằng Go; mã Workflow, Activity và Worker của doanh nghiệp dùng SDK riêng của từng ngôn ngữ. Dự án khởi nguồn từ bản fork của Cadence do Uber phát triển. [1][5]
Temporal đáng cân nhắc khi quy trình có nhiều bước gọi sang hệ thống khác, phải chờ con người hoặc chờ thời gian trôi qua, và không được “quên” mình đang ở đâu sau khi máy chủ khởi động lại. Tài liệu History Service minh họa bằng một workflow gọi activity rồi ngủ ba mươi ngày; bộ hẹn giờ ấy được lưu thành task bền vững chứ không nằm trong bộ nhớ tiến trình. [3]
Nếu nhu cầu chỉ là vài tác vụ định kỳ hay một pipeline dữ liệu tuyến tính, Temporal là lựa chọn quá cồng kềnh vì chi phí học mô hình và vận hành cụm máy chủ là đáng kể. Khuyến nghị: thử trên một quy trình dài hạn có chủ sở hữu nghiệp vụ rõ ràng trước khi mở rộng; đây là nhận định phân tích, chưa có phép đo.
Một đơn hàng kéo dài ba tuần: vì sao cron, hàng đợi và bảng trạng thái tự viết dễ gãy
Quy trình dài thường được ghép từ một cột trạng thái trong cơ sở dữ liệu, một tiến trình cron quét định kỳ, một hàng đợi tin nhắn và vài đoạn mã thử lại rải rác. Tổ hợp ấy hiếm khi trả lời rõ: tiến trình chết sau khi gửi tin nhắn mà trước khi cập nhật trạng thái thì sao, bước nào có thể đã chạy hai lần.
Temporal lấy các yêu cầu ngược lại làm nền móng: thực thi workflow phải đúng ngay cả khi tiến trình máy chủ hay tiến trình của người dùng gặp lỗi tạm thời, hệ thống phải mở rộng tới số lượng lượt thực thi đồng thời rất lớn, và mã của người dùng vẫn chạy trong môi trường do họ sở hữu. [2]
Lập trình viên nhờ đó viết quy trình như một hàm tuần tự, còn ghi nhớ tiến độ, hẹn giờ và thử lại được đẩy xuống nền tảng. Đổi lại, đội phải hiểu ranh giới workflow và activity, giữ kỷ luật tất định và vận hành thêm một hệ phân tán; chỉ đáng làm khi thiệt hại do quy trình đứt gãy lớn hơn cái giá ấy.
Frontend, History, Matching và Worker: ai giữ trạng thái, ai chạy mã nghiệp vụ
Tài liệu kiến trúc chia hệ thống làm hai phía. Phía người dùng có User Application, dùng SDK như gRPC client để khởi động, hủy và tương tác với workflow, cùng các Worker chạy mã Workflow và Activity. Phía cụm gồm Frontend, History, Matching và Internal Workers; doanh nghiệp có thể tự vận hành cụm cùng cơ sở dữ liệu hoặc dùng Temporal Cloud. [2]
History Service được chia thành shard, mỗi shard phụ trách một tập lượt thực thi: xử lý RPC, đưa task sang Matching và lưu trạng thái cần cho thực thi bền vững. Tổng số shard cố định từ lúc tạo cụm; quyền sở hữu shard giữa các máy do giao thức thành viên điều phối. Matching Service quản lý các Task Queue mà Worker liên tục thăm dò. [2][3]
Nền móng dữ liệu là event sourcing, tức lưu dưới dạng chuỗi sự kiện: mỗi lượt thực thi có lịch sử chỉ ghi nối thêm, đủ để dựng lại toàn bộ trạng thái khi phát lại. Máy chủ còn lưu và đệm trong bộ nhớ mutable state, bản tóm tắt trạng thái hiện tại, để xử lý nhanh. Lớp lưu trữ có triển khai cho Cassandra, MySQL, PostgreSQL và SQLite; tài liệu CHASM mô tả thêm một khung coi Workflow chỉ là một loại máy trạng thái ứng dụng. [2][3][6]
Từ StartWorkflowExecution tới WorkflowExecutionCompleted: hành trình của một lượt chạy
Ứng dụng gửi StartWorkflowExecution tới Frontend, Frontend chuyển sang History. History khởi tạo lịch sử với WorkflowExecutionStarted và WorkflowTaskScheduled, ghi mutable state cùng một transfer task, rồi bộ xử lý hàng đợi gọi Matching để thêm Workflow Task. Worker thăm dò, nhận task kèm lịch sử, chạy mã workflow tới khi bị chặn bởi lời gọi activity hoặc timer, rồi gửi lại command như ScheduleActivityTask. [4]
Worker chạy activity xong thì gửi RespondActivityTaskCompleted, kết quả được ghi vào sự kiện ActivityTaskCompleted. Timer đến hạn sinh sự kiện TimerFired và một Workflow Task mới. Command CompleteWorkflowExecution sinh WorkflowExecutionCompleted, kéo theo task cập nhật visibility và xử lý thời hạn lưu giữ. Nếu activity thất bại, máy chủ đặt timer thử lại và ghi số lần thử vào mutable state; lượt thử lại không thêm sự kiện vào lịch sử. [3][4]
Mutable state và task được ghi trong cùng giao dịch, còn việc task chắc chắn tới Matching dựa trên mẫu transactional outbox. Hệ quả cho thiết kế: tham số, kết quả activity và tín hiệu có thể nằm lại trong lịch sử vì một số sự kiện mang payload, tức dữ liệu đính kèm yêu cầu; lịch sử vì thế là dữ liệu nghiệp vụ cần quản trị. [3]
Kỷ luật tất định: điều kiện để lịch sử sự kiện phát lại được
Tài liệu kiến trúc yêu cầu mã workflow tất định và không có tác dụng phụ, trừ ngoại lệ được quy định; mã activity phải idempotent, tức chạy lặp lại không gây thêm hậu quả, hoặc được đánh dấu không thử lại. Workflow ra quyết định, còn activity làm việc với thế giới bên ngoài theo ngữ nghĩa ít nhất một lần hoặc nhiều nhất một lần. [2]
Ràng buộc này đến thẳng từ event sourcing: mỗi Workflow Task chạy tiếp mã workflow trên nền lịch sử đã có, nên nếu mã đọc đồng hồ hệ thống, sinh số ngẫu nhiên hay gọi API trực tiếp, lần phát lại có thể rẽ sang nhánh khác. Gọi cổng thanh toán, gửi tin nhắn hay ghi vào phần mềm kế toán đều phải nằm trong activity. [2][3]
Đội phát triển nên biến kỷ luật này thành quy tắc review mã: workflow không truy cập mạng hay tệp, mỗi activity có khóa idempotency gắn với mã nghiệp vụ, và việc sửa mã workflow đang chạy dở tuân theo hướng dẫn versioning của SDK đã chọn. Đây là khuyến nghị của bài.
Những khả năng đối chiếu được trong tài liệu tại commit khảo sát
Ở mức nền tảng, tài liệu xác nhận: workflow định nghĩa bằng mã; máy chủ tự xử lý lỗi gián đoạn và thử lại thao tác thất bại; timer bền vững kéo dài nhiều tuần; Query Task đọc trạng thái mà không làm workflow tiến lên; History Service nhận các yêu cầu Start, Cancel, Query, Update, Signal và Reset; workflow có thể khởi động workflow con hoặc gửi tín hiệu sang workflow khác. [1][2][3]
README hướng dẫn cài Temporal CLI, chạy temporal server start-dev để có máy chủ phát triển cục bộ, mở Web UI ở cổng 8233 và dùng CLI liệt kê namespace, workflow; bộ mẫu có cho Go và Java. Nexus dùng giao thức Nexus RPC để gọi thao tác vượt ranh giới namespace và cụm, bật mặc định từ phiên bản 1.26.0; callback giao kết quả workflow được thử lại tới khi thành công, thất bại vĩnh viễn hoặc hết thời hạn lưu giữ. [1][7]
Bên trong máy chủ, gói backoff cung cấp chính sách thử lại cho lời gọi gRPC giữa các dịch vụ, với chính sách riêng cho lỗi ResourceExhausted; CHASM có các thư viện workflow, scheduler và nexusoperation. Đây là cơ chế nội bộ, không phải API ứng dụng gọi trực tiếp. [5][6]
Đội ngũ nào hưởng lợi từ Temporal, đội ngũ nào nên chờ
Temporal hợp với đội backend vận hành nhiều quy trình giao dịch nhiều bước: đơn hàng thương mại điện tử, điều phối giao vận, hoàn tiền, cấp phát hạ tầng hay phối hợp microservice. Điểm chung là mỗi bước gọi một hệ thống khác, thời gian chờ khó đoán và lỗi giữa chừng gây thiệt hại thật.
Tổ chức có vài kỹ sư sẵn sàng học mô hình workflow và activity, cùng người vận hành được cơ sở dữ liệu, sẽ khai thác tốt nhất. Nếu không muốn tự vận hành cụm, tài liệu nhắc tới Temporal Cloud; bài không đánh giá điều khoản hay chi phí của dịch vụ này. [2]
Nhóm phân tích chủ yếu chạy truy vấn theo lịch, cửa hàng nhỏ chỉ cần nhắc lịch hẹn hay đơn vị không có người viết mã sẽ thấy Temporal quá nặng. Doanh nghiệp vừa có xưởng và khâu giao lắp, như tình huống dưới đây, nằm ở vùng giữa: đáng thử nếu có người viết mã ổn định.
Đề xuất cho cửa hàng nội thất đóng theo yêu cầu: mỗi đơn hàng là một workflow
Tình huống giả định: một cửa hàng nội thất có showroom và xưởng gia công, nhận đóng tủ bếp, sofa theo kích thước. Mỗi đơn đi qua báo giá, đặt cọc, đo đạc tại nhà, duyệt bản vẽ, sản xuất hai đến bốn tuần, giao và lắp đặt, thu phần còn lại và hỏi thăm sau ba mươi ngày. Thông tin hiện nằm rải rác trong bảng tính, nhóm chat và trí nhớ nhân viên.
Đề xuất là chạy mỗi đơn như một workflow với mã đơn làm Workflow ID; theo tài liệu CHASM, BusinessID như Workflow ID chỉ được giải phóng để dùng lại khi lượt thực thi đã đóng, nên cách này giúp tra cứu theo mã nghiệp vụ và hạn chế mở trùng đơn. Activity lo việc có tác dụng phụ: tạo phiếu thu, gửi tin nhắn, cập nhật bảng sản xuất, đặt xe giao. [2][6]
Signal đưa vào workflow các sự kiện như tiền cọc đã về, bản vẽ được duyệt, xưởng báo xong. Timer thay cho việc “nhớ gọi lại”: chờ duyệt bản vẽ 48 giờ rồi nhắc, chờ 30 ngày sau lắp đặt rồi gửi khảo sát bảo hành. Nhân viên xem tiến độ qua Query. Khi khách hủy, nhánh hoàn cọc dùng activity có khóa idempotency theo mã đơn để thử lại không thành chuyển tiền hai lần. Payload chỉ mang mã đơn và mã khách; số điện thoại, địa chỉ nằm trong phần mềm quản lý khách hàng. [2][3]
Thước đo của đề xuất là số đơn bị bỏ sót giữa các khâu, số lần khách phải hỏi lại tiến độ và giờ công đối chiếu. Đây là mô hình đề xuất, chưa phải dự án đã triển khai.
Tự vận hành cụm Temporal: lớp lưu trữ, số shard và tiến trình worker
Lệnh temporal server start-dev trong README phục vụ phát triển, không phải cấu hình production. Một cụm tự quản phải chốt lớp lưu trữ chính, nơi lưu dữ liệu visibility (có thể là cơ sở dữ liệu khác với nơi chứa trạng thái workflow) và đặc biệt là số History Shard, vì con số này cố định từ lúc tạo cụm. [1][3]
Worker chạy trên hạ tầng của doanh nghiệp, nên đóng gói, giám sát, tự khởi động lại và mở rộng worker là việc của đội ứng dụng. Máy chủ dùng tệp cấu hình tĩnh và dynamic config; tài liệu Nexus cho thấy một số khóa cấu hình đổi tên hoặc đổi cách dùng giữa các phiên bản 1.30, 1.31 và 1.32, nên mỗi lần nâng cấp cần đọc ghi chú tương ứng. [2][7]
Tài liệu Nexus cũng liệt kê metric cho hàng đợi outbound, bộ giới hạn tốc độ và circuit breaker, bộ ngắt mạch mở khi lỗi liên tiếp tới cùng một đích vượt quá năm lần. Dashboard, cảnh báo, sao lưu, diễn tập khôi phục, retention cho từng namespace và runbook khi worker ngừng thăm dò vẫn do đội vận hành tự dựng. [7]
TLS, callback và lịch sử sự kiện: các bề mặt dữ liệu cần bảo vệ
Bề mặt nhạy cảm nhất là lịch sử sự kiện: một số sự kiện chứa payload, kết quả activity được ghi lại, và dữ liệu chỉ bị xóa sau khi lượt thực thi đóng và hết thời hạn retention của namespace. Cần tối thiểu hóa dữ liệu cá nhân trong tham số và kết quả, ưu tiên truyền mã tham chiếu, và cân nhắc mã hóa phía ứng dụng trước khi gửi payload. [3][4][6]
Kênh truyền nên được mã hóa: kho có hướng dẫn dùng openssl tạo CA cục bộ và chứng chỉ cho bên được gọi như cơ sở dữ liệu, bên gọi như máy chủ, dành cho môi trường phát triển. Với callback của Nexus, tài liệu cảnh báo mẫu ký tự đại diện và HTTP không mã hóa chỉ dành cho phát triển; production nên giới hạn host và tắt AllowInsecure vì HTTP làm tăng nguy cơ tấn công xen giữa. [7][8]
Web UI và CLI cho phép liệt kê và xem workflow, nên quyền vào các giao diện này tương đương quyền đọc dữ liệu nghiệp vụ. Bài chưa khảo sát cơ chế xác thực và phân quyền của máy chủ; cần kiểm tra ở đúng phiên bản sẽ triển khai. [1]
MIT ở thư mục gốc, bản quyền Uber trong lịch sử mã và CLA cho người đóng góp
Tệp LICENSE ở gốc kho tại commit khảo sát là MIT, ghi bản quyền Temporal Technologies (2025) và Uber Technologies (2020). MIT cho phép dùng, sửa đổi, phân phối và bán bản sao, với điều kiện giữ thông báo bản quyền và giấy phép; phần mềm được cung cấp nguyên trạng, không bảo hành, và văn bản không cấp quyền gì về nhãn hiệu. [9]
Kho có thêm tệp giấy phép trong thư mục con: common/persistence/visibility/store/query mang LICENSE riêng, vẫn là MIT nhưng thêm chủ sở hữu bản quyền Xargin (2017); bản build tùy biến khi phân phối lại phải giữ đủ các thông báo này. Bài chưa rà soát mọi thư mục con. [10]
Người đóng góp mã phải ký CLA cá nhân với Temporal Technologies, cấp cho công ty và người nhận phần mềm quyền bản quyền và quyền sáng chế với phần đóng góp; nếu chủ lao động có quyền với sản phẩm trí tuệ của nhân viên, cần sự cho phép hoặc CLA cấp doanh nghiệp. MIT ở đây chỉ bao phủ mã máy chủ tại commit này, không tự áp dụng cho SDK ở kho khác, thư viện phụ thuộc hay Temporal Cloud. [11][1][2]
Nguồn lực thật sự tốn kém: thời gian kỹ sư hiểu mô hình, hơn là máy chủ
Giả định lập kế hoạch: doanh nghiệp vừa, vài trăm workflow mở cùng lúc, mỗi workflow vài chục sự kiện. Nguồn lực chính là con người: một đến hai kỹ sư backend dành vài tuần để nắm workflow, activity, signal, timer và quy tắc tất định, cộng thời gian viết quy trình đầu tiên và bộ kiểm thử.
Hạ tầng tự quản gồm máy cho các dịch vụ Frontend, History, Matching và Internal Workers, một cơ sở dữ liệu có sao lưu, có thể thêm kho visibility riêng, cùng máy chạy worker của ứng dụng. Môi trường thử có thể gộp trên một máy ảo, production nên tách để có dự phòng; dung lượng tăng theo số sự kiện và thời hạn retention. [2][3]
Chi phí định kỳ gồm nâng cấp, theo dõi metric, xử lý sự cố cơ sở dữ liệu và trực khi worker ngừng. Temporal Cloud chuyển phần vận hành cụm sang nhà cung cấp nhưng phát sinh phí dịch vụ và câu hỏi về nơi lưu dữ liệu; bài không nêu giá vì không có nguồn chính thức. [2]
Đặt Temporal cạnh hàng đợi tin nhắn, máy trạng thái tự viết và công cụ điều phối dữ liệu
Tự xây bằng bảng trạng thái, cron và hàng đợi như RabbitMQ hay Kafka cho toàn quyền kiểm soát; đổi lại, đội tự giải bài toán thử lại, timer dài ngày, chống chạy trùng và khả năng quan sát. Cách này hợp khi quy trình ngắn, ít bước và hạ tầng hàng đợi đã sẵn.
Nhóm công cụ điều phối pipeline dữ liệu như Apache Airflow, Prefect hay Dagster là một hướng khác. Với đơn hàng, thanh toán hay quy trình có người tương tác kéo dài nhiều tuần, nên kiểm chứng trực tiếp cách từng công cụ xử lý timer dài, tín hiệu từ bên ngoài và chống lặp thao tác tiền.
Các engine cùng hướng durable execution, trong đó có Cadence mà Temporal được fork từ đó, hay dịch vụ workflow do nhà cung cấp đám mây quản lý, nên được so theo cùng bộ tiêu chí: mô hình lập trình, ngôn ngữ SDK, cách lưu lịch sử, khả năng tự host, giấy phép và công sức vận hành. Thiếu phép đo độc lập, đây là khung so sánh chứ không phải bảng xếp hạng. [1]
Giới hạn được chính tài liệu nêu ra và các tình huống không nên chọn Temporal
Tài liệu CHASM thừa nhận Workflow có giới hạn thật: quá chậm hoặc quá nặng với một số bài toán, không mở rộng theo mọi chiều như hàng triệu signal hay payload lớn, và phức tạp quá mức khi một giải pháp chuyên biệt đơn giản hơn. Vì vậy không nên dùng workflow cho luồng sự kiện khối lượng rất lớn hay để chở tệp lớn trong payload. [6]
Route HTTP của Nexus được ghi là thử nghiệm, có thể đổi không báo trước; Nexus chỉ hỗ trợ một cụm vì việc sao chép registry endpoint mới nằm trong kế hoạch; đổi tên endpoint có thể làm workflow kẹt trong vòng lặp thử lại. Số History Shard không đổi được sau khi tạo cụm, nên sai lầm định cỡ ban đầu rất khó sửa. [3][7]
Không nên chọn Temporal khi đội không có người viết mã, khi quy trình chỉ là vài lệnh chạy theo lịch, hoặc khi tổ chức không vận hành nổi cơ sở dữ liệu mà cũng không dùng được dịch vụ quản lý. [2]
Thí điểm sáu tuần với một loại đơn hàng: chỉ số, giai đoạn và điểm dừng
Tuần 1–2: chọn một loại đơn như tủ bếp đóng theo kích thước, mô hình hóa workflow trên máy chủ phát triển, viết activity giả lập cho tin nhắn và kế toán. Điều kiện sang giai đoạn sau: mọi bước hiện tại đều có chỗ trong workflow, và review mã xác nhận workflow không gọi mạng hay đọc đồng hồ hệ thống.
Tuần 3–4: chạy song song với bảng tính trên đơn thật, chưa nhắn tin cho khách. Đo tỷ lệ đơn có trạng thái khớp thực tế qua đối chiếu hằng tuần, tỷ lệ timer nhắc đúng hạn và số sự kiện trung bình mỗi workflow. Thử lỗi có chủ đích: tắt worker giữa lúc activity chạy, khởi động lại cơ sở dữ liệu, cắt mạng tới API tin nhắn, rồi xác nhận không có tin trùng hay đơn mất bước.
Tuần 5–6: bật nhắn tin thật cho nhóm khách đã đồng ý, thử sửa mã workflow khi còn đơn đang mở, diễn tập khôi phục từ bản sao lưu. Dừng nếu có đơn mất trạng thái không giải thích được, thao tác tiền bị lặp hoặc công sức vận hành vượt khả năng đội; chỉ mở rộng khi chủ cửa hàng và người phụ trách kỹ thuật ký nhận tiêu chí. Kế hoạch chưa có số liệu đo.
Kết luận: đổi kỷ luật lập trình lấy trí nhớ bền vững cho quy trình
Temporal giải một bài toán rõ ràng: giữ cho quy trình nhiều bước, kéo dài và dễ đứt gãy tiếp tục đúng chỗ sau sự cố. Event sourcing, History shard và Task Queue được mô tả đủ chi tiết để đánh giá, và giấy phép MIT ở gốc cho phép tự host phần máy chủ. [2][3][9]
Cái giá là kỷ luật: workflow tất định, activity idempotent, cụm máy chủ và cơ sở dữ liệu vận hành nghiêm túc, trong khi Nexus còn đang hoàn thiện. Doanh nghiệp vừa nên thử trên một quy trình giá trị cao như đơn hàng đặt riêng trước khi mở rộng.
Nếu việc cần làm chủ yếu là chạy báo cáo theo lịch, hãy chọn công cụ đơn giản hơn. Nếu thiệt hại đến từ những đơn hàng rơi giữa các hệ thống, Temporal xứng đáng vào danh sách thử nghiệm.
Nguồn, commit và giới hạn của phương pháp nghiên cứu
Temporal thuộc nhóm Tự động hóa và tích hợp của loạt nghiên cứu mã nguồn mở xuất hiện trong GitHub Trending năm 2026. Bằng chứng tuyển chọn là trang lưu trữ Trending ngày 01/01/2026, nơi temporalio/temporal đứng thứ ba ở mục Go. [12] Bảng ứng viên nội bộ ghi nhận 22 lần xuất hiện từ 01/01 đến 02/10/2026. Lưu ý về phạm vi: kho lưu trữ do bên thứ ba duy trì này chỉ có bốn danh sách Python, Go, JavaScript, Swift và thiếu trang ngày 03/09, 12/10, nên không thay được thống kê Top 100 chính thức của GitHub.
Đối chiếu dựa trên các tệp tại commit 30c625664a2bbc1bd4cd9022d71982cc473e6979 (ngày commit 10/10/2026), kiểm tra ngày 12/10/2026: README, LICENSE, tài liệu kiến trúc tổng quan, History Service, vòng đời workflow, retry, CHASM, Nexus, hướng dẫn chứng chỉ TLS, văn bản CLA và một LICENSE ở thư mục con. Nhánh chính có thể khác bản phát hành ổn định. [1][2][3][4][5][6][7][8][9][10][11]
Toàn bộ nhận định dựa trên việc đọc tài liệu với sự hỗ trợ của AI. Không có bước cài đặt, chạy thử, đo hiệu năng hay triển khai Temporal nào; phần cửa hàng nội thất, ước tính nguồn lực và lịch thí điểm là phân tích của người viết. Bài không phải công trình khoa học đã qua bình duyệt, và số sao GitHub không được dùng làm thước đo.
Xem mã nguồn Temporal trên GitHub