Iggy.rs - Xây dựng message streaming bằng Rust
(blog.iggy.rs)Khởi nguồn
- Tháng 4 năm 2023, quyết định học Rust.
- Dựa trên kinh nghiệm về hệ thống phân tán và messaging, quyết định phát triển một nền tảng message streaming.
- Mục tiêu là hiểu cách các hệ thống messaging vận hành bên trong và những đánh đổi mà các nhà phát triển phải thực hiện.
- Iggy.rs ra đời, với mục tiêu trở thành nền tảng message streaming nhấn mạnh vào tốc độ và sự gọn nhẹ.
Dự án
- Iggy ban đầu sử dụng giao thức QUIC để cung cấp chức năng trao đổi message cơ bản.
- Thông qua quá trình tạo mẫu và cải tiến liên tục, đã triển khai máy chủ hỗ trợ ghi/đọc song song và các stream độc lập.
- Bổ sung hỗ trợ cho giao thức TCP và HTTP, đồng thời tối ưu hóa cơ chế đồng bộ dữ liệu để cải thiện hiệu năng.
- Benchmark cho thấy throughput cao và độ trễ thấp, từ đó dự án được chuyển thành một dự án dài hạn.
Đội ngũ
- Iggy có một đội ngũ khoảng 10 thành viên đóng góp vào nhiều phần khác nhau.
- Tham gia vào nhiều dự án như core server, SDK, web UI, CLI.
- Các nhà phát triển với kinh nghiệm đa dạng, cùng chia sẻ niềm đam mê lập trình, đã tự nguyện tham gia.
- Sự tham gia của các contributor bên ngoài từ khắp nơi trên thế giới đã củng cố thêm niềm tin vào dự án.
Tính năng
- Máy chủ message streaming hiệu năng cao, bền vững, dựa trên log.
- Throughput cao, độ trễ thấp, cùng mức sử dụng tài nguyên có thể dự đoán của ngôn ngữ biên dịch Rust.
- Hỗ trợ nhiều stream, topic, partition và nhiều giao thức truyền tải khác nhau.
- RESTful API, client SDK cho nhiều ngôn ngữ, và làm việc trực tiếp với dữ liệu nhị phân.
- Có thể cấu hình tính năng máy chủ, lưu consumer offset trên máy chủ, và hỗ trợ nhiều cách polling message.
- Consumer group để đảm bảo thứ tự message và mở rộng theo chiều ngang, cùng các tính năng hết hạn message và loại bỏ trùng lặp.
- Hỗ trợ TLS cho mọi giao thức truyền tải, mã hóa dữ liệu tùy chọn và hỗ trợ message header.
- CLI tích hợp và ứng dụng benchmark để quản lý máy chủ streaming, triển khai dưới dạng một binary duy nhất.
Lộ trình
- Sau khi xuất hiện trên trang GitHub Trending, đã có các cuộc thảo luận với người dùng về việc bổ sung tính năng.
- Mục tiêu là cải thiện hiệu năng và độ tin cậy thông qua clustering, I/O cấp thấp và kiến trúc mỗi lõi một luồng.
- Thử nghiệm cơ chế đồng thuận Raft, cải thiện tác vụ I/O bằng
io_uring, và có kế hoạch sử dụng runtime monoio.
Tương lai
- Mục tiêu là trở thành một nền tảng message streaming đa dụng và thách thức các giới hạn của OS và phần cứng.
- Dự kiến hỗ trợ nhiều ngôn ngữ lập trình, CLI và web UI như một nền tảng tích hợp dễ sử dụng.
- Hướng tới phát triển thông qua phản hồi và ý tưởng từ cộng đồng.
GN⁺ nhận định
- Iggy.rs là một nền tảng message streaming dựa trên Rust, hướng tới hiệu năng cao và độ trễ thấp.
- Là một dự án mã nguồn mở, dự án đang tiếp tục phát triển nhờ sự tham gia và đóng góp tự nguyện của các nhà phát triển trên toàn thế giới.
- Mục tiêu đầy tham vọng là vượt qua giới hạn hiệu năng của hệ thống phân tán thông qua các công nghệ đổi mới như clustering, tối ưu I/O cấp thấp và kiến trúc mỗi lõi một luồng là điều rất thú vị, và đây là một dự án rất hữu ích với những ai quan tâm đến lĩnh vực này.
1 bình luận
Ý kiến trên Hacker News
Cảm giác thật lý tưởng khi mọi người cùng làm việc hướng tới cùng một mục tiêu, dù có những lý do khác nhau, và tiền bạc không phải là mục đích duy nhất
Mong dự án thành công; nếu có phần so sánh với các lựa chọn thay thế khác thì có lẽ sẽ giúp hiểu rõ hơn dự án này nằm ở đâu
Người viết tạo cảm giác khiêm tốn, chân thành và giống một lãnh đạo dự án có tính xây dựng
Mọi người cùng tham gia nỗ lực này với tinh thần thử xem cho vui nữa
Nó cung cấp đa luồng hữu ích tương tự SCTP nên là điểm khởi đầu tốt, đã có nhiều thư viện tốt có thể dùng, và có khả năng sẽ còn tốt hơn, tối ưu hơn nữa trong tương lai: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
Đây là một lĩnh vực tự nhiên mà chỉ cần dùng một giao thức truyền tải tốt hơn đôi chút so với hiện có cũng đã mang lại lợi ích lớn, nên tôi rất kỳ vọng vào QUIC trong 10 năm tới
Tuy nhiên giao thức TCP hiện được triển khai lại nhanh hơn QUIC một chút, có thể là do chưa tinh chỉnh đủ
Ngoài ra, QUIC trên MacOS chậm hơn so với Linux
https://docs.nats.io/nats-concepts/jetstream
Nó có gần với hàng đợi thông điệp như RabbitMQ hơn không?
https://www.fluvio.io/
Fluvio là một sản phẩm thực sự và có công ty đứng sau nên trưởng thành hơn, nhưng chúng tôi có những ý tưởng riêng để biến Iggy thành một giải pháp streaming thông điệp có sức cạnh tranh
https://github.com/thibauts/styx
Tôi tò mò vì sao các bạn không tiếp tục phát triển nữa
Ngoài ra, tôi thích gu thẩm mỹ của trang web
Chúng tôi là một nhóm nhỏ đã gắn bó lâu năm với các ứng dụng lấy dữ liệu làm trung tâm trong nhiều lĩnh vực suốt vài thập kỷ qua, và đang đặt kỳ vọng vào streaming dữ liệu dựa trên Rust và WebAssembly thay vì Java và JVM
Bài viết tháng 6/2021 trong đó CTO tóm tắt tầm nhìn của Fluvio nằm ở đây: https://news.ycombinator.com/item?id=38880743
Vì các câu hỏi so sánh cứ tiếp tục xuất hiện, tôi cũng có thể chia sẻ tài liệu phía Fluvio đang có. Đó là một công việc tài liệu hóa dài hơi, nhưng chúng tôi có gì thì có thể chia sẻ. Iggy cũng là một sản phẩm làm rất tốt
Tuy nhiên trước khi dùng thử, tôi nghĩ cần hiểu hai điều: làm thế nào để chạy nhiều hơn một server instance, và khi chạy nhiều hơn một thì tương tác hệ thống tệp giữa các server diễn ra thế nào
Khi hỗ trợ cluster, tôi nghĩ nó có thể cạnh tranh với Kafka
Theo tôi biết thì nó cần trình biên dịch nightly, và tôi nghĩ đó không phải lựa chọn tốt khi bảo trì dự án
Phần còn lại hầu hết cũng không phải những tính năng quá cực đoan. Tôi chưa xem sâu mã nguồn, nhưng tất cả đều hợp lý. Ví dụ, một cái là API thư viện chuẩn để tạo container chưa khởi tạo, giúp loại bỏ việc sao chép
Tôi chưa so sánh glommio chạy trên stable với monoio, nhưng có vẻ sẽ thú vị
Vì vậy chúng tôi chọn cách tiếp cận bleeding edge. Dù sao thì để triển khai io_uring và các tối ưu hóa khác cũng sẽ mất thêm vài tháng, và có khả năng chúng tôi sẽ viết lại một số phần cốt lõi để chuyển sang cấu trúc thread theo từng core