Създаването на услуга за чат не е толкова лесно, колкото си мислите.
Изградих пълни XMPP сървъри, клиенти и SDK и мога да свидетелствам за някои от фините и трудни проблеми, които възникват. Прототип, в който потребителите се виждат и чатят е лесно. Пълнофункционалната система със създаване на акаунт, сигурност, откриване, присъствие, офлайн доставка и списъци с приятели е много по-голямо предизвикателство. Особено трудно е да се мащабира това в произволен брой сървъри.
PubSub е функция, предлагана от Chat Services (вижте XEP-60), а не традиционно средство за изграждане на услуга за чат. Виждам привлекателността, но PubSub може да има недостатъци.
Някои въпроси към вас:
-
Правите ли това през мрежата? Ще се свързват ли потребителите и ще се свързват дълго или имате решение за уеб сокети?
-
Колко потребители? Колко връзки на потребител? Съотношение на записа към четенето?
-
Вашата идея за използване на SQS по този начин е интересна, но вероятно няма да се мащабира. Не е необичайно да имате 50k или повече потребители на чат сървър. Ако анкетирате всяка SQS опашка за всеки потребител, няма да се доближите до това. Би било по-добре да имате опашка за всеки сървър и сървърът да анкетира само тази опашка. След това вие трябва да разберете на кой сървър е даден потребител и да поставите съобщението в правилната опашка.
Подозирам, че ще искате да отидете на нещо като:
- Голяма RDS база данни в бекенда.
- Много предни сървъри, обработващи клиентските връзки.
- Някакъв Java/C# код от средно ниво, проследяващ всичко и насочващ съобщенията на правилното място.
За да получите представа за сложността на изграждането на сървър за чат, прочетете XMPP RFC:RFC 3920RFC 3921