Введение: Эта статья является первой из всей серии "Как построить архитектуру онлайн-приложения без потерь трафика". В этой серии три статьи. Цель состоит в том, чтобы максимально простым языком классифицировать технические проблемы, влияющие на стабильность. трафика онлайн-приложений. , некоторые из решений этих проблем представляют собой просто некоторые детали на уровне кода, некоторые требуют сотрудничества инструментов, а некоторые требуют дорогостоящих решений. Если ваше приложение хочет иметь универсальный опыт [без потерь трафика] в облаке вы можете обратить внимание на облачный продукт Alibaba Cloud «Служба корпоративных распределенных приложений (EDAS)», EDAS будет продолжать развиваться в направлении трафика доступа по умолчанию без потерь.
Автор | Гу И, Шимиан
предисловие
Github вызвал глобальное прерывание службы более чем на 6 часов из-за обновления программного обеспечения... Meta (ранее известная как Facebook) только что пережила глобальный системный паралич более чем на 6 часов из-за ошибки отправки конфигурации...
Подобные крупные сбои ИТ-систем случаются время от времени. Создание безопасной и надежной архитектуры онлайн-приложений для предприятия является основной обязанностью системного архитектора.В дополнение к глубокому пониманию архитектуры бизнес-системы для безопасной работы с текущим бизнес-трафиком ему также необходимо иметь возможность строить будущее, которое выбранная архитектура должна быть в состоянии справиться с ростом бизнеса в течение следующих нескольких лет. Эта способность не имеет ничего общего с технологической тенденцией, но связана с емкостью рынка талантов выбранной технологии и связана с формой бизнеса и направлением роста самого предприятия.
Давайте отложим в сторону конкретность инфраструктуры ИТ-систем и корпоративного бизнеса и абстрагируем ее от двух ключевых показателей онлайн-приложений: трафика и емкости. Цель пропускной способности — удовлетворить базовые потребности в трафике, а наша цель непрерывной оптимизации — найти точку баланса, которая может отражать «технологический прогресс» по этим двум показателям. Эта точка баланса означает: эффективно и точно обслуживать существующие ресурсы (мощности) для существующего и предсказуемого бизнес-трафика; высокая эффективность означает производительность, а точность должна быть потеряна.
Эта серия из трех статей направлена на то, чтобы вернуть технологию к основной проблеме, которую необходимо решить системным архитекторам: как максимизировать поток онлайн-приложений без потерь.
определение проблемы
Давайте сначала обратимся к общей диаграмме архитектуры бизнес-развертывания (Примечание. Поскольку техническим опытом автора является Java, а знакомая инфраструктура — это в основном облачные сервисы, во многих из этих примеров используются некоторые технические фреймворки в системе Java для связи с облаком. Сервис объясняется, и некоторые детали могут не иметь значения для других языков программирования.):
Эта картина представляет собой типичную и очень простую бизнес-архитектуру. Этот бизнес будет обслуживать пользователей со всего мира. Когда запрос пользователя поступит, он будет передан в следующий кластер микросервисного шлюза через балансировку нагрузки, и микросервисный шлюз выполнит некоторые основные действия. После очистки трафика, аутентификации, аудита и т. д. они направляются в следующие микросервисные кластеры в соответствии с бизнес-формой, весь микросервисный кластер в конечном итоге будет выполнять операции обмена данными (чтение/запись) с различными службами данных.
Согласно приведенному выше описанию, мы временно разделим весь процесс обслуживания запроса трафика на:Анализ трафика, доступ к трафику, обслуживание трафика, обмен даннымиЧетыре основных этапа. На этих четырех этапах может быть вероятность потери трафика, и решения, которые мы принимаем после каждой возможности, будут совершенно разными, некоторые могут быть решены некоторыми конфигурациями фреймворка, а другие могут потребовать рефакторинга всей архитектуры. Мы проанализируем эти четыре этапа один за другим в трех сериях статей, первая часть в основном посвящена анализу трафика и доступу к нему.
Анализ трафика
Суть сценария разрешения состоит в том, чтобы получить адрес службы через имя службы, этот процесс является разрешением DNS в нашем обычном понимании. Однако под влиянием текущих стратегий управления различных поставщиков услуг традиционное разрешение доменных имен часто сталкивается с проблемами.Кэширование доменных имен, переадресация доменных имен, задержка разрешения, доступ между поставщиками услугИ другие вопросы. Особенно в глобальном интернет-бизнесе, когда веб-сервис разрешается через традиционный DNS, источник конечного пользователя не будет определяться, а один из IP-адресов будет выбираться случайным образом и возвращаться конечному пользователю, что может не только уменьшить эффективность разрешения из-за разрешения между поставщиками услуг, и это также приведет к замедлению работы конечных пользователей из-за межокеанского доступа.
Вышеупомянутые проблемы могут напрямую привести к нашейтрафик скомпрометирован. Чтобы справиться с описанными выше сценариями, обычно используемые решения включают интеллектуальное разрешение и технологию HTTP DNS, которые описаны ниже:
1. Интеллектуальный анализ
Интеллектуальный синтаксический анализ изначально использовался для решения проблемы сбоя сети, вызванного синтаксическим анализом между сетями между различными операторами.Он в основном выбирает точку доступа в соответствующей сети в соответствии с адресом терминала доступа, чтобы достичь цели синтаксического анализа правильный адрес. Благодаря непрерывной итерации и развитию этой технологии в некоторые продукты на этой основе были добавлены узлы мониторинга качества сети в разных регионах, и они могут выполнять более интеллектуальный анализ группы машин в соответствии с качеством обслуживания различных узлов. В настоящее время интеллектуальный анализ в Alibaba Cloud опирается на облачную инфраструктуру и может даже динамически масштабировать узлы в пуле узлов в единицах приложений, максимизируя значение эластичности облака в этой области:
(Изображение взято из документа по анализу облачных вычислений Alibaba Cloud)
2. HTTPDNS
HTTPDNS, как следует из его названия, представляет собой протокол обнаружения, который использует протокол HTTP вместо DNS; как правило, поставщик услуг (или созданный самостоятельно) предоставляет HTTP-сервер, который обеспечивает предельно лаконичный HTTP-интерфейс.Прежде чем клиент инициирует доступ, HTTPDNS SDK сначала инициирует разрешение. , разрешение завершается ошибкой, а затем выполняется возврат к исходному разрешению LocalDNS. HTTPDNS особенно эффективен при решении задач, связанных с перехватом DNS, кэшированием доменных имен и т. д. Недостаток заключается в том, что большинство решений также требуют, чтобы клиент вторгся в SDK, в то же время стоимость создания сервера будет немного высокой. Однако с непрерывным чередованием поставщиков облачных услуг в этой области появляется все больше и больше облегченных решений; это также поможет HTTPDNS стать одной из основных тенденций в развитии области DNS в будущем.
доступ к трафику
Когда DNS разрешает правильный адрес, он входит в ядро доступа к трафику.Главным героем этого процесса является шлюз.Роль, которую играет шлюз, обычно важна.Маршрутизация, аутентификация, аудит, преобразование протоколов, управление API,а такжеБезопасностьи другие важные функции. Обычным CP в отрасли является комбинация балансировки нагрузки и шлюза микросервисов. Однако, когда эти два компонента работают вместе, часто возникают сценарии, которые легко игнорировать. На следующем рисунке приведен пример. Я кратко представлю три сценария, которые их легко игнорировать.Безопасность трафика, управление шлюзовыми приложениями и маршрутизация трафика.
1. Безопасность дорожного движения
Небезопасный трафик делится на две категории: первая — трафик типа атаки, вторая — трафик, превышающий пропускную способность системы. Защита трафика атакующего типа в основном основана на программных и аппаратных брандмауэрах. Этот тип решения является достаточно зрелым и не будет повторяться здесь. Выявить неатакуемый трафик, превышающий пропускную способность системы, сложно, как сделать так, чтобы нормальный трафик мог получить соответствующие сервисы в наибольшей степени в этом сценарии, а также защитить всю бизнес-систему, которая с большой вероятностью может лавинообразно обрушиться, — сложное решение. .
Простая попытка состоит в том, чтобы выполнить управление потоком, аналогичное RateLimit, на шлюзе в соответствии с количеством запросов в секунду, параллелизмом, минутными запросами и даже параметрами интерфейса. Но перед этим системный архитектор должен знать возможности системы. Мы рекомендуем провести общую оценку производительности, прежде чем приступать к аналогичной защите безопасности.Оценка здесь представляет собой не просто стресс-тест для некоторых API, а настоящий полноценный тест для производственной среды.Дорожный стресс-тест (будет проводиться специальный введение в третьей части), а затем внесите целевые корректировки политики безопасности.
2. Управление и контроль приложений шлюза
В конечном счете, шлюз все еще является приложением.По словам клиентских онлайн-систем, с которыми мы сталкивались до сих пор, бизнес-система с полностью микросервисной архитектурой будет занимать 1/6 - 1/3 машинных ресурсов всей системы. Это очень большое приложение. Поскольку это приложение, оно будет выполнять некоторые обычные операции управления и обслуживания, такие как запуск, остановка, развертывание и расширение. Однако, поскольку шлюз является горлом бизнес-системы, он не может выполнять частые операции, а значит, есть несколько принципов, которые необходимо четко донести до команды разработчиков:
- **Развязка конфигурации и кода**. Возможности (переадресация протокола, текущая конфигурация ограничения, политика безопасности, правила маршрутизации и т. д.) должны быть настраиваемыми и предоставляться динамически.
- **Не смешивайте бизнес-логику: **Пусть шлюз вернется к сути шлюза, не смешивайте бизнес-логику, шлюз, который не играет сам по себе, является хорошим шлюзом!
В дополнение к двум вышеупомянутым принципам на стороне разработки существуют также соответствующие принципы на стороне эксплуатации и обслуживания. В дополнение к регулярному мониторингу и оповещению, O&M также должна обладать адаптивной гибкостью. Однако гибкость шлюза включает в себя слишком много моментов: например, его нужно эксплуатировать в сочетании с предыдущей балансировкой нагрузки (например: перед развертыванием приложения соответствующий узел должен быть отключен или понижен в точке балансировки нагрузки, и развертывание приложения должно гарантировать успешный запуск до того, как узел будет подключен к сети. ); в то же время гибкость также должна взаимодействовать с автоматизацией системы управления и контроля приложений для достижения онлайна.Трафик без потерь.
3. Маршрутизация трафика
Следующим шагом после шлюза является маршрутизация приложения к следующему узлу.В сценарии Интернета, где имеется многомашинное помещение с высокой доступностью, для качества обслуживания будет принят принцип ближайшей маршрутизации. То есть, если вход шлюза находится в главном компьютерном зале, следующий прыжок хочет перенаправиться к узлу в том же компьютерном зале. По той же причине следующий прыжок в микросервисном кластере все еще надеется на маршрутизацию к тому же компьютеру. номер. В противном случае, если есть запрос на вызов через компьютерный зал, RT станет очень длинным, и в конечном итоге время ожидания запроса истечет.Потеря потока,Как показано ниже:
Для того, чтобы добиться эффекта вызова в одном и том же компьютерном зале, нам необходимо хорошо разбираться в выбранной структуре обслуживания. Основной принцип заключается в том, что для маршрута следующего перехода сначала необходимо выбрать адрес той же аппаратной. Различные фреймворки и среда развертывания, в которой расположен бизнес, требуют некоторой целенаправленной индивидуальной разработки для достижения приоритетного вызова в одном и том же компьютерном зале в строгом смысле.
Эпилог
Эта статья является первой из всей серии "Как построить архитектуру онлайн-приложения без потерь трафика". В этой серии три статьи. Целью этой серии является использование максимально простого языка для классификации технических проблем, влияющих на стабильность трафика онлайн-приложений. Эти некоторые решения проблемы представляют собой просто некоторые детали на уровне кода, некоторые требуют сотрудничества инструментов, а некоторые требуют дорогостоящих решений. Если ваше приложение хочет иметь [Трафик без потерь] универсальный опыт, вы можете обратить внимание на облачный продукт «Служба корпоративных распределенных приложений (EDAS)» Alibaba Cloud, EDAS также будет продолжать развиваться в направлении трафика доступа по умолчанию без потерь. В следующей статье мы представим различные сухие товары с точки зрения публикации онлайн-приложений и управления услугами, так что следите за обновлениями.
Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.