Модели связи, ориентированные на облако
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
При создании облачной системы взаимодействие становится значительным решением по проектированию. Как интерфейсное клиентское приложение взаимодействует с серверной микрослужбой? Как внутренние микрослужбы взаимодействуют друг с другом? Каковы принципы, шаблоны и рекомендации, которые следует учитывать при реализации коммуникации в облачных приложениях?
Рекомендации по обмену данными
В монолитном приложении обмен данными прост. Модули кода выполняются вместе в одном исполняемом пространстве (процессе) на сервере. Этот подход может иметь преимущества производительности, так как все работает вместе в общей памяти, но приводит к тесно связанному коду, который становится трудно поддерживать, развивать и масштабировать.
Облачные системы реализуют архитектуру на основе микрослужб с множеством небольших независимых микрослужб. Каждая микрослужба выполняется в отдельном процессе и обычно выполняется внутри контейнера, развернутого в кластере.
Кластер группировать пул виртуальных машин вместе для формирования высокодоступной среды. Они управляются с помощью средства оркестрации, ответственного за развертывание контейнерных микрослужб и управление ими. На рисунке 4-1 показан кластер Kubernetes, развернутый в облаке Azure с полностью управляемыми Служба Azure Kubernetes.
Рис. 4-1. Кластер Kubernetes в Azure
В кластере микрослужбы взаимодействуют друг с другом с помощью API и технологий обмена сообщениями.
Хотя они предоставляют множество преимуществ, микрослужбы не являются бесплатным обедом. Локальные вызовы метода внутрипроцессного процесса между компонентами теперь заменяются сетевыми вызовами. Каждая микрослужба должна взаимодействовать по сетевому протоколу, что повышает сложность системы:
- Перегрузка сети, задержка и временные ошибки являются постоянной проблемой.
- Устойчивость (т. е. повторная попытка неудачных запросов) является важной.
- Некоторые вызовы должны быть идемпотентными для поддержания согласованного состояния.
- Каждая микрослужба должна проходить проверку подлинности и авторизовать вызовы.
- Каждое сообщение должно быть сериализовано, а затем десериализировано , что может быть дорогостоящим.
- Шифрование и расшифровка сообщений становится важным.
Книга .NET Microservices: Архитектура контейнерных приложений .NET, доступная бесплатно от Корпорации Майкрософт, предоставляет подробное освещение шаблонов связи для приложений микрослужб. В этой главе мы предоставляем общий обзор этих шаблонов, а также варианты реализации, доступные в облаке Azure.
В этой главе мы сначала рассмотрим связь между интерфейсными приложениями и внутренними микрослужбами. Затем мы рассмотрим внутренние микрослужбы, взаимодействуя друг с другом. Мы рассмотрим технологию коммуникации gRPC. Наконец, мы рассмотрим новые инновационные шаблоны коммуникации с помощью технологии сетки служб. Кроме того, мы увидим, как облако Azure предоставляет различные типы служб поддержки для поддержки облачной связи.
