Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».
Если в последние годы вы следили за тенденциями в области распределенных и облачных архитектур, вы наверняка не раз слышали о микросервисах. Они появились несколько лет назад, и с тех пор их роль в вопросах корпоративных облачных развертываний только растет. Все больше компаний переходят на микросервисы и заявляют об этом в своих публикациях и пресс-релизах.
Их выбор вполне оправдан, но лишь немногие рассказывают, что стоит за таким переходом. При должной реализации микросервисы решают множество проблем монолитной архитектуры: их легко итерировать и распределять по группам, а код без труда разбивается на управляемые компоненты. Однако в большинстве публикаций нет ни слова о последующей работе с микросервисами и инструментах, необходимых для их эффективного использования.
Сегодня мы заглянем за кулисы и разберемся, что такое service mesh, как эта технология помогает решить проблемы микросервисных архитектур и упрощает работу разработчиков. Надеюсь, вы получите подробное представление о ее роли в развертываниях микросервисов.
Service mesh (также встречаются термины «сеть микросервисов», «mesh-сеть микросервисов») — это абстрактный слой инфраструктуры, который определяет взаимодействие между микросервисами приложения. Технология использует сетевые соединения между контейнерами для управления взаимодействием различных компонентов приложения. Звучит довольно абстрактно, но на самом деле это вполне практическая концепция. Контейнеры взаимодействуют через сеть, поэтому изменение топологии сети позволяет изменить порядок взаимодействия контейнеров.
Эффективное взаимодействие играет ключевую роль в работе микросервисов. Управление этим взаимодействием с помощью service mesh дает массу преимуществ. Так, при развертывании новых версий компонентов можно моментально переключать сетевые устройства со старых экземпляров на новые без дополнительной настройки. Если возникнут трудности с масштабированием, можно использовать service mesh для перенаправления трафика на различные балансировщики нагрузки и увеличения количества контейнеров для компонентов приложения.
Популярный совет для тех, кто начинает работать с микросервисами, звучит так: относитесь к различным компонентам приложения, как к API абсолютно разных поставщиков. Технология service mesh позволяет реализовать этот принцип на сетевом уровне и с точностью определить, какие сервисы будут доступны в тех или иных сетевых расположениях. В случае перемещения или модификации сервиса вместо развертывания новой конфигурации достаточно изменить сетевое взаимодействие.
Микросервисы популярны благодаря широким возможностям масштабирования и подходят для работы с крупными приложениями, которые можно разбивать на легко управляемые компоненты. Монолитные архитектуры, напротив, удобны в тех областях, где важна централизация. В монолитных приложениях проще вести регистрацию событий, поскольку они выполняются в одном расположении. Контроль версий также не вызывает сложностей, так как перезаписывается единственный экземпляр. Неудивительно, что многие разработчики теряются при переходе от монолитных архитектур к микросервисным, где нет единого расположения для ведения журналов и сложнее выделять нужные версии компонентов.
Преимущество технологии service mesh заключается в том, что она играет роль центрального источника некоторых данных, в частности данных о сетевых взаимодействиях. Рассмотрим вышеупомянутый пример развертывания новой версии компонента приложения. Вместо уничтожения всех контейнеров, содержащих старую версию, запуска новых контейнеров с новой версией и повторения этого процесса для других связанных с ней компонентов можно контролировать, какие контейнеры будут видны другим контейнерам в сети.
Это значит, что для развертывания новой версии достаточно просто указать новые контейнеры в качестве целевых с помощью DNS, сделать целевым новый балансировщик нагрузки или изменить контейнеры, на которые нацелен существующий балансировщик.
Сосредоточившись на взаимодействиях между компонентами приложения (на mesh-сети, в которой они работают), можно поддерживать определенный уровень централизации, которая так упрощает администрирование в монолитной среде. Вам нужно больше информации о трафике, проходящем через приложение? Добавьте возможности мониторинга в сеть между компонентами. Хотите повысить уровень безопасности? Внедрите надежное шифрование и протокол HTTPS. Все это возможно благодаря service mesh.
В ближайшие пару недель мы будем более подробно изучать работу mesh-сети и ее практическое применение в некоторых сценариях развертывания микросервисов. Мы сосредоточимся на реальных преимуществах этой технологии: эффективном контроле, управляемости и возможности наблюдать за процессами крупных приложений.
Если в последние годы вы следили за тенденциями в области распределенных и облачных архитектур, вы наверняка не раз слышали о микросервисах. Они появились несколько лет назад, и с тех пор их роль в вопросах корпоративных облачных развертываний только растет. Все больше компаний переходят на микросервисы и заявляют об этом в своих публикациях и пресс-релизах.
Их выбор вполне оправдан, но лишь немногие рассказывают, что стоит за таким переходом. При должной реализации микросервисы решают множество проблем монолитной архитектуры: их легко итерировать и распределять по группам, а код без труда разбивается на управляемые компоненты. Однако в большинстве публикаций нет ни слова о последующей работе с микросервисами и инструментах, необходимых для их эффективного использования.
Сегодня мы заглянем за кулисы и разберемся, что такое service mesh, как эта технология помогает решить проблемы микросервисных архитектур и упрощает работу разработчиков. Надеюсь, вы получите подробное представление о ее роли в развертываниях микросервисов.
Что такое service mesh?
Service mesh (также встречаются термины «сеть микросервисов», «mesh-сеть микросервисов») — это абстрактный слой инфраструктуры, который определяет взаимодействие между микросервисами приложения. Технология использует сетевые соединения между контейнерами для управления взаимодействием различных компонентов приложения. Звучит довольно абстрактно, но на самом деле это вполне практическая концепция. Контейнеры взаимодействуют через сеть, поэтому изменение топологии сети позволяет изменить порядок взаимодействия контейнеров.
Эффективное взаимодействие играет ключевую роль в работе микросервисов. Управление этим взаимодействием с помощью service mesh дает массу преимуществ. Так, при развертывании новых версий компонентов можно моментально переключать сетевые устройства со старых экземпляров на новые без дополнительной настройки. Если возникнут трудности с масштабированием, можно использовать service mesh для перенаправления трафика на различные балансировщики нагрузки и увеличения количества контейнеров для компонентов приложения.
Популярный совет для тех, кто начинает работать с микросервисами, звучит так: относитесь к различным компонентам приложения, как к API абсолютно разных поставщиков. Технология service mesh позволяет реализовать этот принцип на сетевом уровне и с точностью определить, какие сервисы будут доступны в тех или иных сетевых расположениях. В случае перемещения или модификации сервиса вместо развертывания новой конфигурации достаточно изменить сетевое взаимодействие.
Что это дает?
Микросервисы популярны благодаря широким возможностям масштабирования и подходят для работы с крупными приложениями, которые можно разбивать на легко управляемые компоненты. Монолитные архитектуры, напротив, удобны в тех областях, где важна централизация. В монолитных приложениях проще вести регистрацию событий, поскольку они выполняются в одном расположении. Контроль версий также не вызывает сложностей, так как перезаписывается единственный экземпляр. Неудивительно, что многие разработчики теряются при переходе от монолитных архитектур к микросервисным, где нет единого расположения для ведения журналов и сложнее выделять нужные версии компонентов.
Преимущество технологии service mesh заключается в том, что она играет роль центрального источника некоторых данных, в частности данных о сетевых взаимодействиях. Рассмотрим вышеупомянутый пример развертывания новой версии компонента приложения. Вместо уничтожения всех контейнеров, содержащих старую версию, запуска новых контейнеров с новой версией и повторения этого процесса для других связанных с ней компонентов можно контролировать, какие контейнеры будут видны другим контейнерам в сети.
Это значит, что для развертывания новой версии достаточно просто указать новые контейнеры в качестве целевых с помощью DNS, сделать целевым новый балансировщик нагрузки или изменить контейнеры, на которые нацелен существующий балансировщик.
Сосредоточившись на взаимодействиях между компонентами приложения (на mesh-сети, в которой они работают), можно поддерживать определенный уровень централизации, которая так упрощает администрирование в монолитной среде. Вам нужно больше информации о трафике, проходящем через приложение? Добавьте возможности мониторинга в сеть между компонентами. Хотите повысить уровень безопасности? Внедрите надежное шифрование и протокол HTTPS. Все это возможно благодаря service mesh.
Хотите узнать больше?
В ближайшие пару недель мы будем более подробно изучать работу mesh-сети и ее практическое применение в некоторых сценариях развертывания микросервисов. Мы сосредоточимся на реальных преимуществах этой технологии: эффективном контроле, управляемости и возможности наблюдать за процессами крупных приложений.
