Một cửa hàng trực tuyến xác nhận một đơn hàng. Bộ phận kế toán phải chuẩn bị hóa đơn, đội ngũ tiếp thị muốn ghi nhận doanh số bán hàng và bộ phận hỗ trợ muốn tìm lại những gì đã xảy ra. Nếu bộ phận tiếp thị tạm dừng vài giờ, có phải mất sự kiện của họ, chặn đơn hàng hay giữ lại lịch sử để họ có thể đọc lại? Trường hợp giả tưởng này giúp hiểu rõ lợi ích của Cloudflare K2 và chọn một thử nghiệm đầu tiên.
Thực hiện một nhiệm vụ hoặc lưu giữ một câu chuyện
Một hàng đợi công việc giống như một danh sách các nhiệm vụ cần thực hiện: gửi thông báo, tạo tài liệu, cập nhật chỉ mục. Một công việc đã hoàn thành thường không cần được đề xuất lại cho cùng một người thực hiện. Một nhật ký sự kiện lại lưu giữ các sự kiện: một đơn hàng đã được xác nhận, một địa chỉ đã thay đổi, một tài liệu đã được chấp nhận. Nhiều ứng dụng có thể muốn đọc những sự kiện này vì những lý do khác nhau.
Trong cửa hàng giả tưởng của chúng tôi, việc lập hóa đơn và marketing không theo cùng một nhịp độ. Bộ phận lập hóa đơn không cần phải chờ kết thúc một phép tính thống kê. Bộ phận hỗ trợ có thể muốn tái tạo lại một chuỗi thời gian sau này. Do đó, nhu cầu chính là khả năng đọc độc lập cùng một câu chuyện, với thời gian lưu trữ được chọn. Sự phân biệt này xuất phát từ phân tích kiến trúc của chúng tôi; nó không chỉ ra hai loại cứng nhắc mà một sản phẩm sẽ tự động thuộc về.
Trước tiên hãy đặt một câu hỏi đơn giản: nếu bạn xóa một sự kiện sau lần xử lý đầu tiên, việc sử dụng nào sẽ trở nên không thể thực hiện được? Nếu không có độc giả nào khác cần và không có việc rà soát lại nào được dự kiến, một hàng đã được quản lý có thể là đủ. Nếu nhiều ứng dụng phải tiến triển độc lập và tiếp tục lịch sử, một nhật ký xứng đáng được xem xét kỹ lưỡng hơn.
Những gì Cloudflare đã thông báo vào ngày 1 tháng 10
Cloudflare đã mở K2 bản beta công khai vào ngày 1 tháng 10 năm 2026. Nhà xuất bản giới thiệu nó như một nhật ký sự kiện bền vững, được xây dựng trên bộ lưu trữ R2 của họ, với các đăng ký để tổ chức việc tiêu thụ. Một số khả năng, bao gồm khả năng tương thích trực tiếp với Kafka, vẫn còn trong lộ trình phát triển. Việc ra mắt này không thiết lập bất kỳ sự tương đương hợp đồng nào với hệ thống hiện tại của bạn. Thông báo Cloudflare K2.
Tài liệu được tham khảo vào ngày 6 tháng 10 cho biết một quyền truy cập với Workers Paid, một hạn mức ban đầu 10 GB cho mỗi tài khoản và thời gian lưu giữ dữ liệu là ba mươi ngày, có thể mở rộng theo yêu cầu. Thời gian lưu giữ là khoảng thời gian dữ liệu được giữ và vẫn có thể được sử dụng để khôi phục. Các giới hạn beta cần được xem lại trước khi chạy thử nghiệm. Tài liệu K2.
Đối với quyết định của bạn, hãy phân biệt giữa việc truy cập vào một môi trường thử nghiệm và việc thay thế một cơ sở hạ tầng. Cái đầu tiên cho phép kiểm tra các giả thuyết. Cái thứ hai yêu cầu xác định các lỗi, các cam kết của nhà cung cấp, khối lượng thực tế và việc ngừng dịch vụ. Một lịch sử lâu bền không chứng minh rằng mỗi tác động kinh doanh sẽ chỉ được thực hiện một lần, cũng như không chứng minh rằng tất cả các sự kiện chia sẻ một thứ tự toàn cục.
Định nghĩa một sự kiện mà vẫn dễ hiểu
Trước khi chọn công nghệ, hãy viết ra những gì sự kiện của bạn xác nhận. "Đơn hàng được xác nhận" là một thông tin chính xác hơn "Đơn hàng đã thay đổi". Người nhận phải có thể hiểu được liệu thanh toán đã được phê duyệt, đã được thu hay chỉ đang chờ. Một tên gọi không rõ ràng có thể gây ra hóa đơn vào thời điểm sai, ngay cả khi việc vận chuyển hoàn toàn đáng tin cậy.
Đây là một cấu trúc minh họa, không có dữ liệu khách hàng và không có hợp đồng riêng biệt K2 :
event_id : demo-commande-001
schema_version : 1
occurred_at : date UTC du fait métier
event_type : commande_confirmee
payload : identifiant fictif de commande et devise
Mã định danh của sự kiện dùng để nhận biết cùng một sự việc khi nó xảy ra trở lại. Phiên bản sơ đồ giải thích cách đọc cấu trúc của nó. Ngày của sự việc nghiệp vụ khác với ngày mà nó được nhận. Nội dung phải giữ ở mức tối thiểu: một dịch vụ thống kê không nhất thiết cần địa chỉ giao hàng. Nếu một người đọc cần chi tiết, hãy quyết định rõ ràng cách họ nhận được chúng và quyền nào cho phép họ xem.
Cũng xác định điều gì sẽ xảy ra khi lược đồ phát triển. Một trường được thêm vào có thể là tùy chọn đối với các trình đọc cũ. Một sự thay đổi về ý nghĩa thường yêu cầu một phiên bản mới, với một giai đoạn tồn tại song song. Giữ các ví dụ của mỗi phiên bản trong môi trường thử nghiệm của bạn: chúng tạo thành một hợp đồng dễ đọc giữa các nhóm, mà không áp đặt một khung công tác mới.
Phát lại mà không lặp lại các hiệu ứng nghiệp vụ
Một bộ tiêu thụ là ứng dụng đọc các sự kiện và tạo ra một tác động từ chúng. Khó khăn không chỉ giới hạn ở việc nhận dữ liệu: nếu quá trình dừng lại sau khi ghi nhận một hóa đơn nhưng trước khi xác nhận xử lý thì sao? Khi tiếp tục, cùng một sự kiện có thể được trình bày lại. Thiết kế của bạn phải dự liệu khả năng này.
Tính lũy đẳng ở đây có nghĩa là làm cho việc lặp lại không có tác động bổ sung. Đối với một bản sao hóa đơn được sử dụng trong thử nghiệm, bạn có thể giữ nguyên định danh của dữ liệu đã được áp dụng. Quy tắc này phải được đảm bảo khi hai tiến trình hoạt động cùng lúc; một kiểm tra đơn giản kèm theo một ghi độc lập sẽ để lại một khoảng trống tranh chấp.
Thuật toán giả sau đây mô tả một ý định, không phải một API K2 cũng không có triển khai nào được thực thi:
commencer une transaction locale
réserver event_id sous une contrainte d'unicité
si cet identifiant est déjà traité : terminer sans nouvel effet
vérifier la version et les règles métier
enregistrer la facture fictive et le résultat du traitement
valider la transaction
confirmer le traitement selon le contrat du transport
Khi hiệu ứng ra khỏi cơ sở của bạn, chẳng hạn như một cuộc gọi tới nhà cung cấp dịch vụ thanh toán, giao dịch tại chỗ này là không đủ. Cần phải xem xét một khóa lũy đẳng được người nhận công nhận hoặc một cơ chế phối hợp phù hợp. Không gửi bất kỳ khoản thanh toán thực nào trong một bài tập rà soát. Một thông báo thử nghiệm hoặc một ghi chép trong bộ nhớ giả cũng đã đủ để kiểm tra quy tắc của bạn.
Cuối cùng hãy tách các lỗi ra. Một sự cố tạm thời có thể biện minh cho việc phục hồi có giới hạn. Một sự kiện không thể hiểu được đòi hỏi một cuộc điều tra. Một lỗi nghiệp vụ đã biết phải được ghi nhận như vậy. Một thời gian cách ly giữ lại các yếu tố cần xem xét mà không làm tắc nghẽn toàn bộ luồng vô thời hạn; xác định người chịu trách nhiệm và thời gian lưu giữ của nó.
Thử nghiệm thí điểm với kết quả giúp đưa ra quyết định
Giao thức mà chúng tôi đề xuất sử dụng một nhà sản xuất và hai người đọc, trên một không gian riêng biệt. Nhà sản xuất chỉ phát ra các đơn hàng tổng hợp. Người đọc đầu tiên đếm số lượng bán hàng; người thứ hai tạo các phiếu hỗ trợ giả. Một danh sách tham chiếu chứa các mã nhận dạng dự kiến. Không có giá trị về thông lượng hay độ tin cậy nào được trình bày ở đây như là đã đo lường.
Bắt đầu bằng lộ trình bình thường. Kiểm tra xem mỗi đầu đọc có nhận được các thông tin cần thiết và kết quả của nó có phù hợp với tham chiếu không. Sau đó dừng một đầu đọc trong khi đầu đọc khác tiếp tục. Khi tiếp tục lại, ghi nhận các sự kiện được phục hồi, những thiếu sót có thể có và các trùng lặp trong trình bày. Thời gian dừng phải phù hợp với việc bảo quản đã chọn.
Trình bày cùng một định danh hai lần cho thành phần mô phỏng lưu trữ. Tiêu chí chấp nhận là chỉ một hiệu ứng nghiệp vụ. Thêm một sự kiện có phiên bản không xác định và một sự cố lưu trữ giả lập: bạn phải có khả năng giải thích quá trình xử lý thu được và tìm lại phần tử cần điều tra. Đo lường độ trễ giữa phát hành và kết quả, các ghi chép khôi phục và khối lượng được giữ lại, với các điều kiện thử nghiệm được ghi chép.
| Câu hỏi cần kiểm chứng | Bằng chứng cần thu thập trong chương trình thử nghiệm |
|---|---|
| Các bộ đọc có tiến triển một cách độc lập không? | Tiến triển của từng người trong khi người kia tạm dừng |
| Một sự phục hồi có tìm lại được các sự kiện được cho phép không? | So sánh các định danh với tham chiếu |
| Một sự lặp lại có tạo ra hiệu ứng kép không? | Số lượng hiệu ứng trong bộ nhớ giả |
| Một lỗi vẫn có thể được giải thích chứ? | Trạng thái, lý do và khả năng khôi phục có kiểm soát |
Bảng này là một phương pháp Partitech. Nó mô tả những quan sát cần thực hiện, mà không cấu thành kết quả từ nhà cung cấp.
Chuẩn bị phương án rời dịch vụ trước khi chuyển đổi
Giữ sơ đồ sự kiện của bạn tách biệt khỏi các đặc thù của dịch vụ. Xác định cách xuất các dữ liệu còn hữu ích, tái tạo tiến trình của người đọc và khôi phục môi trường thử nghiệm. Kiểm tra độ trung thực của một bản xuất bằng cách đọc lại một vài ví dụ của mỗi phiên bản, thay vì chỉ dựa vào một tệp đã tải xuống.
Trong trường hợp chuyển đổi hệ thống có thể xảy ra, một việc quay lại không thể đơn giản chỉ kích hoạt lại hai bộ tiêu thụ cùng tính phí. Cần một quy tắc chỉ định cơ chế duy nhất được phép tạo ra hiệu quả, sau đó là một điểm phục hồi có thể kiểm tra được. Thử nghiệm thí điểm không được tạo ra tác động thực cho đến khi sự phối hợp này được thiết lập.
Chọn một hàng đợi đơn giản nếu nhu cầu của bạn là một công việc cần thực hiện mà không yêu cầu chia sẻ câu chuyện. Đánh giá một nhật ký nếu nhiều người đọc phải tiếp tục cùng một câu chuyện theo những nhịp điệu khác nhau. K2 làm cho bài thử nghiệm này có thể truy cập trong phạm vi beta của nó; quyết định cuối cùng phụ thuộc vào bằng chứng phục hồi, tính lũy đẳng và các điều kiện thoát mà bạn đạt được trong môi trường của mình.
Nguồn và ngày kiểm tra
Nguồn chính mở ngày 6 tháng 10 năm 2026: thông báo K2 từ ngày 1 tháng 10 và tài liệu K2. Các kịch bản, bảng lưới và pseudocode là các đề xuất gốc, chưa được thực hiện trong bài viết này.