Mặc dù tôi đã đi qua Kafka trước đây, nhưng gần đây tôi mới nhận ra Kafka có thể được sử dụng như (cơ sở) của một CQRS , cửa hàng sự kiện .

Một trong những điểm chính mà Kafka hỗ trợ:

• Sự kiện chụp / lưu trữ, tất nhiên HA.
• Quán rượu / kiến ​​trúc phụ
• Khả năng phát lại eventlog cho phép khả năng người đăng ký mới đăng ký với hệ thống sau khi thực tế.

Phải thừa nhận rằng tôi không thành thạo 100% về nguồn cung ứng CQRS / Sự kiện nhưng điều này có vẻ khá gần với những gì một cửa hàng sự kiện nên có. Điều thú vị là: Tôi thực sự không thể tìm thấy nhiều về việc Kafka được sử dụng như một cửa hàng sự kiện, vì vậy có lẽ tôi đang thiếu một cái gì đó.

Vì vậy, bất cứ điều gì còn thiếu từ Kafka để nó trở thành một sự kiện tốt? Nó sẽ làm việc? Sử dụng nó sản xuất? Quan tâm đến cái nhìn sâu sắc, liên kết, vv

Về cơ bản trạng thái của hệ thống được lưu dựa trên các giao dịch / sự kiện mà hệ thống đã nhận được, thay vì chỉ lưu trạng thái / ảnh chụp hiện tại của hệ thống, điều thường được thực hiện. (Hãy nghĩ về nó như một Sổ cái tổng hợp trong Kế toán: tất cả các giao dịch cuối cùng sẽ thêm vào trạng thái cuối cùng) Điều này cho phép tất cả các loại điều thú vị, nhưng chỉ cần đọc các liên kết được cung cấp.

Kafka có nghĩa là một hệ thống nhắn tin có nhiều điểm tương đồng với một cửa hàng sự kiện tuy nhiên để trích dẫn phần giới thiệu của họ:

Cụm Kafka giữ lại tất cả các thông báo đã xuất bản, cho dù chúng có được sử dụng hay không trong một khoảng thời gian có thể định cấu hình . Ví dụ: nếu lưu giữ được đặt trong hai ngày, thì trong hai ngày sau khi tin nhắn được xuất bản, nó có sẵn để sử dụng, sau đó nó sẽ bị loại bỏ để giải phóng không gian. Hiệu suất của Kafka thực sự không đổi đối với kích thước dữ liệu nên việc giữ lại nhiều dữ liệu không phải là vấn đề.

Vì vậy, trong khi các tin nhắn có khả năng có thể được giữ lại vô thời hạn, kỳ vọng là chúng sẽ bị xóa. Điều này không có nghĩa là bạn không thể sử dụng nó như một cửa hàng sự kiện, nhưng tốt hơn là sử dụng thứ khác. Hãy xem EventStore để thay thế.

CẬP NHẬT

Tài liệu của Kafka :

Tìm nguồn cung ứng sự kiện là một kiểu thiết kế ứng dụng trong đó các thay đổi trạng thái được ghi lại dưới dạng một chuỗi các bản ghi theo thời gian. Sự hỗ trợ của Kafka cho dữ liệu nhật ký được lưu trữ rất lớn làm cho nó trở thành một phụ trợ tuyệt vời cho một ứng dụng được xây dựng theo phong cách này.

CẬP NHẬT 2

Một mối quan tâm với việc sử dụng Kafka để tìm nguồn cung ứng sự kiện là số lượng chủ đề bắt buộc. Thông thường trong tìm nguồn cung ứng sự kiện, có một luồng (chủ đề) các sự kiện cho mỗi thực thể (chẳng hạn như người dùng, sản phẩm, v.v.). Bằng cách này, trạng thái hiện tại của một thực thể có thể được phục hồi bằng cách áp dụng lại tất cả các sự kiện trong luồng. Mỗi chủ đề Kafka bao gồm một hoặc nhiều phân vùng và mỗi phân vùng được lưu trữ dưới dạng một thư mục trên hệ thống tệp. Cũng sẽ có áp lực từ ZooKeeper khi số lượng znodes tăng lên.

Tôi là một trong những tác giả gốc của Kafka. Kafka sẽ làm việc rất tốt như một bản ghi cho nguồn cung cấp sự kiện. Nó có khả năng chịu lỗi, quy mô đến kích thước dữ liệu khổng lồ và được xây dựng theo mô hình phân vùng.

Chúng tôi sử dụng nó cho một số trường hợp sử dụng mẫu này tại LinkedIn. Ví dụ, hệ thống xử lý luồng nguồn mở của chúng tôi, Apache Samza, đi kèm với sự hỗ trợ tích hợp để tìm nguồn cung ứng sự kiện.

Tôi nghĩ rằng bạn không nghe nhiều về việc sử dụng Kafka để tìm nguồn cung ứng sự kiện chủ yếu vì thuật ngữ tìm nguồn cung ứng sự kiện dường như không phổ biến trong không gian web tiêu dùng nơi Kafka phổ biến nhất.

Tôi đã viết một chút về phong cách sử dụng Kafka này ở đây .

Tôi tiếp tục quay trở lại QA này. Và tôi không tìm thấy câu trả lời đủ sắc thái, vì vậy tôi thêm câu trả lời này.

TL; DR. Có hay không, tùy thuộc vào việc sử dụng nguồn sự kiện của bạn.

Có hai loại hệ thống nguồn gốc sự kiện mà tôi biết.

Bộ xử lý sự kiện xuôi dòng = Có

Trong loại hệ thống này, các sự kiện xảy ra trong thế giới thực và được ghi lại dưới dạng sự kiện. Chẳng hạn như một hệ thống kho để theo dõi các pallet của sản phẩm. Về cơ bản không có sự kiện xung đột. Mọi thứ đã xảy ra, ngay cả khi nó sai. (Tức là pallet 123456 đặt trên xe tải A, nhưng đã được lên lịch cho xe tải B.) Sau đó, các sự kiện được kiểm tra ngoại lệ thông qua các cơ chế báo cáo. Kafka có vẻ rất phù hợp cho loại ứng dụng xử lý sự kiện này.

Trong bối cảnh này, có thể hiểu được tại sao mọi người Kafka lại ủng hộ nó như một giải pháp Tìm kiếm sự kiện. Bởi vì nó khá giống với cách nó đã được sử dụng, ví dụ, nhấp vào luồng. Tuy nhiên, những người sử dụng thuật ngữ Tìm nguồn sự kiện (trái ngược với Xử lý luồng) có thể đề cập đến việc sử dụng thứ hai ...

Nguồn sự thật do ứng dụng kiểm soát = Không

Loại ứng dụng này tuyên bố các sự kiện của chính nó là kết quả của các yêu cầu của người dùng thông qua logic kinh doanh. Kafka không hoạt động tốt trong trường hợp này vì hai lý do chính.

Thiếu sự cô lập thực thể

Kịch bản này cần khả năng tải luồng sự kiện cho một thực thể cụ thể. Lý do phổ biến cho việc này là để xây dựng một mô hình ghi tạm thời cho logic nghiệp vụ để sử dụng để xử lý yêu cầu. Làm điều này là không thực tế trong Kafka. Sử dụng chủ đề cho mỗi thực thể có thể cho phép điều này, ngoại trừ đây là một người không bắt đầu khi có thể có hàng ngàn hoặc hàng triệu thực thể. Điều này là do giới hạn kỹ thuật trong Kafka / Zookeeper.

Một trong những lý do chính để sử dụng mô hình ghi tạm thời theo cách này là để làm cho các thay đổi logic kinh doanh rẻ và dễ triển khai.

Thay vào đó, nên sử dụng chủ đề cho mỗi loại cho Kafka, nhưng điều này sẽ yêu cầu tải các sự kiện cho mọi thực thể của loại đó chỉ để nhận các sự kiện cho một thực thể. Vì bạn không thể biết vị trí đăng nhập của sự kiện nào thuộc về thực thể nào. Ngay cả khi sử dụng Snapshots để bắt đầu từ một vị trí nhật ký đã biết, đây có thể là một số lượng đáng kể các sự kiện để lướt qua.

Thiếu phát hiện xung đột

Thứ hai, người dùng có thể tạo điều kiện cuộc đua do các yêu cầu đồng thời chống lại cùng một thực thể. Có thể khá là không mong muốn để lưu các sự kiện xung đột và giải quyết chúng sau thực tế. Vì vậy, điều quan trọng là có thể ngăn chặn các sự kiện xung đột. Để mở rộng yêu cầu tải, người ta thường sử dụng các dịch vụ không trạng thái trong khi ngăn xung đột ghi bằng cách sử dụng ghi có điều kiện (chỉ ghi nếu sự kiện thực thể cuối cùng là #x). Aka lạc quan đồng thời. Kafka không hỗ trợ đồng thời lạc quan. Ngay cả khi nó hỗ trợ nó ở cấp chủ đề, nó sẽ cần phải giảm xuống mức thực thể để có hiệu quả. Để sử dụng Kafka và ngăn chặn các sự kiện xung đột, bạn sẽ cần sử dụng một nhà văn có trạng thái, tuần tự ở cấp ứng dụng. Đây là một yêu cầu / hạn chế kiến ​​trúc quan trọng.

Thêm thông tin

Cập nhật mỗi bình luận

Nhận xét đã bị xóa, nhưng câu hỏi đại loại như: mọi người sử dụng gì để lưu trữ sự kiện sau đó?

Dường như hầu hết mọi người cuộn triển khai lưu trữ sự kiện của riêng họ trên cơ sở dữ liệu hiện có. Đối với các kịch bản không được phân phối, như các sản phẩm phụ trợ nội bộ hoặc các sản phẩm độc lập, nó được ghi chép đầy đủ về cách tạo một cửa hàng sự kiện dựa trên SQL. Và có những thư viện có sẵn trên đầu một loại cơ sở dữ liệu. Ngoài ra còn có EventStore , được xây dựng cho mục đích này.

Trong các kịch bản phân tán, tôi đã thấy một vài triển khai khác nhau. Dự án Panther của Jet sử dụng Azure CosmosDB , với tính năng Change Feed để thông báo cho người nghe. Một triển khai tương tự khác mà tôi đã nghe nói về AWS là sử dụng DynamoDB với tính năng Luồng để thông báo cho người nghe. Khóa phân vùng có thể phải là id luồng để phân phối dữ liệu tốt nhất (để giảm lượng cung cấp quá mức). Tuy nhiên, một phát lại đầy đủ trên các luồng trong Dynamo là tốn kém (đọc và chi phí khôn ngoan). Vì vậy, điều này cũng đã được thiết lập cho Luồng động để chuyển các sự kiện sang S3. Khi một người nghe mới xuất hiện trực tuyến hoặc một người nghe hiện tại muốn phát lại đầy đủ, nó sẽ đọc S3 để bắt kịp trước.

Dự án hiện tại của tôi là một kịch bản nhiều người thuê, và tôi đã tự mình lăn lộn trên Postgres. Một cái gì đó như Citus có vẻ thích hợp cho khả năng mở rộng, phân vùng theo dòng + xúc tu.

Kafka vẫn rất hữu ích trong các kịch bản phân tán. Đây là một vấn đề không hề nhỏ khi đưa các sự kiện của mỗi dịch vụ sang các dịch vụ khác. Một cửa hàng sự kiện thường không được xây dựng cho điều đó, nhưng đó chính xác là những gì Kafka làm tốt. Mỗi dịch vụ có nguồn sự thật bên trong riêng (có thể là lưu trữ sự kiện hoặc theo cách khác), nhưng lắng nghe Kafka để biết những gì đang xảy ra "bên ngoài". Dịch vụ cũng có thể đăng các sự kiện lên Kafka để thông báo cho "bên ngoài" những điều thú vị mà dịch vụ đã làm.

Bạn có thể sử dụng Kafka làm cửa hàng sự kiện, nhưng tôi không khuyên bạn nên làm như vậy, mặc dù nó có thể có vẻ là sự lựa chọn tốt:

• Kafka chỉ đảm bảo ít nhất một lần giao hàng và có những bản sao trong cửa hàng sự kiện không thể xóa được. Cập nhật: Tại đây bạn có thể đọc lý do tại sao rất khó với Kafka và một số tin tức mới nhất về cách cuối cùng đạt được hành vi này: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-does-it /
• Do tính không thay đổi, không có cách nào để thao túng kho sự kiện khi ứng dụng phát triển và các sự kiện cần phải được chuyển đổi (tất nhiên có các phương pháp như upcasting, nhưng ...). Có thể nói bạn không bao giờ cần phải chuyển đổi các sự kiện, nhưng đó không phải là giả định chính xác, có thể xảy ra trường hợp bạn sao lưu bản gốc, nhưng bạn nâng cấp chúng lên các phiên bản mới nhất. Đó là yêu cầu hợp lệ trong kiến ​​trúc hướng sự kiện.
• Không có nơi để duy trì ảnh chụp nhanh của các thực thể / tập hợp và phát lại sẽ trở nên chậm hơn và chậm hơn. Tạo ảnh chụp nhanh là tính năng cho cửa hàng sự kiện từ quan điểm dài hạn.
• Các phân vùng Kafka đã cho được phân phối và chúng khó quản lý và sao lưu so với cơ sở dữ liệu. Cơ sở dữ liệu đơn giản hơn :-)

Vì vậy, trước khi bạn lựa chọn, bạn nghĩ hai lần. Lưu trữ sự kiện dưới dạng kết hợp các giao diện lớp ứng dụng (giám sát và quản lý), lưu trữ SQL / NoQuery và Kafka với tư cách là nhà môi giới là lựa chọn tốt hơn so với việc Kafka xử lý cả hai vai trò để tạo ra giải pháp đầy đủ tính năng.

Cửa hàng sự kiện là dịch vụ phức tạp đòi hỏi nhiều hơn những gì Kafka có thể cung cấp nếu bạn nghiêm túc trong việc áp dụng tìm nguồn cung ứng Sự kiện, CQRS, Sagas và các mẫu khác trong kiến ​​trúc hướng sự kiện và duy trì hiệu suất cao.

Hãy thử thách câu trả lời của tôi! Bạn có thể không thích những gì tôi nói về nhà môi giới yêu thích của bạn với nhiều khả năng chồng chéo, nhưng vẫn vậy, Kafka không được thiết kế như một cửa hàng sự kiện, nhưng đồng thời là nhà môi giới hiệu suất cao và bộ đệm để xử lý các nhà sản xuất nhanh so với các kịch bản của người tiêu dùng chậm, ví dụ.

Vui lòng xem tại eventiated.io microservice khung nguồn mở để khám phá thêm về các vấn đề tiềm ẩn: http://eventiated.io/

Cập nhật kể từ ngày 8 tháng 2 năm 2018

Tôi không kết hợp thông tin mới từ các bình luận, nhưng đồng ý về một số khía cạnh đó. Bản cập nhật này là về một số khuyến nghị cho nền tảng hướng sự kiện microservice. Nếu bạn nghiêm túc về thiết kế mạnh mẽ của microservice và hiệu suất cao nhất có thể nói chung, tôi sẽ cung cấp cho bạn một vài gợi ý mà bạn có thể quan tâm.

1. Đừng sử dụng Spring - thật tuyệt (tôi sử dụng nó rất nhiều), nhưng lại nặng và chậm cùng một lúc. Và nó không phải là nền tảng microservice. Đó là "chỉ" một khung để giúp bạn thực hiện một (rất nhiều công việc đằng sau việc này ..). Các khung khác là "chỉ" REST hoặc JPA nhẹ hoặc các khung tập trung khác nhau. Tôi khuyên bạn nên có sẵn nền tảng microservice hoàn chỉnh nguồn mở tốt nhất trong lớp đang quay trở lại với các gốc Java thuần túy: https://github.com/networknt

Nếu bạn tự hỏi về hiệu suất, bạn có thể so sánh bản thân với bộ điểm chuẩn hiện có. https://github.com/networknt/microservice-framework-benchmark

2. Đừng sử dụng Kafka chút nào :-)) Đây chỉ là một trò đùa. Ý tôi là trong khi Kafka là tuyệt vời, đó là một hệ thống trung tâm môi giới khác. Tôi nghĩ rằng tương lai là trong các hệ thống nhắn tin ít môi giới. Bạn có thể ngạc nhiên nhưng có hệ thống Kafka nhanh hơn :-), tất nhiên bạn phải xuống cấp thấp hơn. Nhìn vào Biên niên sử.

3. Đối với cửa hàng Sự kiện, tôi khuyên dùng tiện ích mở rộng Postgresql vượt trội có tên TimescaleDB, tập trung vào xử lý dữ liệu thời gian hiệu suất cao (sự kiện là thời gian) với khối lượng lớn. Tất nhiên, CQRS, tìm nguồn cung ứng Sự kiện (phát lại, v.v.) được xây dựng trong khung light4j ngoài hộp sử dụng Postgres làm dung lượng lưu trữ thấp.

4. Để nhắn tin, hãy thử xem Chronicle Queue, Map, Engine, Network. Tôi có nghĩa là thoát khỏi các giải pháp trung tâm môi giới lỗi thời này và đi với hệ thống nhắn tin vi mô (nhúng một). Chronicle Queue thực sự thậm chí còn nhanh hơn Kafka. Nhưng tôi đồng ý rằng đó không phải là tất cả trong một giải pháp và bạn cần thực hiện một số phát triển nếu không bạn đi và mua phiên bản Enterprise (trả phí). Cuối cùng, nỗ lực xây dựng từ Chronicle, lớp nhắn tin của riêng bạn sẽ được trả bằng cách loại bỏ gánh nặng duy trì cụm Kafka.

Có, bạn có thể sử dụng Kafka như một cửa hàng sự kiện. Nó hoạt động khá tốt, đặc biệt là với việc giới thiệu Kafka Streams , cung cấp cách thức gốc của Kafka để xử lý các sự kiện của bạn thành trạng thái tích lũy mà bạn có thể truy vấn .

Về:

Khả năng phát lại eventlog cho phép khả năng người đăng ký mới đăng ký với hệ thống sau khi thực tế.

Điều này có thể là khó khăn. Tôi đã đề cập chi tiết ở đây: https://stackoverflow.com/a/48482974/741970

Có, Kafka hoạt động tốt trong mô hình tìm nguồn cung ứng sự kiện đặc biệt là CQRS, tuy nhiên bạn phải cẩn thận trong khi đặt TTL cho các chủ đề và luôn nhớ rằng Kafka không được thiết kế cho mô hình này, tuy nhiên chúng tôi rất có thể sử dụng nó.

Tôi nghĩ bạn nên nhìn vào khung sợi trục cùng với sự hỗ trợ của họ cho Kafka