Confluent Schema Registry: Quản Lý Schema Kafka

Confluent Schema Registry Là Gì?

Confluent Schema Registry là một lớp phục vụ (serving layer) cho metadata schema, chạy song song với cụm Kafka và cung cấp giao diện RESTful để lưu trữ và truy xuất schema Avro, JSON Schema, và Protobuf. Nó lưu lịch sử có đánh số phiên bản cho từng schema theo subject, áp dụng các cấu hình compatibility có thể tùy chỉnh, và đi kèm serializer cắm thẳng vào Kafka client để producer và consumer tự động xử lý việc lưu trữ và truy xuất schema.

Tính Năng Cốt Lõi Để Quản Lý Schema

• ✓REST API để đăng ký một phiên bản schema mới dưới một subject, liệt kê các subject, và lấy schema theo subject/phiên bản hoặc theo ID schema toàn cục (globally unique), đúng như các ví dụ curl trong README.
• ✓Lịch sử schema có đánh số phiên bản: mỗi schema đăng ký dưới một subject được theo dõi theo số phiên bản, dựa trên một subject name strategy được chỉ định.
• ✓Cấu hình compatibility có thể tùy chỉnh, áp dụng toàn cục qua `PUT /config` hoặc theo từng subject qua `PUT /config/{subject}` — ví dụ trong README đặt compatibility thành BACKWARD hoặc NONE.
• ✓Một endpoint kiểm tra compatibility riêng (`POST /compatibility/subjects/{subject}/versions/latest`) trả về `is_compatible: true` hoặc `false` trước khi bạn đăng ký thay đổi schema.
• ✓Serializer và deserializer cho Avro, JSON Schema, và Protobuf, cắm thẳng vào Apache Kafka client, tự động xử lý việc lưu trữ và truy xuất schema cho message.
• ✓Một OpenAPI (Swagger) spec được tạo tự động bởi swagger-maven-plugin trong bước compile của Maven.
• ✓Một Jetty server tích hợp sẵn để phục vụ giao diện REST, khởi động và dừng bằng script `bin/schema-registry-start` và `bin/schema-registry-stop`.

Tương Tác Với API Của Schema Registry

Mọi request đều đi qua HTTP thông thường với content type `application/vnd.schemaregistry.v1+json`, nên curl hay bất kỳ REST client nào cũng dùng được — không cần SDK riêng. Để đăng ký một phiên bản schema mới, gửi POST với payload JSON chứa trường `schema` tới `/subjects/{subject}/versions`; phản hồi trả về ID toàn cục của schema. `GET /subjects` liệt kê mọi subject mà Confluent Schema Registry đang theo dõi, còn `GET /subjects/{subject}/versions` liệt kê các số phiên bản dưới một subject. Bạn có thể lấy schema theo ID toàn cục bằng `GET /schemas/ids/{id}`, hoặc lấy một phiên bản cụ thể hay phiên bản mới nhất bằng `GET /subjects/{subject}/versions/{version}` và `GET /subjects/{subject}/versions/latest`. Trước khi đăng ký một thay đổi, gửi `POST` schema ứng viên tới `/compatibility/subjects/{subject}/versions/latest` và kiểm tra trường `is_compatible` trong phản hồi. Quy tắc compatibility được đọc và thiết lập bằng `GET /config` và `PUT /config` (toàn cục) hoặc `PUT /config/{subject}` (theo từng subject); ví dụ trong README đặt giá trị này thành BACKWARD hoặc NONE. Xóa một phiên bản hay toàn bộ subject đều dùng `DELETE` trên đường dẫn tương ứng.

Cài Đặt Schema Registry

README nêu hai cách. Cách đơn giản nhất là tải bản dựng sẵn (prebuilt) như một phần của Confluent Platform. Để build từ mã nguồn, trước tiên bạn cần cài phiên bản development của hai repo Confluent liên quan — common và rest-utils — rồi build Schema Registry bằng Maven: `mvn compile` để build, `mvn test` để chạy unit test và integration test, và `mvn package` (có thể thêm `-DskipTests`) để tạo gói output trong `package-schema-registry/target/` và `package-kafka-serde-tools/target/`. Một profile Maven `standalone` (`mvn package -P standalone`) đóng gói toàn bộ dependency vào một fat JAR duy nhất thay vì cấu trúc thư mục đầy đủ. Sau khi build xong, giao diện REST chạy trên một Jetty server tích hợp sẵn, khởi động và dừng bằng script `bin/schema-registry-start` và `bin/schema-registry-stop` — đây là cách README khuyến nghị để chạy dịch vụ. Một OpenAPI (Swagger) spec được tạo tự động bởi swagger-maven-plugin trong bước compile của Maven. Cấu hình chi tiết hơn không được README này mô tả — nó trỏ tới tài liệu Confluent riêng cho phần cài đặt và cấu hình.

Các Giải Pháp Schema Khác

Câu Hỏi Thường Gặp

Vấn đề Confluent Schema Registry giải quyết

Kafka chỉ truyền byte, không truyền kiểu dữ liệu — producer và consumer chỉ khớp nhau về hình dạng message theo quy ước ngầm, nên việc đổi tên field hay đổi kiểu dữ liệu ở một phía có thể âm thầm làm hỏng deserializer ở phía kia lúc runtime, thường là sau khi message lỗi đã nằm trong log. Confluent Schema Registry tồn tại để biến quy ước đó thành một nguồn thông tin chung, có thể tra cứu và được thực thi: một nơi tập trung để mọi producer và consumer kiểm tra schema trước khi serialize hoặc deserialize, cùng một bước kiểm tra compatibility có thể từ chối một thay đổi gây lỗi trước khi nó được đăng ký.

Trường hợp sử dụng tốt nhất

• •Cho producer và consumer của Kafka một nguồn thông tin chung duy nhất, theo subject, cho định dạng message Avro, JSON Schema, hay Protobuf, thay vì phối hợp thay đổi schema theo quy ước ngầm.
• •Chặn một thay đổi schema gây lỗi trước khi triển khai, bằng cách chạy nó qua endpoint kiểm tra compatibility so với BACKWARD (hay bất kỳ mức compatibility nào đang cấu hình).
• •Gắn serializer Avro/JSON Schema/Protobuf trực tiếp vào code producer và consumer của Kafka để việc đăng ký và tra cứu schema diễn ra tự động cho từng message.
• •Xây công cụ nội bộ — một trình duyệt schema, một CI gate, một script migration — trực tiếp trên REST API thuần thay vì một SDK độc quyền.
• •Chạy Schema Registry như một phần của triển khai Confluent Platform, dùng gói prebuilt thay vì build từ mã nguồn.

Ai nên dùng — và ai nên bỏ qua

Hãy thử Confluent Schema Registry nếu bạn đang chạy Kafka và muốn có hợp đồng schema được đánh số phiên bản, kiểm tra bắt buộc cho message Avro, JSON Schema, hay Protobuf, cùng khả năng kiểm tra compatibility trước khi triển khai thay đổi. Bỏ qua — hoặc ít nhất đọc kỹ file giấy phép trước — nếu bạn cần mọi thành phần trong stack đều theo giấy phép mã nguồn mở được OSI công nhận, vì phần lõi của server dùng Confluent Community License chứ không phải Apache 2.0 hay tương đương; module client và serializer là ngoại lệ, không phải quy tắc chung.

Repo liên quan