Взаимодействие с клиентом переднего плана

Подсказка

Это фрагмент из электронной книги «Архитектура облачных нативных приложений .NET для Azure», доступен на .NET Docs или как бесплатный загружаемый PDF-файл, который можно прочитать в автономном режиме.

Скачать в формате PDF

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

Какие есть варианты?

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

Рис. 4-2. Прямая связь клиента со службой

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

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

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

Вместо этого широко принятый шаблон облачной разработки заключается в реализации службы шлюза API между интерфейсными приложениями и внутренними службами. Шаблон показан на рисунке 4-3.

Рис. 4-3. Шаблон шлюза API

На предыдущем рисунке обратите внимание, что служба шлюза API абстрагирует внутренние микрослужбы. Реализован как веб-API, он выступает в качестве обратного прокси-сервера, маршрутизации входящего трафика во внутренние микрослужбы.

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

Необходимо обеспечить простой и быстрый доступ к шлюзу API. Как правило, бизнес-логика хранится вне шлюза. Сложный шлюз рискует стать узким местом и в конечном итоге монолитом. Крупные системы часто предоставляют несколько шлюзов API, сегментированных по типам клиента (мобильным, веб-приложениям, рабочим столам) или внутренним функциям. Backend for Frontends шаблон определяет подход к реализации нескольких шлюзов. Шаблон показан на рис. 4-4.

Рис. 4-4. Серверная часть для шаблона внешнего интерфейса

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

Простые шлюзы

Для начала можно создать собственную службу шлюза API. Быстрый поиск GitHub предоставляет множество примеров.

Для простых облачных приложений .NET можно рассмотреть шлюз Ocelot. Созданный для микрослужб .NET, с открытым исходным кодом, он легковесный, быстрый и масштабируемый. Как и любой шлюз API, его основная функциональность заключается в пересылке входящих HTTP-запросов в подчиненные службы. Кроме того, он поддерживает широкий спектр возможностей, которые можно настроить в конвейере ПО промежуточного слоя .NET.

YARP (еще один обратный прокси-сервер) — это другой обратный прокси-сервер с открытым исходным кодом, возглавляемый группой разработчиков продуктов Майкрософт. Доступный для загрузки как пакет NuGet, YARP подключается к платформе ASP.NET в качестве промежуточного слоя и обладает высокой степенью настройки. Вы найдете YARP хорошо задокументированный с различными примерами использования.

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

Шлюз приложений Azure

Для простых требований к шлюзу можно рассмотреть шлюз приложений Azure. Она доступна в качестве службы PaaS Azure, включает основные функции шлюза, такие как маршрутизация URL-адресов, завершение SSL и брандмауэр веб-приложения. Служба поддерживает возможности балансировки нагрузки уровня 7 . На седьмом уровне можно направлять запросы на основе фактического содержимого HTTP-сообщения, а не только низкоуровневых сетевых пакетов TCP.

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

Контроллер входящего трафика шлюза приложений позволяет шлюзу приложений Azure работать непосредственно со службой Azure Kubernetes. На рисунке 4.5 показана архитектура.

Рис. 4-5. Контроллер входящего трафика Шлюза приложений

Kubernetes включает встроенную функцию, которая поддерживает балансировку нагрузки HTTP (уровень 7) под названием Ingress. Ingress определяет набор правил для того, как экземпляры микрослужб внутри AKS могут быть открыты внешнему миру. На предыдущем изображении контроллер входящего трафика интерпретирует правила входящего трафика, настроенные для кластера, и автоматически настраивает шлюз приложений Azure. На основе этих правил шлюз приложений направляет трафик к микрослужбам, работающим внутри AKS. Контроллер входящего трафика прослушивает изменения правил входящего трафика и вносит соответствующие изменения в шлюз приложений Azure.

Управление API Azure

Для умеренных и крупномасштабных облачных систем можно рассмотреть управление API Azure. Это облачная служба, которая не только удовлетворяет ваши потребности, связанные с API-шлюзом, но и предлагает полнофункциональный опыт для разработчиков и администраторов. Управление API отображается на рисунке 4-6.

Рис. 4-6. Управление API Azure

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

Для разработчиков управление API предлагает портал разработчика, предоставляющий доступ к службам, документации и примеру кода для их вызова. Разработчики могут использовать Swagger/Open API для проверки конечных точек службы и анализа их использования. Служба работает на основных платформах разработки: .NET, Java, Golang и т. д.

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

Ниже приведены примеры того, как политики могут повлиять на поведение облачных служб:

• Ограничение доступа к службе.
• Обеспечение аутентификации.
• При необходимости ограничивайте вызовы из одного источника.
• Включите кэширование.
• Блокировать вызовы с определенных IP-адресов.
• Регулирование работы службы.
• Преобразуйте запросы из SOAP в REST или между различными форматами данных, например из XML в JSON.

Управление API Azure может предоставлять внутренние службы, размещенные в любом месте в облаке или центре обработки данных. Для устаревших служб, которые вы можете предоставлять в облачно-нативных системах, она поддерживает интерфейсы REST и SOAP API. Даже другие службы Azure могут предоставляться с помощью управления API. Вы можете поместить управляемый API на серверную службу Azure, например служебную шину Azure или Azure Logic Apps. Управление API Azure не включает встроенную поддержку балансировки нагрузки и должно использоваться вместе со службой балансировки нагрузки.

Управление API Azure доступно на четырех разных уровнях:

• разработчик.
• Базовый
• Стандарт
• Премия

Уровень разработчика предназначен для непроизводственных рабочих нагрузок и оценки. Другие уровни предлагают постепенно больше мощности, функций и более высоких соглашений об уровне обслуживания (SLA). Уровень "Премиум" обеспечивает поддержку виртуальной сети Azure и нескольких регионов. Все уровни имеют фиксированную цену в час.

Облако Azure также предлагает бессерверный уровень для управления API Azure. Называется ценовой категорией потребления, служба является вариантом управления API, разработанным вокруг бессерверной вычислительной модели. В отличие от ранее показанных «предварительно выделенных» ценовых категорий, уровень потребления обеспечивает мгновенное предоставление и оплату за каждое действие.

Он включает функции шлюза API для следующих вариантов использования:

• Микрослужбы, реализованные с помощью бессерверных технологий, таких как Функции Azure и Azure Logic Apps.
• Ресурсы службы резервной копии Azure, такие как очереди и разделы служебной шины, хранилище Azure и другие.
• Микрослужбы, где трафик имеет случайные большие пики, но остается низким в большинстве случаев.

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

• Нет инфраструктуры для управления.
• Нет неиспользуемой мощности.
• Высокий уровень доступности.
• Автоматическое масштабирование.
• Затраты основаны на фактическом использовании.

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

связь в режиме реального времени;

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

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

Служба Azure SignalR — это полностью управляемая служба Azure, которая упрощает обмен данными в режиме реального времени для облачных приложений. Технические детали реализации, такие как выделение ресурсов, масштабирование и постоянные подключения, скрываются. Услуги обрабатываются для вас с соглашением об уровне обслуживания 99.9%. Вы сосредоточены на функциях приложений, а не на техническом обеспечении инфраструктуры.

После включения облачная служба HTTP может отправлять обновления содержимого непосредственно подключенным клиентам, включая браузер, мобильные и классические приложения. Клиенты обновляются без необходимости опроса сервера. Azure SignalR абстрагирует технологии транспорта, которые создают подключение в режиме реального времени, включая WebSockets, Server-Side события и длинный опрос. Разработчики сосредоточены на отправке сообщений всем или определенным подмножествам подключенных клиентов.

На рисунке 4-7 показан набор HTTP-клиентов, подключающихся к облачному приложению с включенным Azure SignalR.

Рис. 4-7. Azure SignalR

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

Служба Azure SignalR тесно интегрируется с другими службами Azure, такими как База данных SQL Azure, служебная шина или кэш Redis, открывая множество возможностей для облачных приложений.

НазадДалее