Инфраструктура связи для слоя взаимодействия между службами
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
В этой главе мы изучили проблемы взаимодействия микрослужб. Мы сказали, что команды разработчиков должны быть чувствительны к тому, как внутренние службы взаимодействуют друг с другом. В идеале, чем меньше взаимодействия между службами, тем лучше. Однако избегание не всегда возможно, так как внутренние службы часто полагаются друг на друга для выполнения операций.
Мы изучили различные подходы к реализации синхронной связи HTTP и асинхронного обмена сообщениями. В каждом из случаев разработчик обременит реализацией кода коммуникации. Код связи является сложным и трудоемким. Неправильные решения могут привести к значительным проблемам с производительностью.
Более современный подход к центрам коммуникации микрослужбы вокруг новой и быстро развивающейся технологии под названием "Сетка служб". Сетка служб — это настраиваемый уровень инфраструктуры с встроенными возможностями для обработки связи между службами, устойчивости и многих перекрестных проблем. Она перемещает ответственность за эти проблемы из микрослужб и в слой сетки служб. Связь абстрагируется от микрослужб.
Ключевым компонентом сетки службы является прокси-сервер. В облачном приложении экземпляр прокси-сервера обычно находится совместно с каждой микрослужбой. Хотя они выполняются в отдельных процессах, они тесно связаны и совместно используют один и тот же жизненный цикл. Этот шаблон, известный как шаблон бокового автомобиля, и показан на рисунке 4-24.
Рис. 4-24. Сетка обслуживания с боковой машиной
Обратите внимание на предыдущий рисунок, как сообщения перехватываются прокси-сервером, который выполняется вместе с каждой микрослужбой. Каждый прокси-сервер можно настроить с помощью правил трафика, относящихся к микрослужбе. Он понимает сообщения и может направлять их через службы и внешний мир.
Помимо управления обменом данными между службами, сетка служб обеспечивает поддержку обнаружения служб и балансировки нагрузки.
После настройки сетка службы очень функциональна. Сетка получает соответствующий пул экземпляров из конечной точки обнаружения служб. Он отправляет запрос конкретному экземпляру службы, записывая задержку и тип ответа результата. Он выбирает экземпляр, скорее всего, возвращать быстрый ответ на основе различных факторов, включая наблюдаемую задержку для последних запросов.
Сетка служб управляет трафиком, обменом данными и сетями на уровне приложения. Он понимает сообщения и запросы. Сетка служб обычно интегрируется с оркестратором контейнеров. Kubernetes поддерживает расширяемую архитектуру, в которой можно добавить сетку служб.
В главе 6 мы подробно рассмотрим технологии Service Mesh, включая обсуждение архитектуры и доступных реализаций с открытым кодом.
Итоги
В этой главе мы обсудили шаблоны взаимодействия на основе облака. Мы начали изучать, как интерфейсные клиенты взаимодействуют с внутренними микрослужбами. На этом пути мы говорили о платформах шлюза API и обмене данными в режиме реального времени. Затем мы рассмотрели, как микрослужбы взаимодействуют с другими внутренними службами. Мы рассмотрели синхронное взаимодействие HTTP и асинхронное обмен сообщениями между службами. Мы рассмотрели gRPC, предстоящие технологии в облачном мире. Наконец, мы представили новую и быстро развивающуюся технологию с названием "Сетка служб", которая может упростить взаимодействие микрослужб.
Особое внимание уделяется управляемым службам Azure, которые могут помочь реализовать обмен данными в облачных системах:
- Шлюз приложений Azure
- Управление API Azure
- Служба SignalR Azure
- Очереди службы хранилища Azure
- Служебная шина Azure
- Сетка событий Azure
- Концентратор событий Azure
Теперь мы перейдем к распределенным данным в облачных системах, а также к преимуществам и проблемам, которые она представляет.
