Pomysły na skalowanie czatu w AWS?

Tworzenie usługi czatu nie jest tak łatwe, jak mogłoby się wydawać.

Zbudowałem pełne serwery, klientów i SDK XMPP i mogę zaświadczyć o niektórych subtelnych i trudnych problemach, które się pojawiają. Prototyp, w którym użytkownicy widzą się i rozmawiają, jest łatwy. Pełny system funkcji z tworzeniem kont, bezpieczeństwem, wykrywaniem, obecnością, dostarczaniem offline i listami znajomych jest znacznie większym wyzwaniem. Skalowanie tego na dowolnej liczbie serwerów jest szczególnie trudne.

PubSub jest funkcją oferowaną przez Chat Services (patrz XEP-60), a nie tradycyjnym sposobem budowania usługi czatu. Widzę urok, ale PubSub może mieć wady.

Kilka pytań do Ciebie:

1. Czy robisz to przez Internet? Czy użytkownicy będą się łączyć i korzystać z długich połączeń, czy masz rozwiązanie Web Sockets?

2. Ilu użytkowników? Ile połączeń na użytkownika? Stosunek zapisów do odczytów?

3. Twój pomysł na wykorzystanie SQS w ten sposób jest interesujący, ale prawdopodobnie nie będzie się skalował. Nie jest niczym niezwykłym posiadanie 50 000 lub więcej użytkowników na serwerze czatu. Jeśli odpytujesz każdą kolejkę SQS dla każdego użytkownika, nie zbliżysz się do tego. Lepiej byłoby mieć kolejkę dla każdego serwera, a serwer odpytuje tylko tę kolejkę. Następnie musisz dowiedzieć się, na jakim serwerze znajduje się użytkownik i umieścić wiadomość we właściwej kolejce.

Podejrzewam, że będziesz chciał zrobić coś takiego:

1. Duża baza danych RDS na zapleczu.
2. Grupa serwerów front-end obsługujących połączenia klientów.
3. Niektóre kody Java/C# średniego poziomu śledzą wszystko i przekierowują wiadomości we właściwe miejsce.

Aby zorientować się w złożoności budowy serwera czatu, przeczytaj XMPP RFC:RFC 3920RFC 3921