Kiến trúc hướng sự kiện với Kafka

Trong hệ sinh thái kỹ thuật số phát triển nhanh chóng ngày nay, nhu cầu xử lý dữ liệu theo thời gian thực và các hệ thống có khả năng mở rộng, tách rời trở nên rõ ràng hơn bao giờ hết. Khi microservices đã trở thành mô hình kiến trúc thực tế cho nhiều ứng dụng hiện đại, các kỹ sư thường xuyên gặp phải những thách thức liên quan đến giao tiếp dịch vụ, đồng bộ hóa dữ liệu và khả năng phục hồi của hệ thống. Một trong những cách hiệu quả nhất để giải quyết những vấn đề này là áp dụng Kiến trúc hướng sự kiện (EDA) được hỗ trợ bởi Apache Kafka.

Kiến trúc hướng sự kiện là một mô hình thiết kế phần mềm trong đó các ứng dụng được tách rời có thể xuất bản và đăng ký các sự kiện một cách không đồng bộ thông qua một bộ môi giới sự kiện. Trong mô hình này, "sự kiện" là bất kỳ thay đổi trạng thái đáng kể nào, chẳng hạn như khách hàng đặt hàng, cảm biến ghi nhận nhiệt độ tăng đột biến hoặc người dùng đăng nhập vào một dịch vụ. Khi các sự kiện này xảy ra, hệ thống sẽ ghi lại chúng và phát sóng chúng đến bất kỳ dịch vụ nào có thể quan tâm, mà không cần nhà sản xuất phải biết người tiêu dùng là ai.

Vai trò của Apache Kafka trong EDA

Apache Kafka đã nổi lên như nền tảng truyền phát sự kiện hàng đầu nhờ thông lượng, độ bền và khả năng chịu lỗi vô song. Không giống như các hàng đợi tin nhắn truyền thống như RabbitMQ hay ActiveMQ, Kafka được thiết kế như một nhật ký commit phân tán.

Nhật ký Commit bất biến

Về cốt lõi, Kafka lưu trữ dữ liệu trong các topic, được phân vùng và sao chép trên nhiều broker. Khi một nhà sản xuất xuất bản một tin nhắn đến một topic, nó sẽ được thêm vào cuối nhật ký commit trong một phân vùng cụ thể. Thiết kế chỉ thêm vào này giúp việc ghi cực kỳ nhanh chóng vì chúng là tuần tự. Sau khi được ghi, một tin nhắn là bất biến và vẫn nằm trong topic trong một khoảng thời gian lưu giữ có thể cấu hình, thay vì bị xóa ngay sau khi được tiêu thụ. Mô hình bền vững này cho phép người tiêu dùng tua lại và phát lại các sự kiện, điều này vô cùng quý giá cho việc gỡ lỗi, kiểm toán hoặc khởi động các dịch vụ mới cần ngữ cảnh lịch sử.

Topics, Partitions và Consumer Groups

Để đạt được khả năng mở rộng cao, các topic của Kafka được chia thành các phân vùng. Một phân vùng là một chuỗi bản ghi có thứ tự, bất biến. Bằng cách chia một topic thành nhiều phân vùng, Kafka cho phép nhiều người tiêu dùng đọc từ một topic duy nhất song song. Điều này đưa chúng ta đến khái niệm Consumer Groups.

Một nhóm người tiêu dùng là một tập hợp các người tiêu dùng hợp tác để tiêu thụ dữ liệu từ một hoặc nhiều topic. Kafka đảm bảo rằng mỗi phân vùng được gán cho chính xác một người tiêu dùng trong một nhóm. Nếu bạn có một topic với 10 phân vùng và một nhóm người tiêu dùng với 10 phiên bản, mỗi phiên bản đọc từ một phân vùng, cho phép bạn xử lý 10 sự kiện đồng thời. Nếu một phiên bản bị lỗi, Kafka tự động gán lại phân vùng của nó cho một phiên bản khỏe mạnh khác trong nhóm, đảm bảo tính sẵn sàng cao và khả năng chịu lỗi.

Các cân nhắc kỹ thuật chính

Khi triển khai EDA với Kafka, các kiến trúc sư và kỹ sư phải cẩn thận điều hướng một số đánh đổi kỹ thuật và mô hình thiết kế.

Event Sourcing so với Event Notification

Thường có hai cách để sử dụng các sự kiện trong một kiến trúc: Event Notification và Event Sourcing.

• Event Notification: Trong mô hình này, các sự kiện chứa thông tin tối thiểu, thường chỉ là một ID và một hành động (ví dụ: "Đơn hàng 123 đã tạo"). Người tiêu dùng sau đó phải truy vấn hệ thống nguồn thông qua API để lấy đầy đủ chi tiết. Mặc dù điều này giảm thiểu kích thước tải trọng, nhưng nó lại tái tạo sự ghép nối đồng bộ giữa các dịch vụ.
• Event Carried State Transfer (Event Sourcing): Ở đây, sự kiện chứa tất cả dữ liệu mà người tiêu dùng cần (ví dụ: chi tiết đơn hàng đầy đủ). Người tiêu dùng có thể duy trì bản vật chất hóa dữ liệu cục bộ của riêng mình, loại bỏ hoàn toàn nhu cầu gọi API đồng bộ. Mặc dù điều này làm tăng kích thước tải trọng sự kiện và yêu cầu quản lý schema cẩn thận, nhưng nó cung cấp khả năng tách rời và khả năng phục hồi tối đa.

Quản lý Schema với Schema Registry

Khi các ứng dụng phát triển, cấu trúc của các sự kiện (schemas) chắc chắn sẽ thay đổi. Nếu một nhà sản xuất thay đổi định dạng của một sự kiện và một người tiêu dùng không được cập nhật để xử lý nó, người tiêu dùng sẽ gặp sự cố. Để giải quyết vấn đề này, các tổ chức sử dụng Schema Registry (thường là Schema Registry của Confluent).

Schema Registry lưu trữ lịch sử phiên bản của tất cả các schema (thường sử dụng Avro, Protobuf hoặc JSON Schema). Khi một nhà sản xuất gửi một tin nhắn, nó bao gồm ID schema. Người tiêu dùng lấy schema từ registry bằng ID đó và giải mã tin nhắn. Registry cũng thực thi các quy tắc tương thích (ví dụ: tương thích ngược, tương thích tiến hoặc tương thích hoàn toàn), đảm bảo rằng các nhà sản xuất không thể xuất bản các sự kiện có thể làm hỏng các người tiêu dùng hiện có.

Exactly-Once Semantics (EOS)

Trong các hệ thống phân tán, việc xử lý lỗi mà không mất dữ liệu hoặc trùng lặp là cực kỳ khó khăn. Kafka truyền thống cung cấp phân phối "ít nhất một lần", nghĩa là một tin nhắn chắc chắn sẽ được phân phối, nhưng có thể được phân phối nhiều lần trong trường hợp thử lại. Đối với các ứng dụng như giao dịch tài chính, điều này là không thể chấp nhận được.

Kể từ phiên bản 0.11, Kafka hỗ trợ Exactly-Once Semantics (EOS) thông qua Idempotent Producer và Transactional API. Một idempotent producer gán một số thứ tự cho mỗi tin nhắn, cho phép broker loại bỏ trùng lặp các lần thử lại. Transactional API cho phép một nhà sản xuất ghi vào nhiều phân vùng một cách nguyên tử—hoặc tất cả các lần ghi thành công, hoặc không có lần nào. Điều này rất quan trọng đối với các ứng dụng xử lý luồng (như Kafka Streams) đọc từ một topic, xử lý dữ liệu và ghi vào một topic khác, đảm bảo rằng mọi bản ghi được xử lý chính xác một lần ngay cả trong trường hợp lỗi.

Log Compaction

Theo mặc định, Kafka giữ lại dữ liệu dựa trên thời gian (ví dụ: 7 ngày) hoặc kích thước. Tuy nhiên, một số topic được sử dụng làm nguồn sự thật cho trạng thái mới nhất của một thực thể (ví dụ: địa chỉ hiện tại của khách hàng). Đối với những trường hợp này, Kafka cung cấp Log Compaction. Với tính năng nén nhật ký được bật, Kafka đảm bảo rằng nó giữ lại ít nhất giá trị cuối cùng được biết cho mỗi khóa tin nhắn. Broker định kỳ quét nhật ký và xóa các bản ghi cũ hơn có cùng khóa với một bản ghi mới hơn. Điều này cho phép người tiêu dùng khôi phục trạng thái hoàn chỉnh, cập nhật của một hệ thống một cách nhanh chóng mà không cần xử lý hàng năm các thay đổi lịch sử.

Kết luận

Chuyển sang Kiến trúc hướng sự kiện với Apache Kafka không chỉ là một sự thay đổi công nghệ; đó là một sự thay đổi cơ bản trong cách các kỹ sư hình dung luồng dữ liệu và tích hợp dịch vụ. Bằng cách áp dụng nhật ký commit phân tán, phân vùng và giao tiếp không đồng bộ, các tổ chức có thể xây dựng các ứng dụng có khả năng mở rộng, phục hồi và phản hồi cao. Tuy nhiên, thành công đòi hỏi sự hiểu biết sâu sắc về nội bộ của Kafka, sự chú ý cẩn thận đến sự phát triển của schema và một cách tiếp cận có kỷ luật đối với thiết kế sự kiện. Khi được thực hiện đúng cách, phần thưởng là một hệ thống thần kinh mạnh mẽ có thể dễ dàng xử lý các yêu cầu của các ứng dụng chuyên sâu về dữ liệu hiện đại.

Bạn cũng có thể thích

• Truyền dữ liệu thời gian thực với Apache Kafka
• Thiết kế hệ thống: Xây dựng bộ giới hạn tốc độ phân tán
• Cách tăng cường bảo mật Firefox trên Linux (Hướng dẫn cho người mới bắt đầu)
• VPN vs Proxy: Sự khác biệt, Dấu vân tay, Rò rỉ và Kiểm tra quyền riêng tư