Netty vs Apache MINA

Cả hai đều cung cấp gần như cùng chức năng. Tôi nên chọn cái nào để phát triển máy chủ TCP hiệu năng cao của mình? Những ưu và nhược điểm là gì?

Liên kết tham khảo:

Apache MINA ( nguồn )

Netty ( nguồn )

Mặc dù MINA và Netty có tham vọng tương tự nhau, nhưng chúng khá khác nhau trong thực tế và bạn nên cân nhắc lựa chọn của mình một cách cẩn thận. Chúng tôi đã may mắn khi chúng tôi có nhiều kinh nghiệm với MINA và có thời gian chơi với Netty. Chúng tôi đặc biệt thích API sạch hơn và tài liệu tốt hơn nhiều. Hiệu suất có vẻ tốt hơn trên giấy quá. Quan trọng hơn, chúng tôi biết rằng Trustin Lee sẽ có mặt để trả lời bất kỳ câu hỏi nào chúng tôi có, và anh ấy chắc chắn đã làm điều đó.

Chúng tôi tìm thấy mọi thứ dễ dàng hơn ở Netty. Giai đoạn = Stage. Mặc dù chúng tôi đã cố gắng thực hiện lại chức năng tương tự mà chúng tôi đã có trên MINA, chúng tôi đã làm như vậy từ đầu. Bằng cách làm theo các tài liệu và ví dụ tuyệt vời, chúng tôi đã kết thúc với nhiều chức năng hơn trong mã nhiều hơn, ít hơn nhiều.

Đường ống Netty làm việc tốt hơn cho chúng tôi. Nó đơn giản hơn MINAs, trong đó mọi thứ đều là xử lý và bạn phải quyết định xem có nên xử lý các sự kiện ngược dòng, sự kiện xuôi dòng, cả hai hay tiêu thụ nhiều thứ cấp thấp hơn. Yêu cầu các byte trong bộ giải mã "phát lại" gần như là một niềm vui. Nó cũng rất hay để có thể cấu hình lại đường ống một cách dễ dàng.

Nhưng điểm thu hút ngôi sao của Netty, imho, là khả năng tạo ra các trình xử lý đường ống với "phạm vi bảo hiểm". Có lẽ bạn đã đọc về chú thích bảo hiểm này đã có trong tài liệu, nhưng về cơ bản, nó cung cấp cho bạn trạng thái trong một dòng mã. Không có sự lộn xộn, không có bản đồ phiên, đồng bộ hóa và những thứ tương tự, chúng tôi chỉ đơn giản có thể khai báo các biến thông thường (giả sử là "tên người dùng") và sử dụng chúng.

Nhưng sau đó, chúng tôi đạt được một rào cản. Chúng tôi đã có một máy chủ đa giao thức theo MINA, trong đó giao thức ứng dụng của chúng tôi chạy trên TCP / IP, HTTP và UDP. Khi chúng tôi chuyển sang Netty, chúng tôi đã thêm SSL và HTTPS vào danh sách trong vài phút! Cho đến nay rất tốt, nhưng khi đến với UDP, chúng tôi nhận ra rằng chúng tôi đã trượt lên. MINA rất tốt với chúng tôi ở chỗ chúng tôi có thể coi UDP là giao thức "được kết nối". Dưới Netty không có sự trừu tượng như vậy. UDP là không kết nối và Netty đối xử với nó như vậy. Netty thể hiện nhiều hơn bản chất không kết nối của UDP ở mức thấp hơn MINA. Có những điều bạn có thể làm với UDP theo Netty hơn là bạn không thể thực hiện được sự trừu tượng hóa ở cấp độ cao hơn mà MINA cung cấp, nhưng chúng tôi đã dựa vào đó.

Thật không đơn giản để thêm một trình bao bọc "UDP được kết nối" hoặc một cái gì đó. Trước những hạn chế về thời gian và theo lời khuyên của Trustin, cách tốt nhất để tiến hành là triển khai nhà cung cấp dịch vụ vận tải của chúng tôi tại Netty, điều này sẽ không nhanh chóng, cuối cùng chúng tôi phải từ bỏ Netty.

Vì vậy, hãy nhìn kỹ vào sự khác biệt giữa chúng và nhanh chóng đến giai đoạn mà bạn có thể kiểm tra bất kỳ chức năng khó khăn nào đang hoạt động như mong đợi. Nếu bạn hài lòng rằng Netty sẽ thực hiện công việc, thì tôi sẽ không ngần ngại thực hiện nó qua MINA. Nếu bạn đang chuyển từ MINA sang Netty thì cũng áp dụng tương tự, nhưng điều đáng chú ý là hai API thực sự khác nhau đáng kể và bạn nên xem xét viết lại ảo cho Netty - bạn sẽ không hối tiếc!

MINA có nhiều tính năng vượt trội hơn với chi phí phức tạp và hiệu suất tương đối kém. Một số tính năng được tích hợp vào lõi quá chặt để có thể loại bỏ ngay cả khi người dùng không cần chúng. Trong Netty, tôi đã cố gắng giải quyết các vấn đề thiết kế như vậy trong khi vẫn giữ được những điểm mạnh đã biết của MINA.

Hiện tại, hầu hết các tính năng có sẵn trong MINA cũng có sẵn trong Netty. Theo tôi, Netty có API sạch hơn và nhiều tài liệu hơn vì Netty là kết quả của việc cố gắng xây dựng lại MINA từ đầu và giải quyết các vấn đề đã biết. Nếu bạn thấy rằng một tính năng thiết yếu bị thiếu, xin vui lòng gửi đề xuất của bạn lên diễn đàn. Tôi rất vui lòng giải quyết mối quan tâm của bạn.

Cũng cần lưu ý rằng Netty có chu kỳ phát triển nhanh hơn. Đơn giản, hãy kiểm tra ngày phát hành của các bản phát hành gần đây. Ngoài ra, bạn nên xem xét rằng nhóm MINA sẽ tiến hành viết lại chính, MINA 3, có nghĩa là họ sẽ phá vỡ hoàn toàn khả năng tương thích API.

Tôi đã thực hiện thử nghiệm 2 triển khai "Google Protobuffer RPC" trong đó một triển khai dựa trên Netty (netty-protobuf-rpc) và khác dựa trên mina (protobuf-mina-rpc). Netty cuối cùng đã nhanh hơn (+ - 10%) cho tất cả các kích cỡ thư - sao lưu yêu cầu hiệu suất tổng thể trên trang web của Netty. Vì bạn muốn tận dụng mọi hiệu quả trong mã của mình khi bạn sử dụng thư viện RPC như vậy, cuối cùng tôi đã viết protobuf-rpc-pro dựa trên Netty. Tôi đã sử dụng MINA trong quá khứ, nhưng thấy tài liệu của họ về nội dung 2.0 có lỗ hổng lớn và việc phá vỡ khả năng tương thích ngược API là một điểm trừ lớn.

MINA và Netty ban đầu được thiết kế và xây dựng bởi cùng một tác giả. Đó là lý do tại sao chúng rất giống nhau. MINA được thiết kế ở mức cao hơn một chút với nhiều tính năng hơn một chút, trong khi Netty nhanh hơn một chút. Tôi nghĩ rằng không có nhiều sự khác biệt, các khái niệm cơ bản là như nhau.

Trong trang web của Netty, bạn có thể tìm thấy một số báo cáo hiệu suất . Như mong đợi :-) họ chỉ ra Netty là khuôn khổ có hiệu suất tốt nhất.

Tôi chưa bao giờ sử dụng Netty, nhưng tôi đã sử dụng MINA để thực hiện giao thức TCP. Việc thực hiện mã hóa và giải mã rất dễ dàng, nhưng việc thực hiện bộ máy trạng thái không quá dễ dàng. MINA cung cấp một số lớp để hỗ trợ bạn khi triển khai máy trạng thái, nhưng tôi thấy chúng khó sử dụng. Cuối cùng, chúng tôi quyết định bỏ MINA và thực hiện giao thức từ đầu, và thật bất ngờ là chúng tôi đã kết thúc với một máy chủ nhanh hơn.

Tôi thích Netty.

Twitter cũng chọn Netty để xây dựng Hệ thống tìm kiếm mới của mình và tăng tốc lên gấp 3 lần.

Tham chiếu: Tìm kiếm Twitter bây giờ nhanh hơn gấp 3 lần

Chúng tôi đã chọn Netty thay vì một số đối thủ cạnh tranh khác, như Mina và Jetty, vì nó có API sạch hơn, tài liệu tốt hơn và quan trọng hơn, vì một số dự án khác tại Twitter đang sử dụng khung này.

Tôi chỉ từng sử dụng MINA để xây dựng một máy chủ http nhỏ. Những vấn đề lớn nhất mà tôi gặp phải với nó cho đến nay:

1. Nó sẽ giữ "yêu cầu" và "phản hồi" của bạn trong bộ nhớ. Đây chỉ là một vấn đề vì giao thức tôi chọn sử dụng là http. Bạn có thể sử dụng giao thức của riêng bạn tuy nhiên để khắc phục điều này.
2. Không có tùy chọn để cung cấp một luồng ra khỏi đĩa trong trường hợp bạn muốn cung cấp các tệp lớn. Một lần nữa có thể được giải quyết bằng cách thực hiện giao thức của riêng bạn

Những điều tốt đẹp về nó:

1. Có thể xử lý rất nhiều kết nối
2. Nếu bạn chọn thực hiện một số loại hệ thống làm việc phân tán thì việc biết khi nào một trong các nút của bạn bị hỏng và mất kết nối là hữu ích để khởi động lại công việc trên một nút khác.