Att bygga en chattjänst är inte så lätt som du skulle kunna tro.
Jag har byggt kompletta XMPP-servrar, klienter och SDK:er och kan intyga några av de subtila och svåra problem som uppstår. En prototyp där användare ser varandra och chattar är lätt. Ett komplett system med kontoskapande, säkerhet, upptäckt, närvaro, offlineleverans och vänlistor är mycket mer av en utmaning. Att sedan skala det över ett godtyckligt antal servrar är särskilt svårt.
PubSub är en funktion som erbjuds av Chat Services (se XEP-60) snarare än ett traditionellt sätt att bygga en chattjänst. Jag kan se lockelsen, men PubSub kan ha nackdelar.
Några frågor till dig:
-
Gör du detta över webben? Kommer användare att ansluta och långpola eller har du en Web Sockets-lösning?
-
Hur många användare? Hur många anslutningar per användare? Förhållandet mellan skrivning och läsning?
-
Din idé om att använda SQS på det sättet är intressant, men kommer förmodligen inte att skalas. Det är inte ovanligt att ha 50 000 användare eller fler på en chattserver. Om du pollar varje SQS-kö för varje användare kommer du inte att komma i närheten av det. Du skulle vara bättre att ha en kö för varje server, och servern pollar bara den kön. Sedan är det upp till dig att ta reda på vilken server en användare är på och sätta meddelandet i rätt kö.
Jag misstänker att du kommer att vilja gå något i stil med:
- En stor RDS-databas på backend.
- Ett gäng front-end-servrar som hanterar klientanslutningarna.
- Någon mellannivå Java/C#-kod spårar allt och dirigerar meddelanden till rätt plats.
För att få en uppfattning om komplexiteten i att bygga en chattserver, läs XMPP RFC:s:RFC 3920RFC 3921