В этой статье обсуждается техническая архитектура интернет-компаний, включая DNS, балансировку нагрузки, постоянные соединения, шлюзы API, push-уведомления, микросервисы, распределенные транзакции и сопутствующие базовые сервисы. В основном для обучения, я надеюсь, что могу дать вам ссылку.
Общая структура
Вызывающие абоненты, такие как APP, ПК и третьи стороны, получают IP-адрес балансировщика нагрузки через традиционную службу разрешения доменных имен LocalDNS, а APP может реализовывать более гибкие и точные службы разрешения доменных имен в режиме реального времени через HttpDNS.
Уровень унифицированного доступа достигается через балансировщик нагрузки, а уровень унифицированного доступа поддерживает долгосрочные соединения.
В качестве входа микросервисов API-шлюз отвечает за преобразование протоколов, маршрутизацию запросов, аутентификацию и аутентификацию, управление трафиком, кэширование данных и т.д.
Сервисный сервер реализует отправку одноранговой стороны в режиме реального времени через систему PUSH push, такую как обмен мгновенными сообщениями, уведомление и другие функции.
Бизнес-серверы звонят друг другу через проприетарный протокол RPC и вызывают внешние сторонние службы через шлюз NAT.
DNS
традиционный DNS
Система доменных имен DNS (Domain Name System), распределенная сетевая служба каталогов, используется для взаимного преобразования доменных имен и IP-адресов, что может упростить доступ людей в Интернет без необходимости запоминать IP-адрес машины. .
Процесс разрешения DNS выглядит следующим образом:
- Клиент рекурсивно запрашивает LocalDNS (обычно пограничный DNS-сервер, предоставляемый интернет-провайдером), чтобы получить IP-адрес.
- LocalDNS выполняет итеративный запрос для получения IP, то есть постоянно получает адрес сервера доменных имен для запроса.
HttpDNS
Мобильный DNS (HttpDNS) отправляет запрос на разрешение доменного имени на DNS-сервер на основе протокола Http, заменяя традиционный метод отправки запроса на разрешение оператору. проблемы с доступом к сети, вызванные локальным DNS, и решить проблемы с мобильным Интернетом Проблемы, вызванные ненормальным разрешением доменных имен в службе.
Взяв за основу Tencent Cloud HttpDNS, преимущества по сравнению с традиционным LocalDNS:
| Преимущество | Облако Tencent HttpDNS | Оператор LocalDNS |
|---|---|---|
| высокоскоростной | Узлы доступа охватывают 17 ведущих отечественных операторов, Юго-Восточную Азию и Северную Америку, с точным анализом и быстрым доступом. | Исключения межсетевого доступа пользователей и синтаксического анализа |
| Безопасность | Обход оператора Local DNS, отсутствие перехвата, предотвращение загрязнения и перехвата DNS | Результаты разрешения доменных имен перенаправляются на рекламные страницы и вставляются сторонние рекламные объявления. |
| разумный | Точно определяйте исходные запросы и получайте доступ к наиболее точным узлам | Он сам не выполняет рекурсивное разрешение доменного имени, а перенаправляет запрос другим операторам. |
| надежный | Аварийное восстановление кластера из трех площадок с одним IP-адресом, автоматическое отключение второго уровня, услуга обеспечивает более 99% SLA. | Среда работы и обслуживания кэш-сервера неравномерна, и время от времени случаются сбои. |
балансировки нагрузки
Чтобы решить проблемы производительности и отдельные проблемы одной машины, необходимо пройтибалансировки нагрузкиГоризонтальное масштабирование нескольких машин и распределение трафика запросов на разные серверы.
Трафик клиента сначала будет поступать на сервер балансировки нагрузки, а сервер балансировки нагрузки будет распределять трафик между различными серверами приложений с помощью определенного алгоритма планирования.В то же время сервер балансировки нагрузки также будет выполнять периодические проверки работоспособности серверов приложений. При обнаружении неисправного узла он может динамически удалять узлы из кластера серверов приложений, чтобы обеспечить высокую доступность приложения.
Балансировка сетевой нагрузки в основном реализована аппаратно и программно, среди основных решений балансировки нагрузки производители оборудования представлены F5, а программного обеспечения в основном LVS, NGINX и HAProxy.
Технический принцип делится на четырехуровневую балансировку нагрузки L4 и семиуровневую балансировку нагрузки L7.
L4 vs L7
Четырехуровневая балансировка нагрузки L4 работает на транспортном уровне модели OSI, и основная работаВперед. После получения клиентского сообщения ему необходимо понять содержимое протокола транспортного уровня и переслать сообщение на сервер приложений в соответствии с заданным режимом пересылки и алгоритмом планирования. Возьмем TCP в качестве примера: когда приходит начальный SYN-пакет TCP-соединения, планировщик выбирает сервер и пересылает на него пакет. После этого путем проверки IP-адреса и адреса TCP-заголовка пакета гарантируется, что последующие пакеты этого соединения пересылаются на сервер.
Семиуровневая балансировка нагрузки L7 работает на прикладном уровне модели OSI, и основная работаиграет роль. Балансировка нагрузки уровня 7 установит полное соединение с клиентом и проанализирует запрос прикладного уровня, а затем выберет сервер приложений в соответствии с алгоритмом планирования и установит другое соединение с сервером приложений для отправки запроса.
Режим переадресации LVS
LVS (технология балансировки нагрузки IP) работает ниже четвертого уровня L4, а режимы пересылки: режим DR, режим NAT, режим TUNNEL и режим FULL NAT.
ДР режим(прямой маршрут)
Перепишите MAC-адрес сообщения запроса, отправьте запрос на реальный сервер, и реальный сервер вернет ответ непосредственно клиенту. Планировщик и реальный сервер должны иметь сетевую карту, подключенную к одному и тому же физическому сегменту сети, а реальный сервер должен быть настроен с помощью виртуального IP-адреса.
режим NAT(преобразование сетевых адресов)
Планировщик перезаписывает адрес назначения сообщения запроса и отправляет запрос на реальный сервер на бэкенде в соответствии с заданным алгоритмом планирования; когда ответное сообщение реального сервера проходит через планировщик, исходный адрес сообщения перезаписывается. , а затем вернуться к реальному серверу Клиент, завершить весь процесс планирования нагрузки. Требуется, чтобы балансировка нагрузки существовала в сети в виде шлюза.
Туннельный режим
Планировщик пересылает сообщение запроса на реальный сервер через IP-туннель, а реальный сервер возвращает ответ непосредственно клиенту, поэтому планировщик обрабатывает только сообщение запроса. Требуется реальный сервер для поддержки протокола туннелирования и настройки VIP.
ПОЛНЫЙ режим NAT
Основываясь на режиме NAT, выполните преобразование исходного адреса (т. е. SNAT). Преимущество выполнения SNAT заключается в том, что ответный трафик может быть возвращен балансировщику нагрузки через обычную маршрутизацию уровня 3, поэтому балансировщик нагрузки не должен существовать. в сети в виде шлюза бинго. Производительность уступает режиму NAT, реальный сервер потеряет реальный IP адрес клиента.
Алгоритм планирования
голосование
Распределяя внешние запросы последовательно и поочередно на реальные серверы в кластере, он обрабатывает каждый сервер одинаково, вне зависимости от фактического количества подключений и нагрузки на сервер.
взвешенная круговая система
Чем больше вес, тем выше вероятность доступа.В основном используется в случае, когда производительность каждого сервера в бэкенде несбалансирована, чтобы добиться разумного и эффективного использования ресурсов хоста.
наименее подключенный
Планируйте сетевые запросы к серверу с наименьшим количеством установленных ссылок. Если реальные серверы кластерной системы имеют аналогичную системную производительность, алгоритм планирования «наименьшее количество подключений» может лучше сбалансировать нагрузку.
хэш
Выполните операцию по модулю над хеш-значением указанного ключа и количеством серверов, чтобы получить серийный номер требуемого сервера.
Согласованное хеширование
Учитывая, что каждый узел распределенной системы может выйти из строя, а новые узлы, скорее всего, будут добавляться динамически, согласованное хеширование может гарантировать, что при изменении количества узлов в системе перемещение узлов доступа будет сведено к минимуму.
Шлюз API
Шлюз API (API Gateway) — кластер серверов, единственный внешний вход. С точки зрения объектно-ориентированного проектирования он похож на шаблон Facade. Шлюз API инкапсулирует внутреннюю архитектуру системы и предоставляет API доступа REST/HTTP для внешнего мира. У него также есть другие обязанности, не связанные с бизнесом, такие как аутентификация, мониторинг, балансировка нагрузки, кэширование, управление трафиком и т. д.
Управление API
Основная функция API Gateway — управление API. Обеспечение полного управления жизненным циклом API, включая основные функции, такие как создание, обслуживание, выпуск, эксплуатация и автономный режим; предоставление нескольких сред, таких как тестирование, предварительный выпуск и выпуск; управление версиями и откат версий.
Конфигурация API включаетИнтерфейсная конфигурацияиКонфигурация серверной части. Конфигурация внешнего интерфейса относится к конфигурации, связанной с HTTP, такой как метод HTTP, URL-адрес, параметры запроса и т. д. Внутренняя конфигурация относится к соответствующей конфигурации микрослужбы, такой как имя службы, параметры службы и т. д. Таким образом, с помощью конфигурации API завершается преобразование внешнего Http во внутренние микросервисы.
полностью асинхронный
Поскольку шлюз API в основном работает с сетевым вводом-выводом, благодаря неблокирующему вводу-выводу и мультиплексированию ввода-вывода небольшое количество потоков может использоваться для выполнения массивной параллельной обработки, избегая переключения контекста потока и значительно увеличивая пропускную способность системы. Снизить затраты на машину.
Распространенными решениями являются Tomcat/Jetty+NIO+servlet3.1 иNetty+NIO, здесь рекомендуется использовать Netty+NIO, который может обеспечить более высокую пропускную способность. Модель реактивного программирования WebFlux, запущенная Spring 5.0, характеризуется асинхронностью, управляемостью событиями и неблокировкой.Внутренне она основана на Netty+NIO илиServlet 3.1 Non-Blocking IOКонтейнер реализован.
цепная обработка
Цепная обработка обеспечивает основные функции шлюза на основе цепочки фильтров через модель цепочки ответственности, такие как маршрутизация, преобразование протоколов, кэширование, ограничение тока, мониторинг и ведение журнала. Его также можно расширить в соответствии с реальными потребностями бизнеса, но будьте осторожны, чтобы не выполнять трудоемкие операции.
Механизм работы облачного шлюза Spring (на основе Spring WebFlux) примерно таков:
- Шлюз получает запросы клиентов.
- Запрос клиента сопоставляется с информацией о маршрутизации, и только успешное совпадение может быть отправлено соответствующей нижестоящей службе.
- Запрос проходит через цепочку фильтров Filter и выполняет логику предварительной обработки, например изменение информации заголовка запроса.
- Запросы перенаправляются нижестоящим службам, а ответы возвращаются.
- Ответ проходит через цепочку фильтров Filter для выполнения логики постобработки.
- Ответ клиенту.
регулирование запроса
Регулирование запросов — это последняя эффективная линия защиты, предотвращающая перегрузку системы перед лицом неизвестного трафика. Текущее ограничение может быть выполнено для кластеров, бизнес-систем и определенных измерений API.
Конкретную реализацию можно разделить на кластерную версию и автономную версию.Разница в том, что кластерная версия использует внутренний унифицированный кеш, такой как Redis, для хранения данных, но есть определенная потеря производительности;единое видениесохранить во внутренней памяти устройства (рекомендуется).
Часто используемые алгоритмы ограничения тока: счетчики, дырявые ведра,ведро с жетонами(рекомендовать)
Слияние понижения
Сервисный предохранитель
Когда нижестоящая служба внезапно становится недоступной или по какой-либо причине отвечает слишком медленно, чтобы обеспечить доступность своей службы в целом, вышестоящая служба не продолжает вызывать целевую службу, возвращается напрямую и быстро освобождает ресурсы. Возобновите вызов, если целевой сервис улучшится.
Прерыватель цепи предназначен для устранения лавины сервисов, особенно в микросервисной системе, которая обычно решается на уровне фреймворка. Внутренний механизм принимает режим автоматического выключателя, и его внутренняя диаграмма перехода состояний выглядит следующим образом:
понижение уровня обслуживания
Когда нагрузка превышает общую нагрузочную способность системы, чтобы обеспечить доступность основных служб, неосновные службы обычно могут быть понижены, если кэшированный контент возвращается или возвращается напрямую.
Степень детализации деградации службы может быть связана с параметрами API, функциями или даже системными параметрами, но все они должны быть заранее отсортированы и определены на уровне обслуживания.
В реальных сценариях администратор решает, расширять или понижать версию после того, как нагрузка на сервер превысит пороговое значение.
деловая изоляция
Шлюз API унифицирует обработку на некоммерческом уровне, но при наличии логики бизнес-обработки разные предприятия могут влиять друг на друга. Для изоляции бизнес-систем обычно можно использовать изоляцию пула потоков и изоляцию кластера, однако для Java потоки являются относительно тяжелыми ресурсами, поэтому рекомендуется изоляция кластера.
Двутолчковый
Система push-уведомлений предоставляет различные типы push-уведомлений для различных сценариев для удовлетворения персонализированных потребностей пользователей в push-уведомлениях и интегрирует функции push-уведомлений Apple, Huawei, Xiaomi, FCM и других каналов производителей.Решение для доступа к серверу предназначено для облегчения пользователям быстро интегрировать функцию push-уведомлений мобильных терминалов и поддерживать взаимодействие с пользователями, тем самым эффективно улучшая коэффициент удержания пользователей и удобство работы с ними.
Подключение устройства, регистрация и процесс привязки пользователя
процесс отправки сообщения
Во многих бизнес-сценариях пользователи могут не быть в сети или не иметь сети, когда происходит бизнес. Поэтому все сообщения сохраняются в MPS. Когда происходит бизнес, MPS попытается выполнить push-уведомление (продвижение стороннего канала или самостоятельно созданное push-соединение TCP). В самодельном канале он проверит, есть ли у пользовательского терминала TCP-соединение, запросив кеш.Если он существует, он будет отправлен.После того, как клиент получит push-сообщение, он передаст квитанцию серверу, и сервер может обновить статус сообщения. Если отправка не удалась или квитанция потеряна, пользователь повторно примет уведомление о сообщении при следующем установлении соединения, а клиент выполнит логическую дедупликацию.
Микросервисная система
TODO написал еще одну статью для ознакомления, с нетерпением жду ее!
использованная литература
woohoo. виртуальный сервер linux.org/this/green1.htm…
woohoo.info Q.talent/article/mag…
блог woo woo woo.cn на.com/mind wind/afraid/…
woo woo Краткое описание.com/afraid/76 Цао Цао 8 поставил 5 от…