Xây dựng một dịch vụ trò chuyện không dễ dàng như bạn nghĩ.
Tôi đã xây dựng đầy đủ các máy chủ, máy khách và SDK XMPP và có thể chứng thực một số vấn đề phức tạp và khó khăn phát sinh. Một nguyên mẫu nơi người dùng nhìn thấy nhau và trò chuyện thật dễ dàng. Một hệ thống đầy đủ tính năng với tạo tài khoản, bảo mật, khám phá, hiện diện, gửi ngoại tuyến và danh sách bạn bè là một thách thức lớn hơn nhiều. Sau đó, mở rộng quy mô đó trên một số lượng máy chủ tùy ý là điều đặc biệt khó khăn.
PubSub là một tính năng được cung cấp bởi Dịch vụ Trò chuyện (xem XEP-60) chứ không phải là một phương tiện truyền thống để xây dựng một dịch vụ trò chuyện. Tôi có thể thấy sự hấp dẫn, nhưng PubSub có thể có những hạn chế.
Một số câu hỏi dành cho bạn:
-
Bạn có đang làm việc này trên Web không? Người dùng sẽ kết nối và phân tích lâu dài hay bạn có giải pháp Ổ cắm web?
-
Có bao nhiêu người dùng? Có bao nhiêu kết nối cho mỗi người dùng? Tỷ lệ số lần ghi trên số lần đọc?
-
Ý tưởng của bạn về việc sử dụng SQS theo cách đó rất thú vị, nhưng có lẽ sẽ không mở rộng. Không có gì lạ khi có 50k người dùng trở lên trên một máy chủ trò chuyện. Nếu bạn đang thăm dò từng Hàng đợi SQS cho mỗi người dùng, bạn sẽ không đi đến đâu gần đó. Tốt hơn là bạn nên có một hàng đợi cho mỗi máy chủ và máy chủ chỉ thăm dò hàng đợi đó. Sau đó, bạn phải tìm ra máy chủ mà người dùng đang sử dụng và đưa thông báo vào đúng hàng đợi.
Tôi nghi ngờ bạn sẽ muốn đi một cái gì đó như:
- Cơ sở dữ liệu RDS lớn trên phần phụ trợ.
- Một loạt các máy chủ front-end xử lý các kết nối máy khách.
- Một số mã Java / C # bậc trung theo dõi mọi thứ và định tuyến thông báo đến đúng nơi.
Để có ý tưởng về sự phức tạp của việc xây dựng một máy chủ trò chuyện, hãy đọc XMPP RFC's:RFC 3920RFC 3921
