Взаимодействие с внешними клиентами
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
В облачной системе интерфейсные клиенты (мобильные, веб-приложения и классические приложения) требуют взаимодействия с независимыми микрослужбами серверной части.
Какие варианты существуют?
Чтобы обеспечить простоту, интерфейсный клиент может напрямую взаимодействовать с внутренними микрослужбами, показанным на рис. 4-2.
Рис. 4-2. Обмен данными между клиентами и службами
При таком подходе каждая микрослужба имеет общедоступную конечную точку, доступную внешним клиентам. В рабочей среде подсистема балансировки нагрузки будет размещаться перед микрослужбами, маршрутизация трафика пропорционально.
Хотя просто реализовать, прямой обмен данными с клиентом будет приемлемым только для простых приложений микрослужб. Этот шаблон тесно связывает интерфейсных клиентов с основными внутренними службами, открыв дверь для многих проблем, включая:
- Чувствительность клиента к рефакторингу серверной службы.
- Более широкая область атаки, так как основные серверные службы предоставляются напрямую.
- Дублирование перекрестных проблем в каждой микрослужбе.
- Слишком сложный код клиента — клиенты должны отслеживать несколько конечных точек и обрабатывать сбои в устойчивом режиме.
Вместо этого широко принятый шаблон облачной разработки заключается в реализации службы шлюза API между интерфейсными приложениями и внутренними службами. Шаблон показан на рисунке 4-3.
Рис. 4-3. Шаблон шлюза API
На предыдущем рисунке обратите внимание, что служба шлюза API абстрагирует внутренние микрослужбы. Реализован как веб-API, он выступает в качестве обратного прокси-сервера, маршрутизации входящего трафика во внутренние микрослужбы.
Шлюз изолирует клиента от секционирования и рефакторинга внутренней службы. Если вы изменяете серверную службу, ее следует разместить в шлюзе без нарушения клиента. Это также ваша первая линия защиты для перекрестных проблем, таких как идентификация, кэширование, устойчивость, измерение и регулирование. Многие из этих перекрестных проблем могут быть отключены от внутренних основных служб к шлюзу, упрощая внутренние службы.
Необходимо обеспечить простой и быстрый доступ к шлюзу API. Как правило, бизнес-логика хранится вне шлюза. Сложный шлюз рискует стать узким местом и в конечном итоге монолитом. Крупные системы часто предоставляют несколько шлюзов API, сегментированных по типам клиента (мобильным, веб-приложениям, рабочим столам) или внутренним функциям. Шаблон серверной части для интерфейсов обеспечивает направление реализации нескольких шлюзов. Шаблон показан на рис. 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. С помощью уровня 7 можно направлять запросы на основе фактического содержимого HTTP-сообщения, а не только с низкоуровневыми сетевыми пакетами TCP.
В этой книге мы евангельизируем размещение облачных систем в Kubernetes. Оркестратор контейнеров Kubernetes автоматизирует развертывание, масштабирование и операционные проблемы контейнерных рабочих нагрузок. Шлюз приложений Azure можно настроить в качестве шлюза API для кластера Служба Azure Kubernetes.
Контроллер входящего трафика Шлюз приложений позволяет Шлюз приложений Azure работать непосредственно с Служба Azure Kubernetes. На рисунке 4.5 показана архитектура.
Рис. 4-5. Контроллер входящего трафика Шлюза приложений
Kubernetes включает встроенную функцию, которая поддерживает балансировку нагрузки HTTP (уровень 7) под названием 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-интерфейсы и управляют их поведением. Доступ к службе можно предоставить, отслеживать работоспособность службы и собирать данные телеметрии служб. Администратор istrator применяют политики к каждой конечной точке, чтобы повлиять на поведение. Политики — это предварительно созданные инструкции, которые выполняются последовательно для каждого вызова службы. Политики настраиваются для входящего вызова, исходящего вызова или вызова при ошибке. Политики можно применять в разных область службы, чтобы обеспечить детерминированное упорядочение при объединении политик. Продукт поставляется с большим количеством предварительно созданных политик.
Ниже приведены примеры того, как политики могут повлиять на поведение облачных служб:
- Ограничение доступа к службе.
- Принудительное применение проверки подлинности.
- При необходимости регулирование вызовов из одного источника.
- Включите кэширование.
- Блокировать вызовы с определенных IP-адресов.
- Управление потоком службы.
- Преобразуйте запросы из SOAP в REST или между различными форматами данных, например из XML в JSON.
Azure Управление API может предоставлять внутренние службы, размещенные в любом месте в облаке или центре обработки данных. Для устаревших служб, которые могут предоставляться в облачных системах, она поддерживает интерфейсы REST и SOAP API. Даже другие службы Azure можно предоставлять через Управление API. Вы можете разместить управляемый API на стороне службы резервного копирования Azure, например Служебная шина Azure или Azure Logic Apps. Azure Управление API не включает встроенную поддержку балансировки нагрузки и должна использоваться вместе со службой балансировки нагрузки.
Azure Управление API доступна на четырех разных уровнях:
- разработчик.
- Basic
- Standard
- Premium
Уровень разработчика предназначен для непроизводственных рабочих нагрузок и оценки. Другие уровни предлагают постепенно больше мощности, функций и более высоких соглашений об уровне обслуживания (SLA). Уровень "Премиум" обеспечивает поддержку azure виртуальная сеть и нескольких регионов. Все уровни имеют фиксированную цену в час.
Облако Azure также предлагает бессерверный уровень для Azure Управление API. Называется ценовой категорией потребления, служба является вариантом Управление API разработанную вокруг бессерверной вычислительной модели. В отличие от предварительно выделенных ценовых категорий, уровень потребления обеспечивает быструю подготовку и оплату за действия.
Он включает функции шлюза API для следующих вариантов использования:
- Микрослужбы, реализованные с помощью бессерверных технологий, таких как Функции Azure и Azure Logic Apps.
- Ресурсы службы резервного копирования Azure, такие как служебная шина очереди и разделы, хранилище Azure и другие.
- Микрослужбы, где трафик имеет случайные большие пики, но остается низким в большинстве случаев.
Уровень потребления использует те же базовые Управление API компоненты службы, но использует совершенно другую архитектуру на основе динамически выделенных ресурсов. Он идеально соответствует модели бессерверных вычислений:
- Отсутствует инфраструктура для управления.
- Нет простой емкости.
- Высокий уровень доступности.
- Автоматическое масштабирование.
- Затраты основаны на фактическом использовании.
Новый уровень потребления является отличным выбором для облачных систем, которые предоставляют бессерверные ресурсы в качестве API.
связь в режиме реального времени;
Обмен данными в режиме реального времени или отправки — это еще один вариант для интерфейсных приложений, взаимодействующих с внутренними облачными системами по протоколу HTTP. Приложения, такие как финансовые тикеры, онлайн-образование, игры и обновления хода выполнения заданий, требуют мгновенных ответов в режиме реального времени от серверной части. При обычном обмене данными ПО HTTP клиент не может знать, когда доступны новые данные. Клиент должен постоянно опрашивать или отправлять запросы на сервер. При обмене данными в режиме реального времени сервер может отправлять новые данные клиенту в любое время.
Системы реального времени часто характеризуются потоками данных с высокой частотой и большим количеством одновременных подключений клиентов. Реализация подключения в режиме реального времени может быстро стать сложной, требуя нетривиальной инфраструктуры для обеспечения масштабируемости и надежного обмена сообщениями с подключенными клиентами. Вы можете самостоятельно управлять экземпляром кэша Redis Azure и набором подсистем балансировки нагрузки, настроенных с использованием липких сеансов для сопоставления клиентов.
Служба Azure SignalR — это полностью управляемая служба Azure, которая упрощает обмен данными в режиме реального времени для облачных приложений. Технические сведения о реализации, такие как подготовка емкости, масштабирование и постоянные подключения, абстрагируются. Они обрабатываются для вас с соглашением об уровне обслуживания 99,9 %. Вы сосредоточены на функциях приложений, а не на сантехнике инфраструктуры.
После включения облачная служба HTTP может отправлять обновления содержимого непосредственно подключенным клиентам, включая браузер, мобильные и классические приложения. Клиенты обновляются без необходимости опроса сервера. Azure SignalR абстрагирует технологии транспорта, которые создают подключение в режиме реального времени, включая WebSockets, события на стороне сервера и длинный опрос. Разработчики сосредоточены на отправке сообщений всем или определенным подмножествам подключенных клиентов.
На рисунке 4-7 показан набор HTTP-клиентов, подключающихся к облачному приложению с включенным Azure SignalR.
Рис. 4-7. Служба
Еще одним преимуществом Служба Azure SignalR является реализация бессерверных облачных служб. Возможно, код выполняется по запросу с помощью триггеров Функции Azure. Этот сценарий может оказаться сложным, так как код не поддерживает длинные подключения с клиентами. Служба Azure SignalR может справиться с этой ситуацией, так как она автоматически управляет подключениями.
Служба Azure SignalR тесно интегрируется с другими службами Azure, такими как База данных SQL Azure, служебная шина или кэш Redis, открывая множество возможностей для облачных приложений.
