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

  • Статья

Совет

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

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

Cloud Native .NET apps for Azure eBook cover thumbnail.

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

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

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

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

Service mesh with a side car

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

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

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

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

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

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

Итоги

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

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

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

Ссылки

НазадДалее