[TOC]

Основы технологии обмена мгновенными сообщениями

Улучшение технического поля обмена мгновенными сообщениями

проблема

1. Подготовка (выбор протокола)

   • Выбор протокола сетевой передачи и выбор протокола передачи данных

2. ххх архитектура проекта

   • Преимущества и недостатки архитектуры
   • Путь к архитектурному совершенствованию

3. Ключевые технические моменты и стратегический механизм IM

   • Как сделать так, чтобы сообщения не терялись/перепутывались/дублировались
   • Политика сердцебиения
   • стратегия воссоединения

4. Типичный сценарий службы обмена мгновенными сообщениями

   • Пользователь А отправляет сообщение пользователю Б
   • Пользователь A отправляет сообщение группе C

5. Краткий анализ структуры хранилища

Подготовка (выбор протокола)

Какой сетевой транспортный протокол (TCP/UDP/HTTP) использовать?

1. Хотя протокол udp имеет лучшую производительность в режиме реального времени, решить проблему безопасной и надежной передачи и взаимодействия сообщений между различными клиентами сложно, и его слишком сложно реализовать.В настоящее время большинство IM-архитектур не используют UDP для реализации. .

2. Но зачем вообще нужен HTTP?

   • Основное длинное соединение TCP используется для отправки и получения сообщений в режиме реального времени. Другие запросы ресурсов не занимают это соединение, чтобы обеспечить производительность в реальном времени.

   • http может использоваться для реализации протокола состояния (может быть разработан с помощью php)

     • Круг друзей
     • Личная информация пользователя (информация о друзьях, номер счета, поиск и т. д.)
     • Используйте режим извлечения для офлайн-сообщений, чтобы избежать чрезмерной нагрузки на TCP-канал и повлиять на эффективность мгновенной доставки сообщений.
     • и т.д...

   • Когда IM общается с изображениями/языками/большими граффити: http может легко обрабатывать такие функции, как возобновление точки останова и загрузка из нескольких частей.

3. TCP: поддерживать длинные соединения, обеспечивать сообщения в реальном времени и соответствовать протоколам передачи данных.

   • Цель: Своевременно отправлять и получать сообщения

Какой протокол передачи данных использовать?

1. Принцип выбора протокола обмена мгновенными сообщениями в целом таков: легко расширять, удобно охватывать различную бизнес-логику и в то же время экономить трафик. Необходимость экономии трафика особенно актуальна на мобильных IM!!!

   • xmpp: протокол с открытым исходным кодом и широкими возможностями расширения.Он реализован на разных языках на каждом конце (включая сервер), что удобно для разработчиков. Но есть и много недостатков: XML слаб в выразительности, слишком много избыточной информации, большой трафик, много провалов в реальном использовании.

   • MQTT:Протокол простой и трафик небольшой, но это не протокол, специально разработанный для обмена мгновенными сообщениями, а в основном используется для push-уведомлений.Вам необходимо внедрить групповые, связанные с друзьями и т. д. в вашем бизнесе (В настоящее время компания использует MQTT для реализации общей структуры обмена мгновенными сообщениями.).

   • SIP: Связанные модули, используемые для VoIP, протокол сигнализации SIP - это управление текстовым элементом является более сложным.

   • Частный протокол: реализуйте протокол самостоятельно. Большинство популярных приложений для обмена мгновенными сообщениями используют частные протоколы. Хорошо спроектированный частный протокол обычно имеет следующие преимущества: высокая эффективность, экономия трафика (обычно с использованием двоичных протоколов), высокая безопасность и сложность взлома.Проект xxx в основном представляет собой частный пользовательский протокол , а более поздняя общая архитектура обмена мгновенными сообщениями использует MQTT.

2. Соображения по разработке протокола:

   • Размер сетевых данных - Занимаемая полоса пропускания, эффективность передачи: хотя объем передаваемых данных невелик для одного пользователя, чтобы серверная сторона могла выдержать большое количество одновременных передач данных с большим объемом данных, необходимо учитывать полосу пропускания, занимаемую данными, и постарайтесь не иметь избыточных данных, чтобы занимать меньшую полосу пропускания, меньше ресурсов, меньше сетевых операций ввода-вывода и повышать эффективность передачи;

   • Безопасность сетевых данных — сетевая безопасность конфиденциальных данных: часть передаваемых данных для связанных служб является конфиденциальными данными, поэтому необходимо рассмотреть возможность шифрования части передаваемых данных (Проект XXX в настоящее время предоставляет библиотеку шифрования C ++ для клиентов для использования клиентов)

   • Сложность кодирования - сложность сериализации и десериализации, эффективность, масштабируемость структур данных

   • Общность протокола — общая спецификация: типы данных должны быть кросс-платформенными, а форматы данных — общими.

3. Общие протоколы сериализации

   • Протоколы с открытым исходным кодом, которые предоставляют библиотеки сериализации и десериализации: pb, Thrift.Расширения достаточно удобны, сериализация и десериализация удобны (В настоящее время проект xxx использует pb)

   • Текстовый протокол: xml, json Сериализация и десериализация несложные, но занимают много места (Общий http-интерфейс в формате json.).

ххх системная архитектура проекта

Предварительная архитектура

...

Улучшенная архитектура

...

Преимущества и недостатки архитектуры.

преимущество

1. Поддержка методов TCP и HTTP, а также отдельных бизнес-сервисов с небольшой корреляцией.

   • php server
   • router server
   • user center
   • Access server
   • oracle server

2. Сервис поддерживает параллельное расширение, что удобно и нечувствительно к пользователю.

3. Инкапсуляция уровня базы данных кеша, вызывающая сторона может напрямую вызывать интерфейс.

4. За исключением сервера доступа с отслеживанием состояния, другие службы не отслеживают состояние.

5. Каждая служба взаимодействует между машинами через rpc.

6. Oracle полностью модульный, немного похож на шаблон MVC, развязку кода и функциональную развязку.

недостаток

1. Оракул слишком велик, и некоторые предприятия можно извлечь

   • недостаток

     • Бизнес слишком большой, разрабатывать его нескольким людям неудобно, легко вызвать конфликты кода.
     • Если небольшая функция не работает, вся служба может быть недоступна.

   • Улучшать

     • Сервер apns связан с оракулом, а apns можно извлечь отдельно.(Теперь проект xxx начал получать доступ к общей системе push-push, аналогично извлечению apns.).

2. push-сервер не занимается бизнесом, просто перенаправляет запросы между Access и оракулом

   • недостаток

     • Необходимо поддерживать относительно безвкусный сервис отдельно, что увеличивает стоимость эксплуатации и обслуживания.

   • Улучшать

     • Включение push-сервера в Access уменьшает уровень промежуточных звеньев вызова rpc, снижает затраты на эксплуатацию и техническое обслуживание и повышает эффективность (Новая архитектура проекта ххх убила push-сервер и интегрировала его в Access.)

3. Сервер доступа тесно связан с пользователями, и при сохранении длительного соединения все же есть некоторые сервисы.

   • недостаток

     • Поддержание длительного соединения, если обновление будет обновлено, это неизбежно повлияет на состояние соединения онлайн-пользователей.
     • Иногда некоторые дела, снижают стабильность длительного соединения

   • Улучшать:

     • Извлеките сервер connd из той части, которая поддерживает долгое соединение с сервером доступа:
       • Поддерживай только долгое соединение, отправляй и получай пакеты.В настоящее время проект xxx совершенствует эту архитектуру и еще не запущен.)

Ключевые технические моменты IM

Технический момент первый: как убедиться, что сообщение достижимо (не потеряно)/уникально (не повторяется)/упорядочено (не не по порядку)

Простейшее сохранение порядка (не вышло из строя)

1. Почему он может выйти из строя?

   • Для онлайн-сообщений одно отправление и одно получение, конечно, при нормальных обстоятельствах проблем не будет.

     • Однако, если вы получаете сообщение, когда вдруг сетевые аномалии, и не получаете сообщение?
       • Сервер повторно отправит или перенесет в автономное хранилище (Механизм проекта ххх сразу переносится в оффлайн хранилище)

   • Для офлайн-сообщений их может быть много.

     • При извлечении автономные сообщения обычно извлекаются одновременно.
       • При наличии нескольких сообщений необходимо обеспечить порядок полученных сообщений.

2. Как я могу убедиться, что он не вышел из строя?

   • После отправки каждого сообщения на сервер будет сгенерирован глобально уникальный msgid, и этот msgid должен увеличиваться постепенно (Генерация msgid будет иметь механизм синхронизации для обеспечения уникальности параллелизма.)

   • Для каждого сообщения будет указано время генерации сообщения с точностью до миллисекунд.

   • При извлечении нескольких сообщений после получения данных отсортируйте их по размеру msgid.

Гарантия уникальности (отсутствие дубликатов)

1. Почему сообщение может быть повторено?

   • Нестабильность мобильной сети может привести к тому, что сообщение не будет отправлено в один прекрасный день, или оно может быть отправлено, а подтверждение ответа не получено.

     • В этом случае может потребоваться механизм повторной передачи, который может потребоваться как клиенту, так и серверу.

     • Поскольку существует механизм повторения, возможно, что полученные сообщения повторяются.

2. Как это решить?Чтобы не было повторений, лучше всего иметь дело с клиентом и сервером

   • В метаструктуру сообщения добавляется поле isResend.Когда клиент отправляет повторно, это поле устанавливается, чтобы указать, что это дубликат, и сервер использует его для последующей оценки.

   • Сервер кэширует пакет последних msgid (так называемый localMsgId) для каждого пользователя, например, 50 кэшей.

   • После того, как сервер получает сообщение, он определяет, есть ли isResend и этот msgid в списке localMsgId.Если сообщение отправляется повторно, сервер не выполняет последующую обработку.

   • Потому что только isResend не может подготовить суждение, потому что, возможно, клиент делает повторную отправку, но сервер не получает...

Гарантированная достижимость (не потерянная и не тяжелая)

1. Самый простой заключается в том, что каждый раз, когда сервер отправляет сообщение получателю, требуется подтверждение для обеспечения достижимости.

   • Но ack также может быть потерян в слабом сетевом окружении.

2. Данные, возвращаемые сервером клиенту, могут быть не получены клиентом или клиент может не получить ответа.

   • Следовательно, должен быть совершенный механизм подтверждения, чтобы сообщить клиенту, что он действительно получил.один раз и только один раз.

3. Рассмотрим ситуацию, когда вход в учетную запись осуществляется с разных терминалов.

   • Сообщение должно иметь возможность быть отправленным терминалу, вошедшему в систему в данный момент, и оно не должно иметь возможности повторно отправлять или извлекать данные, которые были извлечены ранее.

Технический момент 2: механизм msgID

Вот два варианта для ознакомления (Одна и та же основная идея, разные методы реализации)

Механизм msgid серийного номера и механизм подтверждения msgid (план 1):

• Каждому сообщению для каждого пользователя должен быть присвоен уникальный msgid

• Сервер будет хранить список msgid каждого пользователя.

• Клиент сохраняет максимальный полученный msgid

преимущество:

1. В соответствии с разницей в последовательности между сервером и мобильным терминалом легко поэтапно доставлять сообщения, которые не получены мобильным терминалом.

2. В случае слабого сетевого окружения вероятность потери пакетов относительно высока, в это время часто бывает так, что обратные пакеты сервера не могут дойти до мобильного телефона. Поскольку мобильный терминал будет обновлять локальную последовательность только после получения точного сообщения, даже если ответный пакет сервера будет потерян, мобильный терминал будет ждать тайм-аута, чтобы повторно получить сообщение с сервера в старой последовательности, и он также будет возможно правильно получить неполученное сообщение.сообщение отправлено.

3. Поскольку последовательность, сохраненная на мобильном терминале, является наибольшей последовательностью для подтверждения приема сообщения, каждый раз, когда мобильный терминал получает сообщение от сервера, также можно рассматривать как подтверждение последнего принятого сообщения. Когда учетная запись регистрируется несколькими мобильными терминалами по очереди, пока сервер хранит подтвержденную последовательность на мобильном терминале, он может просто понять, что подтвержденные сообщения не будут отправляться повторно, и альтернативные входы между разными мобильными терминалами не будут выполняться. Прием сообщений, принятых другими мобильными терминалами.

Пользователи получают сообщения, когда они входят в систему с разных терминалов

Если мобильный телефон A принимает Seq_cli = 100 для получения сообщений от сервера, а Seq_svr сервера = 150, то мобильный телефон A может получать сообщения с последовательностью [101 - 150], и мобильный телефон A установит локальный Seq_cli на 150.

В следующий раз, когда мобильный телефон А подойдет к серверу для получения сообщений, в это время Seq_cli = 150 и Seq_svr сервера = 200, тогда мобильный телефон А сможет принимать сообщения с последовательностью [151 - 200].

Если первоначальный пользователь мобильного телефона A переключается на мобильный телефон B для входа в систему и использует Seq_cli = 120 для получения сообщений на сервере, поскольку сервер подтвердил, что сообщение с последовательностью

Механизм msgid серийного номера и механизм подтверждения msgid (план 2: текущий план проекта xxx):

• Каждому сообщению для каждого пользователя должен быть присвоен уникальный msgid

• Сервер будет хранить список msgid каждого пользователя.

• Клиент сохраняет максимальный полученный msgid

  • Для одиночного чата, группового чата и анонимного хранилища (идентификатор, соответствующий человеку, идентификатор, соответствующий группе).

считать

Каковы преимущества и недостатки этих двух методов?

1. Во втором способе механизм подтверждения — еще один http-запрос, однако он может обеспечить своевременную ликвидацию данных

2. В первом методе механизм подтверждения заключается в том, чтобы ждать, пока в следующий раз вытащит данные для подтверждения, никаких дополнительных запросов не добавляется, но удаление данных происходит несвоевременно.

Технический пункт третий: стратегия сердцебиения

Функция Heartbeat: поддержка долгосрочных TCP-соединений и обеспечение долговременной стабильности соединения. Это единственная функция для мобильных сетей?

1. На самом деле сердцебиение выполняет две функции.

   • Сердцебиение обеспечивает функцию поддержания соединения между клиентом и сервером, и сервер использует это, чтобы определить, находится ли клиент в сети.

   • Heartbeat также необходимо поддерживать GGSN мобильной сети.

     • Оператор преобразует IP-адрес мобильной интрасети и IP-адрес экстрасети через NAT (преобразование сетевого адреса), чтобы окончательно подключиться к Интернету.Модуль GGSN (узел поддержки шлюза GPRS) представляет собой процесс реализации NAT, но большинство операторов уменьшают загрузка таблицы сопоставления шлюза NAT, если канал не имеет связи в течение определенного периода времени, его соответствующая таблица будет удалена, что приведет к прерыванию канала.Поэтому оператор намеренно сокращает время простоя соединения, чтобы сохранить канал ресурсы, но это преднамеренное поведение выпуска может привести к пассивному отключению нашего соединения (До проекта ххх сердцебиение отключалось оператором, позже стратегия сердцебиения была улучшена, и в будущем стратегия сердцебиения будет продолжать совершенствоваться.)

     • Проще говоря, решение NAT состоит в том, чтобы изменить способ, которым в прошлом каждый пользователь широкополосного доступа независимо выделял IP-адрес общедоступной сети, чтобы выделить каждому пользователю IP-адрес интрасети. Затем оператор единообразно развертывает устройства NAT для пользователей доступа. NAT предназначен для подключения пользователей к сети.Инициированный IP-адрес интрасети транслируется в общедоступный IP-адрес в виде подключения к порту, а затем подключается к внешним сетевым ресурсам.

     • С мобильного телефона на GGSN — это интрасеть, а затем выполните преобразование адреса NAT/PAT в GGSN, чтобы преобразовать его в адрес пула адресов общедоступной сети GGSN, поэтому адрес, представленный вашим мобильным телефоном в Интернете, является общедоступным сетевым адресом этого пул адресов.

2. Наиболее распространенным является отправка сердцебиений через фиксированное время (например, 4 с половиной минуты), но это недостаточно разумно.

   • Причина для 4,5 минут заключается в том, что время ожидания NAT каждого оператора мобильной связи интегрировано.

   • Время пульса слишком мало, что потребляет трафик/мощность и увеличивает нагрузку на сервер.

   • Если время подтверждения слишком велико, соединение может быть пассивно разорвано, поскольку политика оператора исключает соответствующую запись в таблице NAT.

3. Политика интеллектуального пульса

   • Поддержка мобильной сети GGSN (Gateway GPRS Support Node)

     • Большинство операторов мобильных беспроводных сетей удаляют соответствующую запись в таблице NAT, если в течение определенного периода времени по каналу отсутствует передача данных, что приводит к разрыву канала. Тайм-аут NAT — важный фактор, влияющий на срок службы TCP-соединений (особенно внутренних), поэтому клиент автоматически рассчитывает время тайм-аута NAT для динамической настройки интервала пульсации, что является очень важным моментом оптимизации.

   • Обратитесь к набору алгоритмов адаптивного сердцебиения WeChat:

     • Чтобы обеспечить своевременное получение сообщений, используется фиксированное сердцебиение, когда приложение активно на переднем плане.

     • Когда приложение переходит в фоновый режим (или экран закрывается на переднем плане), сначала используйте несколько минимальных тактов для поддержания длинной связи. Затем введите фоновый адаптивный расчет сердцебиения. Целью этого является попытка выбрать период времени, когда пользователь неактивен, чтобы уменьшить влияние несвоевременного сбора сообщений, которые могут быть сгенерированы расчетом пульса.

4. Упростите пакеты пульса, убедитесь, что размер пакета пульса не превышает 10 байт, и отрегулируйте интервал пакетов пульса в соответствии с передним и фоновым статусом приложения (в основном Android)

Технический пункт четвертый: стратегия отключения и повторного подключения

После отключения выберите разные интервалы повторного подключения в соответствии с разными статусами. При возникновении ошибки в локальной сети не нужно регулярно переподключаться, в этом случае нужно только следить за состоянием сети и ждать, пока сеть восстановится, чтобы переподключиться. Если сеть меняется очень часто, особенно когда приложение работает в фоновом режиме, к повторному подключению также можно добавить определенный контроль частоты, чтобы обеспечить передачу определенных сообщений в режиме реального времени и избежать чрезмерного энергопотребления.

1. Кратчайший интервал между отключением и повторным подключением выполняется в последовательности 4, 8, 16... (максимум не более 30) в единицах секунд (с), чтобы избежать частых отключений и повторных подключений, тем самым снижая нагрузку на сервер. Эта политика сбрасывается, когда сервер получает правильный пакет

2. Если есть сеть, но соединение не установлено, оно будет непрерывно повторяться в последовательности с интервалами 2, 2, 4, 4, 8, 8, 16, 16... (максимум не более 120) в секундах (с). .

3. Чтобы предотвратить появление лавинного эффекта, когда мы обнаруживаем сбой сокета (аномалии сервера), мы не переподключаемся немедленно, а позволяем клиенту случайным образом спать в течение определенного периода времени (или других стратегий, упомянутых выше) перед подключением к серверу, чтобы мы могли сделать так, чтобы разные клиенты не подключались одновременно при перезапуске сервера, что приводило к лавинному эффекту.

Типичный процесс бизнес-сценария обмена мгновенными сообщениями

1. Пользователь А отправляет сообщение пользователю Б

   • A получает токен через пароль учетной записи.
   • A берет токен для входа
   • Сервер кэширует информацию о пользователе и поддерживает состояние входа в систему.
   • Пакет данных и отправить его на сервер
   • Сервер определяет, является ли пользователь A пользователем риска
   • Сервер выполняет проверку чувствительного слова в сообщении (это важно)
   • Сервер генерирует msgid
   • Сервер выполняет обнаружение друзей (A/B)
   • Сервер выполняет дубликат обнаружения отправки
   • Сервер получает информацию о соединении B и оценивает онлайн-статус.
   • Если онлайн, отправьте напрямую на B, слейте в кеш и БД
   • Если он не в сети, сохраните его напрямую.Если это ios, выполните apns.
   • Online B, после получения сообщения, ответьте на ack для подтверждения.

2. Пользователь A отправляет сообщение группе C

структура хранения

непрочитанный список индексов

• Важность индекса непрочитанных сообщений состоит в том, чтобы обеспечить надежность сообщения и служить структурой индекса для автономных пользователей, чтобы получить список непрочитанных сообщений.

• Индекс непрочитанных сообщений состоит из двух частей, каждая из которых хранится в Redis:

  • Запишите непрочитанную хэш-структуру каждого друга пользователя
  • Каждому другу соответствует структура zset, в которой хранятся идентификаторы всех непрочитанных сообщений.

• Предположим, у A есть три друга B, C, D. А не в сети. B отправляет 1 сообщение в A, C отправляет 2 сообщения в A, а D отправляет 3 сообщения в A, тогда структура непрочитанного индекса A в это время такова:

• хэш-структура

  • B-1
  • C-2
  • D-3

• структура zset

User	MsgId 1	MsgId 2	MsgId 3
B	1	-	-
C	4	7	-
D	8	9	10

• Очередь сообщений обновляет восходящую ссылку и означает индекс непрочитанных сообщений, хэш-структуру плюс соответствующее поле, а затем добавляет к соответствующей структуре идентификатора сообщения zset друзей.

• При получении ack индекс непрочитанного сообщения наоборот сохраняется, поле, соответствующее хэш-структуре, декрементируется на 1, а затем id сообщения удаляется из структуры zset в соответствующем друге.

Нисходящая линия сообщения (получение непрочитанных сообщений)

В этом процессе пользователь получает непрочитанные сообщения в автономном режиме.

Этот процесс в основном обслуживается интерфейсом сеансы/последние. Процесс выглядит следующим образом:

• hgetall считывает хеш-структуру в индексе непрочитанных сообщений.
• Пройдите по хэш-структуре, если непрочитанное сообщение не равно 0, прочитайте структуру zset соответствующего друга и выньте список идентификаторов непрочитанных сообщений.
• Прочитайте содержимое сообщения из кеша (или проникните в базу данных) через список идентификаторов сообщений и отправьте его клиенту.

Так же, как и онлайн-процесс, после прочтения непрочитанного сообщения автономный клиент должен отправить и получить подтверждение на бизнес-конец, сообщая ему, что непрочитанное сообщение было успешно доставлено, а бизнес-конец отвечает за поддержание индекса непрочитанных сообщений пользователя. .

В отличие от онлайн-процесса, это подтверждение получения реализуется путем вызова интерфейса messages/lastAccessedId. Клиенту необходимо передать хэш-структуру на сервер, ключ — это идентификатор друга, отправленный через интерфейс сеансов/последних, а значение — наибольший идентификатор сообщения, соответствующий другу в списке непрочитанных сообщений интерфейса сеансы/последние.

После того, как сервер получает эту хеш-структуру, он проходит по ней.

• Очистить соответствующий кеш
• Очистите структуру zset соответствующего друга с помощью операции zremrangebyscore.
• Структура хэш-индекса непрочитанных сообщений в возвращаемом значении вычитается из zremrangebyscore

На этом процесс обслуживания автономного индекса непрочитанных сообщений завершен.

Процесс обработки очереди

• Если сообщение помечено как автономное, сообщение сохраняется, записывается в кеш (в кеш записываются только офлайн-сообщения), индекс непрочитанных сообщений обновляется, а затем вызывается apns для отправки.

• Если сообщение помечено как онлайн, оно может быть сохранено напрямую, так как B уже получил сообщение.

• Если сообщение помечено как повторно доставленное, запишите сообщение в кеш, а затем вызовите apns для отправки.

Вопросы после обсуждения

Необходимо ли для рассмотрения и цели разделения уровня соединения Доступ к слою сервера connd?

1. Цель выделения:

   • Слой соединения более стабилен
   • Уменьшите число перезапусков и упростите обновление службы Access

2. Неужели может быть такой эффект?

   • Уровень подключения более стабилен — — — Для определения большей стабильности необходимы точные индикаторы, поскольку служба доступа не является тяжелой и в настоящее время не является узким местом.

     • В настоящее время служба Access не тяжелая, неужели нужно ее разбивать?

     • Если вы действительно хотите разделить, это не разделение, он разделен на Oracle, похоже на концепцию микросервисов

     • Таким образом, стабильность не отражена в оригинальном Connd Design, Thinner и не предпринимает бизнес, и теперь есть некоторый доступ к бизнес-логике, то возможность модернизации ее относительно высоки.

     • Цель разделения доступа состоит в том, чтобы сделать слой, поддерживающий соединение, достаточно тонким, чтобы, каким бы тонким он ни был для изменения бизнеса, ему не нужно было бы обновлять код (tcp не будет прерываться).

   • Сокращение перезапусков для облегчения обновления служб доступа — — — Перезапуск и обновление не могут быть достигнуты путем добавления уровня служб, и требуются другие механизмы, чтобы гарантировать, что сервер можно будет обновить, не затрагивая пользователей при длительном TCP-соединении.

     • Разделенный сервер может все еще нуждаться в перезагрузке.Что мне делать в это время?Ключевая проблема все еще не решена

     • Добавление уровня сервисов предназначено для использования общей памяти, а connd управляет только подключениями. Когда доступ обновляется и обновляется, пользователь не будет отключен.

   • Если вы добавите службу, будет еще одна ссылка, что может привести к тому, что ссылка на службу будет слишком длинной, и запрос будет проходить через большее количество служб, что сделает службу более недоступной, потому что доступность каждой службы должна быть гарантирована. до 99,999% (5 9) Сложно, добавление услуги снизит доступность всей услуги.

3. Улучшение архитектуры должно поддерживаться данными. Чтобы быть эффективным, необходимо, чтобы вывод данных подтверждал эффективность улучшения. В противном случае на внесение улучшений ушло бы два месяца, а результаты были бы бесполезными, тратой сил и времени и сокращением разработки. эффективный

   • Каждая фаза архитектуры может быть разной, в зависимости от пользователя, чтобы определить количество тепла и текущую стадию.

Как обеспечить перезапуск и обновление службы уровня доступа?Расширение/сокращение службы?

1. Решение: добавьте сигнальное взаимодействие.Если сервер хочет перезапустить/уменьшить пропускную способность, он информирует всех клиентов, подключенных к этому Access, о том, что сервер необходимо обновить, а клиенту необходимо повторно подключиться к другим узлам.

   • На самом деле это активная стратегия миграции, так что хотя клиент все равно переподключается, это будет лучше, чем если бы мы напрямую отключились.

2. После того как будет определено, что все клиенты на текущем узле доступа подключены к другим узлам, текущий узел доступа перезапустится/перейдет в автономный режим/уменьшится масштаб.

3. Как увеличить мощность?Если мощность необходимо увеличить, после добавления нового узла выполните обнаружение службы и регистрацию через etcd.После того, как клиент запрашивает данные через сервер маршрутизатора, он подтягивает их к соответствующему узлу.

4. Если текущие 3 узла больше не могут удерживать и добавляются еще 2 узла, что нужно сделать, чтобы немедленно уменьшить нагрузку на текущие 3 узла?

   • Согласно предыдущему способу, если клиент переведет к запросу сервера маршрутизатора, а затем подключается, это не может сразу уменьшить давление, поскольку после добавления нового узла текущее давление все еще находится на предыдущих узлах.

   • Следовательно, сервер должен иметь лучший механизм для управления сервером.

     • Сервер отправляет команду клиенту на текущем узле, позволяя клиенту подключиться к новому узлу.

     • Сервер также должен определить, подключены ли некоторые части к другим узлам, а затем иметь соответствующие политики.

как предотвратить атаки

1. Онлайн-машины имеют политики брандмауэра (включая аппаратный брандмауэр/программный брандмауэр)

   • Аппаратный брандмауэр: аппаратное брандмауэр Оборудование, очень дорогое, приобретенное в настоящее время, но меньше

   • Программный брандмауэр: на уровне программного обеспечения, например iptable, установите политику брандмауэра iptable.

2. На уровне канала TCP

   • Частотный контроль скорости соединения сокета не может позволить другим постоянно устанавливать соединения сокета, иначе сокеты легко переполнятся и не выдержат.

     • Текущая настройка - скорость подключения независимого ip превышает 100/с, он считается атакованным, и этот ip забанен

   • Частота отправки и получения сообщений контролируется, чтобы другие не могли постоянно отправлять сообщения, иначе весь сервис зависнет

     • Чтобы иметь возможность отправлять сообщения, вы должны быть авторизованы

     • Для входа необходимо иметь токен, есть ключи

     • Обмен сообщениями может быть предоставлен контроль частоты

Сравнение и выбор протоколов с открытым исходным кодом / универсальных протоколов, представленных в настоящее время на рынке.

1. Почему xmpp не подходит, только из-за большого объема данных xml?

   • В настоящее время также существуют решения по оптимизации обработки для xmpp, поэтому большой трафик не является основным недостатком.

   • Другой момент заключается в том, что сообщение ненадежно, а его механизм запроса и ответа в основном рассчитан на стабильную и долгосрочную сетевую среду подключения, он не особенно оптимизирован для мобильных сетей с узкой полосой пропускания и нестабильными долгосрочными подключениями.

   • Таким образом, XMPP, предназначенный для поддержки многотерминальных состояний, не подходит для мобильных устройств.

2. Почему mqtt не подходит?Почему mqtt не используется в проекте ххх?

   • MQTT подходит для толчка, но не для IM. Это требует дополнительной обработки на уровне бизнеса, и она уже начала повторно использовать.

   • Это историческая проблема, что проект ххх не нуждается в mqtt, потому что он должен быть выполнен быстро в начале, а структура должна быть быстро построена для достижения, поэтому он используется для командного разговора Могуцзе.

   • При последующем выборе и если не осталось проблем из истории, мы выберем использование mqtt

3. В дополнение к большому объему данных также учитывать сложность протокола, сложность обработки протокола клиентом и сервером?

   • Протокол следует считать легким для расширения, для облегчения последующих новых полей и для поддержки нескольких платформ.

   • Подумайте, проста ли реализация клиента и сервера

   • Эффективность кодека

Межмашинное помещение, аварийное восстановление с несколькими машинными помещениями

1. Службы должны иметь возможность охватывать компьютерные залы, особенно узлы с отслеживанием состояния.

2. Необходимо зарезервировать несколько компьютерных залов для аварийного восстановления, чтобы предотвратить зависание всего компьютерного зала.

Только что обсудили, какие функции имеет уровень доступа:

1. Поддержка длинных TCP-соединений, включая обнаружение сердцебиения/тайм-аута

2. Распаковка

3. Механизм защиты от атак

4. Ожидание получения ответа на сообщение (ранее об этом не упоминалось, то есть после того, как сообщение отправлено получателю, получатель должен ответить)

Точки для размышлений (ключевые моменты оценки)

1. Почему сообщения могут быть не по порядку Как убедиться, что сообщения не по порядку?

   • Рассмотрите возможность перехода в офлайн-режим
   • Учитывайте сетевые аномалии

2. Как должен быть разработан метод/структура хранения для сообщений в автономном режиме?

   • Рассмотрите возможность отправки сообщений несколькими людьми
   • Рассмотрим способ кэширования + db

3. Как сделать так, чтобы сообщение не потерялось и не стало тяжелым, как спроектировать механизм предотвращения потери сообщений?

   • Учтите, что одна и та же учетная запись может войти в систему с нескольких терминалов.
   • Учитывая слабую сетевую среду, ACK также может быть потерян

4. Для длинных соединений, как управлять этими длинными соединениями?

   • Рассмотрим быстрый поиск
     • Приходят данные бэкенда, как быстро найти соединение, соответствующее этому запросу?

5. Существует несколько узлов уровня доступа, и они сохраняют состояние.Какой механизм используется для обеспечения того, чтобы соответствующий ответ на запрос, отправленный с узла 1, по-прежнему возвращался узлу 1?

   • Или если ответ возвращается не на узел 1, а на узел 2, какие недостатки?

["Добро пожаловать, обратите внимание на мою общедоступную учетную запись WeChat: разработка серверной системы Linux, и позже я буду активно отправлять высококачественные статьи через общедоступную учетную запись WeChat"]