Vytvoření chatovací služby není tak snadné, jak si myslíte.
Postavil jsem kompletní servery XMPP, klienty a sady SDK a mohu potvrdit některé jemné a obtížné problémy, které se objevují. Prototyp, kde se uživatelé vidí a chatují, je snadný. Systém plných funkcí s vytvořením účtu, zabezpečením, zjišťováním, přítomností, offline doručováním a seznamy přátel je mnohem větší výzvou. Škálovat to na libovolný počet serverů je obzvláště obtížné.
PubSub je funkce nabízená chatovacími službami (viz XEP-60) spíše než tradičním způsobem budování chatovací služby. Vidím kouzlo, ale PubSub může mít nevýhody.
Několik otázek pro vás:
-
Děláte to přes web? Budou se uživatelé připojovat a zdlouhavě vyhledávat, nebo máte řešení Web Sockets?
-
Kolik uživatelů? Kolik připojení na uživatele? Poměr zápisů ke čtení?
-
Váš nápad na použití SQS tímto způsobem je zajímavý, ale pravděpodobně se nezmění. Není neobvyklé mít na chatovacím serveru 50 000 nebo více uživatelů. Pokud se dotazujete na každou frontu SQS pro každého uživatele, nikam se tomu nepřiblížíte. Bylo by lepší mít frontu pro každý server a server se dotazuje pouze této fronty. Pak je na vás, abyste zjistili, na jakém serveru se uživatel nachází, a zařadili zprávu do správné fronty.
Mám podezření, že budete chtít něco jako:
- Velká databáze RDS na backendu.
- Skupina front-end serverů obsluhujících připojení klientů.
- Nějaký střední kód Java / C# kód, který vše sleduje a směruje zprávy na správné místo.
Chcete-li získat představu o složitosti budování chatovacího serveru, přečtěte si XMPP RFC:RFC 3920RFC 3921