castomFLOW
Mở castomFLOW

Những lần chạy bạn có thể tin tưởng

Chẳng ai để ý đến một tự động hóa cho đến khi nó gửi thứ gì đó hai lần

Rồi mọi người đều để ý. Bốn cơ chế trên trang này tồn tại vì những lỗi của loại phần mềm này luôn là bốn lỗi giống nhau, và tất cả đều tránh được bằng thiết kế chứ không bằng sự cẩn thận.

Chạy mô phỏng trước khi xuất bản

Đẩy một bản ghi thật qua một quy trình đang tắt, và đọc lại chính xác điều gì sẽ xảy ra: đường đi đã chọn, mọi giá trị ở mọi bước, nội dung của mọi thông điệp, và yêu cầu sẽ được gửi đến từng hệ thống bên ngoài.

Không gì rời khỏi tòa nhà. Không gửi e-mail, không lập hóa đơn, không thử trừ tiền, không ghi dòng nào. Các cuộc gọi bên ngoài được ghi lại dưới dạng ý định, kèm payload sẽ được gửi, để bạn thấy ánh xạ có đúng không trước khi nó trở thành vấn đề của ai đó.

Mô phỏng là cách bạn trả lời câu hỏi khiến người ta ngại bật một tự động hóa: thứ này thực sự sẽ làm gì?

Mô phỏng · đơn hàng 88 214Không gửi gì
  • 1Xác thực địa chỉKhớp. Sẽ ghi 6 trường.
  • ?Điều kiệnĐơn trên 1 000 zł? Không — 289,00 zł. Đã đi đường ngắn.
  • 3Hóa đơnSẽ POST sang hệ thống xuất hóa đơn. Payload hiển thị đầy đủ.
  • !Bị bắt tại đâyThuế suất VAT được ánh xạ từ nhầm trường. Phát hiện trong một lần mô phỏng thay vì trong hộp thư của kế toán.

Đã gửi: không có gìĐã tính phí: không có gì

Một lượt chạy đi theo phiên bản mà nó vào lúc bắt đầu

Xuất bản thay đổi lên một quy trình không ảnh hưởng đến các lượt chạy đã ở trong đó. Mỗi lượt chạy được ghim vào phiên bản mà nó bắt đầu và hoàn tất theo phiên bản đó, dù mất bao lâu và bạn viết lại bao nhiêu trong lúc đó.

Nhờ vậy bạn có thể tái cấu trúc một quy trình trong khi có mười nghìn người đang đi giữa chừng, và mỗi người đều hoàn tất luồng đã được hứa với họ. Cách khác — thiết kế mà toàn bộ đường đi phía sau được dựng sẵn ngay khi vào — chính là lý do việc chỉnh sửa một tự động hóa đang chạy cảm giác nguy hiểm trong hầu hết các công cụ. Ở đây nó chẳng có gì đáng chú ý.

Các lượt chạy mới nhận phiên bản mới ngay từ khoảnh khắc bạn xuất bản. Phiên bản của một lượt chạy được ghi trên chính lượt chạy đó, nên câu hỏi về hành vi trong tháng Ba vẫn có câu trả lời vào tháng Chín.

Chỉnh sửa khi đang chạyv4 → v5
  • 1Trước2 918 lượt chạy đang thực hiện, tất cả trên v4. Một số đang chờ hai ngày.
  • 2Xuất bản v5Hai bước được đổi thứ tự, một thông điệp được viết lại.
  • 3Sau2 918 lượt đó hoàn tất theo v4. Mọi thứ bắt đầu từ 11:40 chạy v5.
  • §Không ainhận được nửa quy trình này và nửa quy trình kia.

Phiên bản được ghi trên mọi lượt chạyCác phiên bản cũ được giữ lại

Thử lại không thể gửi trùng lặp

Một bước là hàm thuần túy của đầu vào, và các hiệu ứng của nó được commit cùng với việc lượt chạy tiến sang bước tiếp theo. Không có khoảng thời gian mà thông điệp đã đi ra nhưng lượt chạy chưa biết điều đó.

Đó là toàn bộ mẹo, và đó là tính chất cấu trúc chứ không phải lời hứa. Một worker bị giết giữa bước — một lần triển khai, một lỗi sập, một máy biến mất — để lượt chạy đúng ở chỗ nó đang đứng. Một worker khác nhặt lên và chạy lại bước đó. Vì hiệu ứng và việc tiến bước commit như một, hoặc cả hai đều xảy ra hoặc không cái nào xảy ra.

Các lời gọi ra ngoài tới hệ thống hỗ trợ idempotency key đều mang một khóa, suy ra từ lượt chạy và bước, để phía bên kia cũng nhận ra lần lặp lại.

Worker bị giết giữa lúc gửiĐã khôi phục
  • 1Bước 5 bắt đầuGửi thông báo giao hàng.
  • ✕Worker chếtTriển khai. Chưa có gì được commit.
  • 2Được nhặt lênMột worker khác thấy lượt chạy vẫn ở bước 5.
  • ✓Gửi đúng một lầnKhách hàng nhận được một email, không phải hai.

Hiệu ứng commit cùng với việc tiến bướcIdempotency key cho mỗi lượt chạy và mỗi bước

Một nhật ký được viết cho con người đọc

Mọi lượt chạy, mọi bước, nhánh nó đi và giá trị quyết định nhánh đó. Thời gian cho từng bước. Request và response của mỗi lời gọi bên ngoài, với thông tin xác thực đã được che. Phiên bản mà lượt chạy đang dùng. Lượt chạy đang chờ ở đâu và đến khi nào.

Khi ai đó hỏi đơn đặt ngày 14 thì sao, có một câu trả lời, và tìm ra nó mất một phút thay vì một buổi chiều đối chiếu nhật ký của ba hệ thống.

Các lượt chạy bị lỗi được tập hợp ở một nơi với lý do được nhóm lại, nên “41 lỗi trong đêm” sẽ dẫn tới “một nhà cung cấp trả về 503 trong chín phút” thay vì 41 lần điều tra riêng lẻ.

Qua đêm, đã nhóm41 lỗi
  • 1Một nguyên nhânAPI nhà cung cấp trả về 503 từ 02:41 đến 02:50.
  • 2Chuyện gì đã xảy raCả 41 lượt được thử lại; 39 lượt thành công ở lần thứ hai.
  • 3Còn lạiHai lượt đã dừng và đang chờ một người xử lý. Cả hai được liệt kê cùng với dòng dữ liệu bị lỗi.
  • §Không phải 41lần điều tra. Chỉ một, cùng một quyết định về hai bản ghi.

Thông tin xác thực đã được chePhiên bản đã được ghi lại

Những điều chúng tôi không khẳng định

Chúng tôi không công bố con số thời gian hoạt động trên trang marketing, vì một con số không có khoảng thời gian đo lường và định nghĩa về “đang hoạt động” chỉ là trang trí. Nếu bạn cần nó theo hợp đồng, hãy hỏi và chúng tôi sẽ trao đổi về những gì chúng tôi thực sự cam kết được.

Chúng tôi cũng không thể khiến API của người khác trở nên đáng tin cậy. Nếu một nhà cung cấp bị sập, quy trình phụ thuộc vào nó sẽ chờ, thử lại và cuối cùng dừng lại với lý do rõ ràng. Điều chúng tôi có thể hứa là lỗi sẽ hiển thị rõ ràng, nó không làm hỏng bất cứ thứ gì, và việc tiếp tục chạy sẽ không gửi lại tin nhắn lần thứ hai.

Về việc chờ: một lượt chạy chờ hai ngày là một wake_at trên lượt chạy đó, chứ không phải một công việc nằm trong hàng đợi. Đó là lý do một quy trình có thể giữ một trăm nghìn lượt chạy trong trạng thái chờ ba tuần mà không tốn bất cứ chi phí nào, và vì sao số lượt chạy đang chờ không phải là điều bạn cần bận tâm.

Lượt chạy mà bạn không bao giờ phải nghĩ tới là lượt chạy đã thành công.