Поделиться через


Инфраструктура связи сетки служб

Подсказка

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

Миниатюра обложки электронной книги Azure с Cloud Native .NET приложениями.

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

Мы изучили различные подходы к реализации синхронной связи HTTP и асинхронного обмена сообщениями. В каждом из случаев на разработчика ложится обязанность реализовать код для связи. Код связи является сложным и трудоемким. Неправильные решения могут привести к значительным проблемам с производительностью.

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

Ключевым компонентом сетки службы является прокси-сервер. В облачном приложении экземпляр прокси-сервера обычно находится совместно с каждой микрослужбой. Хотя они выполняются в отдельных процессах, они тесно связаны и совместно используют один и тот же жизненный цикл. Этот шаблон, известный как шаблон Sidecar, показан на рисунке 4-24.

Сетка обслуживания с боковой машиной

Рис. 4-24. Сетка обслуживания с боковой машиной

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

Помимо управления обменом данными между службами, сетка служб обеспечивает поддержку обнаружения служб и балансировки нагрузки.

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

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

В главе 6 мы подробно рассмотрим технологии Service Mesh, включая обсуждение архитектуры и доступных реализаций с открытым кодом.

Сводка

В этой главе мы обсудили шаблоны взаимодействия на основе облака. Мы начали изучать, как интерфейсные клиенты взаимодействуют с внутренними микрослужбами. На этом пути мы говорили о платформах шлюза API и обмене данными в режиме реального времени. Затем мы рассмотрели, как микрослужбы взаимодействуют с другими внутренними службами. Мы рассмотрели как синхронную HTTP-коммуникацию, так и асинхронный обмен сообщениями между службами. Мы рассмотрели gRPC, новую технологию в мире облачных технологий. Наконец, мы представили новую и быстро развивающуюся технологию с названием "Сетка служб", которая может упростить взаимодействие микрослужб.

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

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

Ссылки