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

задняя часть Архитектура сервер Nginx
Практика оптимизации архитектуры системы обмена мгновенными сообщениями с высокой степенью параллелизма
В эпоху Интернет+ объем сообщений резко возрос, а формы сообщений стали более разнообразными, что поставило перед облачной службой обмена мгновенными сообщениями большие проблемы. Какая архитектура и функции лежат в основе высококонкурентной системы обмена мгновенными сообщениями?

Вышеупомянутый контент организован по внутренним материалам, которыми поделился главный архитектор NetEase Yunxin.

Связанная рекомендация по чтению

Подробное объяснение гарантии отправки мгновенных сообщений и оптимизации сети (1): как добиться поддержки активности в фоновом режиме, не влияющей на взаимодействие с пользователем.

Гарантия отправки мгновенных сообщений и оптимизация сети Подробное объяснение (2): Как выполнить длительное соединение и комбинированное решение для отправки сообщений

IM мгновенные сообщения обмена сообщениями GANG и оптимизация сети подробное объяснение (3): как оптимизировать большую передачу данных в слабой сетевой среде

Ключевые моменты этой статьи:

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

NetEaseIMАнализ диаграммы многоуровневой архитектуры облака

  1. низкоуровневый клиентSDK, охватывающий несколько платформ, таких как Android, iOS, ПК с Windows, веб-страницы и встроенные устройства. Сетевые протоколы, используемые на уровне SDK, включают 4-уровневый TCP-протокол и 7-уровневый протокол Socket.IO на основе 7. Последний специально используется для обеспечения возможности длительного соединения в Web SDK, в дополнение к SDK, интегрированному в приложение Приложение, оно также предоставляет API-интерфейс, вызываемый сторонним сервером, основанный на протоколе Http; окончательный A/V SDK представляет собой звуковой и видео SDK в реальном времени на основе протокола UDP, который используется для реализации сети. на основе голосовых и видеозвонков.


  2. Уровень шлюза: обеспечивает прямой доступ к клиенту и поддерживает длительное соединение с сервером; WebSDK напрямую подключается к службе Weblink, которая представляет собой службу длинных соединений на основе протокола Socket.IO и используется для AOS/IOS/ ПК и т. д. Клиентский SDK напрямую подключен к сервису Link на основе протокола TCP, очень важной функцией в сервисах Link и WebLink является управление всеми клиентскими долгосрочными подключениями, а шлюз на основе протокола HTTP имеет службы API и службы LBS и т. д., в которых служба LBS используется для помощи клиентскому SDK в выборе наиболее подходящей точки доступа к шлюзу и оптимизации эффективности сети, а служба API напрямую предоставляет бизнес-запросы от сторонних серверов;
  3. Уровень высокой доступности: над уровнем доступа к шлюзу находится уровень высокой доступности.Уровень доступа к шлюзу может обеспечивать прямое подключение к клиентам.Существует уровень высокой доступности между канальным уровнем и сервисным уровнем для разъединения и обеспечения высокой доступности и простоты расширения.Особенности:В специфическая реализация HA, для Link и WebLink, двух служб, которые поддерживают долгосрочные клиентские соединения, Yunxin предоставляет службы маршрутизации протокола для распределения бизнес-запросов от их имени. Уровень маршрутизации будет следовать заранее определенным правилам. Запрос от клиента перенаправляется на соответствующий бизнес-узел. Когда бизнес-кластер расширяется, служба маршрутизации может немедленно найти новые доступные узлы и перенаправить запрос. Когда бизнес-узел окажется ненормальным, он будет помечен уровнем маршрутизации и изолирован в автономном режиме для подготовки к замене .
  4. Cluster Business Node: на уровне HA - это определенный кластер бизнес-узлов, который мы называем службой приложений. Эта услуга обрабатывает определенные клиентские запросы, и бэкэнд напрямую подключается к различным основным услугам, таким как БД и кэш. Характеристики узлов в этом Кластер он легкий, и каждый узел не является восполнением. Юньсин будет развернуться от сетевых сред, когда фактически развертываете этот кластер, такой как развертывание набора узлов бизнес-сервисов в двух компьютерных комнатах в том же городе, и передний конец распределяет бизнес-запросы через Услуги маршрутизации., В обычные времена службы являются горячими резервными копиями друг для друга, а интернет-трафик одинаково совместно используется; когда одна сетевая среда или инфраструктура не удается, она будет обнаружена с помощью службы маршрутизации, а также вычислительные узлы в этом Окружающая среда будет отмечена в автономном режиме, а онлайн все запросы трафика на сервере направлены в нормальный рабочий кластер; тем самым улучшая общую доступность сервиса; с использованием инструментов эксплуатации и обслуживания, таких как платформы мониторинга, емкость и емкость обработки в реальном времени Использование бизнес-узлов будет динамически контролироваться. Когда настроен уровень воды, сигнал тревоги будет спущена немедленно, а персонал эксплуатации и обслуживания может легко расширить кластер бизнес-узла через платформу автоматической развертывания.
  5. Бизнес-слой: он содержит некоторые ключевые функции: основные единичные сообщения чата, Сообщения группы и чат, уведомления и т. Д.; А также хостинг информации о пользователе, специальные отношения, и т. Д.; И API-ориентированные услуги, такие как SMS, обратный вызов и частные заседания линии и т. Д.; и связанные с ними возможности, такие как аудио и видео и видео и видео в реальном времени.

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

NetEaseIMТопология облачного развертывания

С помощью следующей упрощенной схемы топологии развертывания вы можете получить предварительное представление об общей технической системе Yunxin. Крайний справа — клиент.Клиент получает список точек доступа шлюза через службу LBS, а затем устанавливает длительное соединение с сервером долгосрочных соединений, таким как Link и WebLink, и выполняет операции RPC.Все запросы от клиент будет перенаправлен на маршрутизатор через уровень маршрутизации.Уровень приложения серверной части, уровень приложения обрабатывает и доставляет результаты обработки синхронного запроса в режиме реального времени и отправляет некоторые асинхронные задачи асинхронным задачам через службу очереди, такие как отправка больших групп сообщений, служба push, хранилище и служба синхронизации сторонних копий данных и т. д., это похоже на нижний интерфейс API, API напрямую предоставляет запрос на вызов стороннего сервера, а серверная часть API представляет собой множество независимых сервисов, таких как обратные вызовы, SMS и т. д.; те же внутренние бизнес-запросы All API также будут генерировать соответствующие журналы; как и журналы в приложении, эти журналы будут собираться в платформа больших данных через платформу сбора журналов.С одной стороны, такие данные будут храниться в HDFS для использования в качестве источника данных для статистического анализа данных, с другой стороны, они будут импортированы в хранилища данных, такие как Hbase, для предоставления журнала поиск и вторичный анализ.


Высокий параллелизмIMПрактика оптимизации уровня системных соединений

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


Как обеспечить стабильность?

NetEase Yunxin SDK использует механизм длительного соединения для достижения и использует метод сердцебиения для обнаружения отключения и автоматического повторного подключения.В то же время, Yunxin SDK имеет много работы по оптимизации для слабых сетевых сред, таких как мобильные сети. клиент и сервер, а также использовать протокол socketIO с веб-сайтом для достижения длительного соединения и решения проблемы совместимости браузера;

Как добиться безопасности?

Yunxin требует, чтобы все данные, передаваемые в общедоступной сети, были зашифрованы, в процессе установления соединения между SDK и сервером происходит сложный процесс согласования ключа.Во-первых, клиенту необходимо сгенерировать одноразовый ключ шифрования и использовать энергонезависимый ключ шифрования. Симметричное шифрование шифрует ключ и передает его на сервер. Зашифрованные данные будут расшифрованы сервером. После этого ключ шифрования будет храниться в информации сеанса длинного соединения. Шифрование может эффективно предотвращать такие атаки, как атаки «человек посередине» и воспроизведение пакетов.

Как гарантировать быстро?

Во-первых, при выборе точек доступа к шлюзу служба LBS может помочь клиентам найти наиболее подходящую точку доступа к шлюзу, например ближайший узел физического расстояния, определенный по IP-адресу и другой информации, а во-вторых, после установления соединения длительное соединение механизм может значительно повысить скорость восходящей и нисходящей линии связи, а в процессе передачи данных Yunxin будет сжимать передачу пакетов данных, уменьшать накладные расходы сети, чтобы увеличить скорость отправки и получения сообщений; в сценарии на стороне клиента SDK предоставляет такие механизмы, как автоматический вход в систему и переподключение, то есть канал сообщений устанавливается заранее при открытии UI-интерфейса, в стратегии выбора шлюза доступа скорость установления соединения повышается за счет параллелизма.

Процесс установления длительного соединения между клиентом и сервером

Первым шагом в доступе к SDK является запрос службы LBS на получение списка доступных адресов шлюзов доступа. Служба LBS назначит адреса клиентам в соответствии с различными условиями политики. Общие условия следующие:

  1. appkey, через appkey конкретный запрос приложения может быть направлен на определенный набор точек доступа, которые могут использоваться для выделенных серверных решений;
  2. IP-адрес клиента используется для назначения шлюза доступа ближайшему клиенту в соответствии с географическим положением клиента, что обычно используется в конфигурации зарубежных узлов;
  3. Номер версии SDK указывает клиентам определенного диапазона версий на определенный шлюз.Он часто используется для решений совместимости между новой и старой версиями, и в настоящее время нет фактического варианта использования;
  4. Конкретный идентификатор среды, такой как интеллектуальная среда обслуживания клиентов, используется для указания определенного типа приложения на определенный шлюз для более высокой степени детализации требований к изоляции среды.

После запроса от LBS-сервиса на адрес шлюза доступа клиент будет пытаться установить соединение последовательно по адресам в списке, при строгом соблюдении этой последовательности процесс установления соединения клиентом будет медленным. процесс доступа. На самом деле, во время работы SDK будет использовать список адресов, возвращенный последним запросом LBS в локальном кеше, для установления соединения, а также получить новый список адресов из LBS и кэшировать его локально для следующего использования. ;, когда все адреса в списке Если это не удается после одной попытки, для установления соединения будет использоваться адрес ссылки по умолчанию, если адрес по умолчанию не работает, будет код сетевой ошибки, такой как 415 или 408;

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

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

Принципиальная основа узла ускорения заключается в том, что линия, предоставляемая оператором отдельному пользователю, будь то мобильная сеть или проводная сеть, всегда отличается по качеству от сети между центрами МЦД; если критический путь в вся пользовательская ссылка заменяется на Сетевая линия между IDC полезна для повышения стабильности и скорости соединения.

Предположим, что клиент в Соединенных Штатах получает доступ к точке доступа шлюза в Ханчжоу через сеть мобильной связи.Поскольку сеть, в которой находится клиент, является мобильной сетью, ссылка для прямого подключения к серверу Ханчжоу очень длинная, а промежуточные узлы то, что можно перепрыгнуть, нельзя Ожидается, что в Китае необходимо пересечь Великий брандмауэр, поэтому в большинстве случаев прямого подключения может быть невозможно подключиться или часто отключается после подключения.

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


Поговорим о влиянии разных режимов доставки на эффективность доставки сообщений:

Вопрос 1: Как удвоить возможности параллелизма доставки сообщений?


На этом рисунке верхняя часть представляет сервер связи «точка-точка».Когда отправитель А отправляет сообщение, он отправляет сообщение в приложение для обработки через ссылку, и приложение запрашивает сервер связи, где находится получатель сообщения Б. Это Link y, поэтому на сервер Link y отправляется пакет уведомления по нисходящему каналу, а длинное соединение, соответствующее пользователю B, находится на Link y, и уведомление отправляется клиенту; в этом режиме все точки доступа Link It равен пользователю, он может получить доступ к любому серверу, любая отправка сообщения должна запрашивать сервер связи, где находится целевой получатель на бизнес-уровне, и отправлять пакет уведомления на соответствующий сервер связи, если это групповая проблема, то необходимо запросить список ссылок всех участников группы в бизнес-приложении; это относительно трудоемкая операция; и по мере того, как количество участников, получающих сообщения, продолжает увеличиваться, накладные расходы продолжают увеличиваться. ; Поэтому, если вы необходимо отправлять сообщения в чат, потому что количество участников в чате очень велико, этот режим скоро столкнется с узкими местами в производительности, и задержка доставки сообщений будет очень серьезной;

Для широковещательного сервера ссылок Yunxin сначала следует принципу при распределении точек доступа, то есть участники в одной и той же комнате чата должны быть отнесены к одной и той же группе точек доступа при распределении комнат чата; длинный набор соединений всех участников в комнате ; и отношение сопоставления между конкретным пользователем и Ссылкой больше не поддерживается в Приложении, но сохраняется набор Ссылок, назначенных определенной комнатой; затем любой участник отправляет чат-комнату После трансляции сообщения сообщение загружается в Приложение через ссылку. Приложению нужно только найти список адресов ссылок, которые были выделены в чате, и отправить широковещательное сообщение каждой ссылке. После того, как ссылка получит широковещательное сообщение нисходящей линии связи, оно будет транслироваться и распространяться локально; Эта эффективность более чем на порядок выше, чем в режиме on-demand;

Вопрос 2: Как устранить узкое место производительности одного узла?

После разговора о разнице между точка-точка и широковещательные ссылки, Yunxin вернётся к эволюции и процессу оптимизации другого типа прокси-решения для веб-ссылок на основе socket.io в Yunxin;

Перед этим мы должны подчеркнуть два ключевых момента в WebLink. Во-первых, WebLink основан на протоколе Socket.io. Чтобы обеспечить надежность канала данных, Yunxin необходимо использовать Https для шифрования канала. Во-вторых, потому что это является HTTPS-запросом, он должен предоставлять независимое доменное имя.


Самое раннее решение показано на рисунке 1. Серверная веб-ссылка обеспечивает соединения и реализует шифрование SSL. Несколько узлов используют LVS в качестве прокси-сервера впереди, доменное имя привязано к прокси-серверу LVS, а решение Keepalived реализовано на прокси-сервере LVS для обеспечить высокую доступность. ; Это решение предоставляет внешнему миру только одно доменное имя, но на самом деле внутри много узлов, и расширение прозрачно для внешнего мира; веб-клиенту нужно только напрямую подключиться к этому уникальному доменному имени при подключении. Для одиночного продукта этот способ наиболее эффективен.Простой и быстрый,клиент может обойти процесс выделения адресов,минусы также сосредоточены в одном выходе.Если этот единственный выход будет атакован DDOS,его можно только избежать путем смены доменного имени.Некоторые затраты на эксплуатацию и обслуживание, а во-вторых, для таких сервисов, как Yunxin, единый выход теряет гибкость, все клиенты напрямую подключены к одному и тому же входу, и невозможно добиться эксклюзивных услуг и изоляции бизнеса, и невозможно добиться ускоренных узловых решений;

Следовательно, существует второе решение. В этом решении для справки используется метод распределения LBS в службе Link. Шифрование SSL реализовано на узле Weblink, и для каждого узла Weblink выделяется независимое доменное имя. Служба LBS выделяется узлу Weblink. подходящая точка доступа; преимущество этого решения в том, что оно обеспечивает большую гибкость, кластер можно расширить в любое время, адрес точки доступа конкретного приложения также можно динамически корректировать, а также дает возможность быть узлом ускорения ; Однако проблема с этим решением заключается в том, что каждый узел представляет собой отдельную точку, и в узле по-прежнему требуется кодирование SSL. Поскольку SSL в Java имеет относительно большие накладные расходы на ресурсы ЦП, резкий пользовательский трафик повлияет на возможности обслуживания одного узла. узел;

Итак, есть третье решение: это решение использует Nginx в качестве семиуровневого прокси-сервера на внешнем интерфейсе и настраивает SSL и привязку доменного имени в Nginx, а серверная часть может одновременно использовать группу веб-ссылок; использование Nginx, логика распределения портов Это также более научно и повышает удобство эксплуатации и обслуживания. Наконец, Yunxin получил комбинированное решение, используемое в настоящее время. Интерфейс по-прежнему использует службу LBS для выделения точек доступа к SDK для обеспечения гибкости; серверная часть использует несколько Кластер Nginx действует как прокси-кластер, а производительность каждой группы кластеров была улучшена.

Сервисно-ориентированная и высокодоступная практика платформы обмена мгновенными сообщениями

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


Уровень доступа к шлюзу отвечает за обслуживание и управление долгосрочным соединением клиента.Все узлы доступа могут даже быть одноранговыми узлами без сохранения состояния, которые отвечают только за пересылку запросов между клиентом и сервером и оптимизируют эффективность пересылки. ; Логика бизнес-обработки все еще должна быть реализована бизнес-уровнем.

Бизнес-уровень должен обрабатывать большое количество запросов и отвечает за взаимодействие с такими компонентами, как БД, кеш, очередь и сторонние интерфейсы.Его стабильность, доступность и масштабируемость напрямую влияют на качество всего облачного сервиса; в Чтобы сделать бизнес-уровень более гибким, Yunxin вводит уровень маршрутизации между уровнем доступа к шлюзу и бизнес-уровнем, чтобы разделить; бизнес-узел регистрируется в сервисном центре после подключения к сети, а узел маршрутизации передает пакет запроса уровень шлюза и отправлять его с сервисного узла.Выбирать соответствующие узлы для распределения запросов; эта трехуровневая архитектура делает систему в целом более устойчивой.

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

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

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