At bygge en chattjeneste er ikke så let, som du skulle tro.
Jeg har bygget komplette XMPP-servere, klienter og SDK'er og kan attestere nogle af de subtile og vanskelige problemer, der opstår. En prototype, hvor brugerne ser hinanden og chatter er let. Et system med fuld funktioner med kontooprettelse, sikkerhed, opdagelse, tilstedeværelse, offline levering og vennelister er meget mere en udfordring. Det er især svært at skalere det på tværs af et vilkårligt antal servere.
PubSub er en funktion, der tilbydes af Chat Services (se XEP-60) snarere end en traditionel måde at bygge en chattjeneste på. Jeg kan se lokket, men PubSub kan have ulemper.
Nogle spørgsmål til dig:
-
Gør du dette over nettet? Skal brugere forbinde og lange polere, eller har du en Web Sockets-løsning?
-
Hvor mange brugere? Hvor mange forbindelser pr. bruger? Forholdet mellem skrivning og læsning?
-
Din idé til at bruge SQS på den måde er interessant, men vil sandsynligvis ikke skalere. Det er ikke usædvanligt at have 50.000 eller flere brugere på en chatserver. Hvis du poller hver SQS-kø for hver bruger, kommer du ikke i nærheden af det. Du ville være bedre stillet at have en kø for hver server, og serveren poller kun den kø. Så er det op til dig at finde ud af, hvilken server en bruger er på og sætte beskeden i den rigtige kø.
Jeg formoder, at du vil gå noget som:
- En stor RDS-database på backend.
- En flok front-end-servere, der håndterer klientforbindelserne.
- Nogle mellemliggende Java-/C#-kode sporer alt og dirigerer beskeder til det rigtige sted.
For at få en idé om kompleksiteten ved at bygge en chatserver, læs XMPP RFC'erne:RFC 3920RFC 3921