👉Содержание

1 фон

2 Архитектура отправки и получения сообщений

3 Механизм предотвращения потери сообщений

4 Резюме

В 2023 году число активных пользователей WeChat (ежемесячно) достигнет 1,34 миллиарда. WeChat стал неотъемлемой частью работы и жизни многих людей. С момента запуска WeChat 21 января 2011 года прошло 13 лет, и его техническая основа и архитектура также претерпели огромные изменения. За этими изменениями стоит золотой век быстрого развития Интернета в Китае. Сообщество разработчиков облачных технологий Tencent специально запланировало серию «Технологии десятилетней давности», чтобы вернуть всех к исходной технической архитектуре этих звездных проектов. Хорошая архитектура растет, но хороший дизайн также необходим. Я надеюсь, что все читатели смогут черпать из нее вдохновение и силы.

01.Фон

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

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

WeChat позиционируется как программа для обмена мгновенными сообщениями и предъявляет два основных требования к отправке и получению сообщений:

1. Сообщения доставляются в максимально реальном времени.
2. Ни одно сообщение не потеряется.

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

02. Архитектура отправки и получения сообщений

2.1 Архитектура отправки сообщений

Сначала отправьте сообщение WeChat с мобильного телефона A на мобильный телефон B, чтобы увидеть общую архитектуру отправки сообщений, как показано на рисунке 1:

Общую архитектуру отправки сообщений WeChat можно разделить на 2 части:

1) Мобильный телефон А отправляет сообщение на сервер (части 1, 2 и 3 на рисунке 1).

1: Мобильный телефон А отправляет запрос сообщения на уровень доступа ConnectSvr;

2: После получения запроса уровень доступа пересылает запрос на логический уровень SendSvr для обработки;

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

2) Сервер отправляет уведомление на мобильный телефон B (части 4, 5.1, 5.2, 6 и 7 на рисунке 1).

4: Логический уровень SendSvr отправляет уведомление о прибытии нового сообщения для мобильного телефона B на сервер обработки уведомлений PushSvr;

5.1: PushSvr запрашивает ConnectSvr постоянного соединения мобильного телефона B на уровне доступа и отправляет уведомление ConnectSvr;

5.2: PushSvr отправляет Push-подсказку сторонней системе Push, созданной на основе мобильной операционной системы (например, ApnsPush от Apple, WPPush от Microsoft, BBPush от BlackBerry и т. д.). Как и в системе Apple IOS, все ресурсы, принадлежащие приложению (такие как процессор, сеть, память и т. д.), будут освобождены через 10 минут после выхода приложения в фоновый режим, что приведет к отключению ранее установленного длинного канала соединения. , уведомление через версию 5.1 недоступно, поэтому вам все равно придется полагаться на собственный канал apns Apple для получения уведомлений в реальном времени;

6: Уровень доступа ConnectSvr отправляет уведомление о прибытии нового сообщения на мобильный телефон B через длинный канал соединения, установленный мобильным телефоном B;

7. Сторонний push-сервер отправляет push-подсказки на мобильный телефон B через собственный push-уведомление.

2.2 Архитектура приема сообщений

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

Процесс сбора сообщений в основном делится на три этапа:

1. сотовый телефон B Инициировать запрос сообщения на сервер уровня доступа. ConnnectSvr；
2. Уровень доступа ConnnectSvr После получения запроса перенаправьте его на сервер логического уровня. ReceiveSvr обрабатывать;
3. ReceiveSvr отхранилищеслой MsgStore Получите сообщение, которое необходимо отправить.

2.3 Резюме

Вышеупомянутая архитектура отправки и получения сообщений может гарантировать, что мобильный телефон A получит сообщение в течение 100 мс после отправки сообщения. Конечно, для пользователей Apple IOS, которые выходят из фонового режима, если сервер apns Apple работает нормально, он также может гарантированно уведомить мобильный телефон B в течение нескольких секунд, чтобы открыть приложение и перейти на передний план для получения сообщений.

03. Механизм предотвращения потери сообщений

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

3.1 механизм последовательности

1. Каждый пользователь имеет 4,2 миллиарда пространства последовательностей (от 1 до UINT_MAX), распределяемого непрерывно от малого к большому;
2. Каждому сообщению каждого пользователя необходимо присвоить последовательность;
3. серверные хранилища Каждому пользователю назначается максимальная последовательность;
4. сотовый телефон Endхранилище Получили сообщения изMax sequence。

3.2 Механизм подтверждения последовательности получения сообщения

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

1. По данным серверов мобильный телефон между концами sequence Из различий вы можете легко реализовать инкрементное распределение сотовых данных. Сообщение не было получено на телефонном терминале.
2. Для плохих сетевых условий в слабых сетевых средах,Вероятность потери пакета относительно высока.,В это время часто случается, что обратная посылка не может прийти в Сотовый. телефонэндизфеномен. За счет сотового Телефонный терминал обновит локальную информацию только после получения точного сообщения. последовательность, поэтому даже если обратный пакет потерян, сотовый Телефонный терминал ожидает истечения времени ожидания, а затем перезапускает процесс. sequence При получении сообщений на сервере вы также можете корректно получать неотправленные сообщения.
3. потому чтосотовый телефонконецхранилищеиз sequence максимальное количество полученных подтверждений последовательность, так что для сотового Каждый раз, когда телефонный терминал приходит на сервер для получения сообщения, это также можно рассматривать как подтверждение последнего полученного сообщения. Один аккаунт в нескольких сотовых сторона телефона поворачивается для входа в систему из-за того, что серверные хранилищасотовый завершение телефона подтвержденоиз последовательности, то вы можете просто понять, что сообщение о подтвержденной доставке не будет доставлено повторно, а это другое дело. телефон между концами Заходите по очереди и не получите других сотовых Телефонный терминал получил сообщение.

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

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

Как показано на рисунке 6, если оригинальный мобильный телефон A Пользователь переключается на мобильный телефон B Войдите и используйте Seq_cli = 120 Получите сообщение от сервера, поскольку сервер его подтвердил. sequence <= 150 Сообщение было получено на мобильный телефон и не будет возвращено. sequence для [121 - 150] сообщение на мобильный телефон Б, но будет sequence для [151 - 200] сообщение отправляется на мобильный телефон B。

Хотя здесь sequence для [151 - 200] сообщение могло быть отправлено с мобильного телефона A и мобильный телефон B получены, но из-за мобильного телефона A После получения sequence для [151 - 200] сообщения не отправляются на сервер для подтверждения или эти сообщения A Оно вообще не было получено, поэтому во избежание потери сообщения последовательность для [151 - 200] сообщение также необходимо отправить на мобильный телефон. B из.

04. Резюме

Выше кратко описывается архитектура обмена сообщениями WeChat. Эта архитектура реализует два основных требования к программному обеспечению для обмена сообщениями:

1. Сообщения доставляются в максимально реальном времени.
2. Ни одно сообщение не потеряется.

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

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