Kiến trúc Kafka trên nền tảng đám mây: Từ lưu trữ phân tầng đến tương lai không ổ đĩa

Trang chủ InfoQ Bài viết Kiến trúc Kafka Cloud-Native: Từ lưu trữ phân cấp đến tương lai không ổ đĩa AI, ML & Kỹ thuật dữ liệu Kiến trúc Kafka Cloud-Native: Từ lưu trữ phân cấp đến tương lai không ổ đĩa Ngày 26/5/2026 Đọc trong 20 phút Bởi Viquar Khan Được đánh giá bởi Arthur Casals Viết cho InfoQ Thỏa mãn sự tò mò của bạn. Giúp hơn 550 nghìn nhà phát triển cấp cao trên toàn cầu luôn dẫn đầu mỗi tháng. Liên hệ Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1.25x 1.5x Thích Danh sách đọc Những điểm chính Việc tách biệt lưu trữ làm thay đổi kinh tế của Kafka bằng cách chuyển chi phí từ cung cấp cơ sở hạ tầng sang sử dụng API đám mây, khiến các mô hình truy cập của người tiêu dùng không hiệu quả có thể trở thành một nguồn chi phí vận hành lớn. Khi chi phí lưu trữ chuyển từ cơ sở hạ tầng dùng chung sang phí API theo yêu cầu, các nhóm nền tảng cần khả năng hiển thị ở cấp độ máy khách để phân bổ chi phí; nếu không có nó, một công việc phát lại duy nhất có thể tạo ra các đợt tăng hóa đơn lớn mà ít có khả năng hiển thị về nguồn gốc của chúng. Giao thức cân bằng lại cũ của Kafka khiến việc mở rộng quy mô người tiêu dùng động bị gián đoạn về mặt vận hành vì các sự kiện mở rộng quy mô đã kích hoạt tạm dừng xử lý trên toàn nhóm. Giao thức thế hệ tiếp theo giảm đáng kể rào cản này, làm cho tính năng tự động mở rộng quy mô Kubernetes-native trở nên thực tế hơn đáng kể. Tính đa nhiệm trong Kafka theo truyền thống đã buộc phải đánh đổi tốn kém: hoặc chạy một cụm chuyên dụng cho mỗi nhóm hoặc chấp nhận sự cô lập yếu trên một cụm dùng chung; các cụm ảo đề xuất một con đường trung gian mang lại ranh giới nghiêm ngặt cho người thuê mà không cần nhân đôi cơ sở hạ tầng. Kafka theo truyền thống đã ghép nối số lượng phân vùng với tính song song của người tiêu dùng. Share Groups phá vỡ ràng buộc này, cho phép các nhóm mở rộng quy mô người tiêu dùng một cách độc lập mà không cần phân vùng lại các chủ đề tốn kém. Giới thiệu: Chuyển đổi sang kiến trúc đám mây và "Hệ điều hành kinh tế" Để hiểu rõ quỹ đạo kiến trúc hiện tại của Apache Kafka, cần xác định bản chất cơ bản của nó. Kafka là một nền tảng truyền phát sự kiện phân tán được thiết kế để xuất bản, đăng ký, lưu trữ và xử lý các luồng bản ghi theo thời gian thực. Sự phát triển của nó được thúc đẩy bởi cộng đồng mã nguồn mở thông qua các Đề xuất cải tiến Kafka (KIPs) – các tài liệu thiết kế chính thức phác thảo những thay đổi kiến trúc lớn và các tính năng vận hành. Trong nhiều năm, Kafka dựa vào thiết kế "không chia sẻ" nghiêm ngặt, được tối ưu hóa cho việc triển khai trên phần cứng vật lý. Nó đạt được độ trễ một chữ số mili giây đáng kinh ngạc bằng cách ghi các nhật ký tuần tự, chỉ nối thêm trực tiếp vào đĩa cục bộ của broker và phục vụ các yêu cầu đọc trực tiếp từ bộ nhớ đệm trang của hệ điều hành. Cách tiếp cận này giúp duy trì độ trễ thấp và thông lượng cao. Tuy nhiên, việc thực hiện "nâng và chuyển" (lift and shift) thiết lập phụ thuộc vào phần cứng này vào các môi trường đám mây hiện đại đã tạo ra những thực tế tài chính mới đầy thách thức. Hãy xem xét hành trình hiện đại hóa của Discover Financial Services. Hoạt động tại Riverwoods, Illinois, Discover xử lý hàng triệu giao dịch mỗi ngày trên mạng lưới toàn cầu của mình. Để cải thiện tốc độ kỹ thuật và hỗ trợ các sáng kiến khoa học dữ liệu, Discover đã di chuyển môi trường thanh toán thẻ cũ của mình sang kiến trúc đám mây gốc được xây dựng trên Apache Kafka làm xương sống sự kiện trung tâm, truyền phát các giao dịch thanh toán thẻ theo thời gian thực đến các lớp xử lý hạ nguồn bao gồm Amazon EMR và Apache Spark để phát hiện gian lận và tính điểm rủi ro. Việc di chuyển này đã giảm đáng kể thời gian cần thiết để áp dụng các thay đổi về giá từ sáu tháng xuống chỉ còn ba tuần, giúp nền tảng có thể xử lý bốn triệu bản ghi giao dịch chỉ trong chín phút (Nghiên cứu điển hình khách hàng của AWS, Bài thuyết trình AWS re:Invent 2021). Trong kiến trúc hiện đại hóa này, Kafka đóng một vai trò riêng biệt: kiến trúc truyền phát sự kiện của nó cung cấp xương sống thời gian thực cho việc phân tích rủi ro và phát hiện gian lận, liên tục cung cấp dữ liệu cho các mô hình hạ nguồn trong khi EMR và Spark xử lý các giao dịch thanh toán theo lô. Tuy nhiên, việc di chuyển một nền tảng đa người thuê lớn lên đám mây đã phơi bày những thực tế về kinh tế đơn vị đám mây. Việc sao chép dữ liệu giao dịch ba lần trên các Vùng sẵn sàng (AZs) tạo ra phí thoát mạng (network egress fees) khổng lồ. Hơn nữa, việc lưu trữ petabyte nhật ký kiểm toán hoặc luồng sự kiện lịch sử trên bộ nhớ khối đám mây cao cấp nhanh chóng trở nên đắt đỏ một cách không tưởng. Để tồn tại trên đám mây, Kafka đang phát triển từ một hệ thống phụ thuộc chặt chẽ vào phần cứng thành một kiến trúc phân tách cao, được quản lý bởi các kiểm soát tài chính nghiêm ngặt. Mặc dù kiến trúc này thường được gọi là "hệ điều hành kinh tế", thuật ngữ này không chỉ là một phép ẩn dụ; nó đại diện cho một thực tế hoạt động cụ thể, nơi các nhóm nền tảng phải chủ động xây dựng các đường ống tính phí dựa trên dữ liệu đo từ xa, thực thi các quy trình quản lý phát lại có ý thức về chi phí và áp dụng có chọn lọc ngữ nghĩa hàng đợi để quản lý các chi phí đám mây biến động cao. Ma trận quyết định sau đây minh họa cách các kiến trúc sư nên ánh xạ các khối lượng công việc cụ thể vào các khả năng đang phát triển này: Hình 1. Ma trận quyết định để ánh xạ khối lượng công việc tới các khả năng lưu trữ phân tầng (Nguồn: tác giả). Như thể hiện trong Hình 1, các kiến trúc sư cần ánh xạ các khối lượng công việc cụ thể tới những khả năng đang phát triển này dựa trên các yêu cầu về thứ tự, độ nhạy cảm với độ trễ và nhu cầu lưu giữ. Trong suốt bài viết này, chúng tôi sẽ trình bày các thách thức vận hành thực tế xuyên suốt từng giai đoạn phát triển kiến trúc từ lưu trữ phân tầng đến tương lai không ổ đĩa, cho thấy chính xác cách các kiến trúc sư và đội ngũ nền tảng phải thích nghi.