Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.
Популярность шаблона Service Mesh растет с популярностью облачных технологий. Он представляет собой выделенный инфраструктурный слой, который упрощает взаимодействие между различными сетевыми сервисами. Современные облачные приложения состоят из сотен и даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.
Взаимодействие между этими сервисами и управление ими — ключевая задача Service Mesh. Фактически это сетевая модель из множества прокси, управляемая централизованно и выполняющая набор весьма полезных функций.
На уровне прокси (data plane):
На уровне управляющего контура (control plane):
Круг пользователей, заинтересованных в развитии этой технологии, очень широк — от небольших стартапов до крупных интернет-корпораций, например, PayPal.
Использование Service Mesh приносит множество очевидных преимуществ. Прежде всего, это просто удобно разработчикам: для написания кода появляется технологическая платформа, которая существенно упрощает интеграцию в облачную инфраструктуру за счет того, что транспортный слой полностью изолирован от прикладной логики.
Кроме того, Service Mesh упрощает взаимоотношения поставщиков и потребителей. Сегодня поставщикам и потребителям API гораздо проще договориться об интерфейсах и контрактах самостоятельно, не привлекая для этого специального интеграционного посредника и арбитра – корпоративную сервисную шину. Такой подход существенно влияет на два показателя. Увеличивается скорость вывода новой функциональности на рынок (time-to-market), но при этом повышается стоимость решения, так как интеграцию приходится делать самостоятельно. Использование Service Mesh командами разработки бизнес-функциональности позволяет сохранить здесь баланс. В итоге поставщики API могут сфокусироваться исключительно на прикладной составляющей своего сервиса и просто опубликовать его в Service Mesh — API сразу станет доступен всем клиентам, а качество интеграции будет production ready и не потребует ни одной строчки дополнительного кода.
Следующим преимуществом является то, что разработчик, используя Service Mesh, фокусируется исключительно на бизнес-функциональности — на продуктовой, а не на технологической составляющей своего сервиса. Например, уже не приходится думать о том, что в ситуации, когда сервис будет вызываться по сети, где-то может произойти обрыв соединения. Кроме того, Service Mesh помогает сбалансировать трафик между копиями одного и того же сервиса: если одна из копий «умерла», то система переключит весь трафик на оставшиеся живые копии.
Service Mesh — это хорошая основа для создания распределенных приложений, которая скрывает от клиента детали обеспечения вызовов его сервисов как изнутри, так и снаружи. Все приложения, использующие Service Mesh, на транспортном уровне изолированы и от сети, и друг от друга: никакой связи между ними нет. При этом разработчик получает полный контроль над своими сервисами.
Нельзя не отметить, что обновление распределенных приложений в среде, где используется Service Mesh, становится проще. Например, blue/green-развертывание, при котором для установки доступны две среды приложения, одна из которых не обновляется и находится в режиме ожидания. Откат на прошлую версию в случае неудачного релиза осуществляется специальным роутером, с ролью которого прекрасно справляется Service Mesh. Для обкатки новой версии можно использовать и канареечный релиз — переключить на новую версию только 10% трафика или запросы от пилотной группы клиентов. Основной трафик идет на старую версию, ничего не ломается.
Также Service Mesh дает нам контроль SLA в реальном времени. Система распределенных прокси не позволит завалить сервис, когда кто-то из клиентов превысит выданную ему квоту. Если пропускная способность по API ограничена, никто не сможет заддосить его большим количеством транзакций: Service Mesh стоит перед сервисом и не пропускает лишний трафик. Он просто будет отбиваться в интеграционном слое, а сами сервисы продолжат работать, не замечая этого.
Если компания хочет сократить расходы на развитие интеграционных решений, Service Mesh также выручает: на его open-source версии можно перейти с коммерческих продуктов. Наш Enterprise Service Mesh базируется на open-source версии Service Mesh.
Еще одно преимущество — наличие единого полноценного набора интеграционных сервисов. Поскольку вся интеграция строится через этот промежуточный слой, мы можем управлять всем интеграционным трафиком и связями между приложениями, которые формируют бизнес-ядро компании. Это очень удобно.
И наконец Service Mesh стимулирует компанию к переходу на динамическую инфраструктуру. Сейчас многие смотрят в сторону контейнеризации. Распиливать монолит на микросервисы, все это красиво внедрять — тема находится на подъеме. Но когда ты пытаешься перевести на новые рельсы систему, которая уже много лет в продакшне, то сразу сталкиваешься с целым рядом проблем: затолкать все это в контейнеры и развернуть на платформе непросто. А внедрение, синхронизация и взаимодействие этих распределенных компонентов —еще одна сложнейшая тема. Как они будут друг с другом общаться? Не будет ли каскадных сбоев? Service Mesh позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что про логику сетевого обмена можно забыть.
У нас в компании уживаются вместе сотни систем и модулей, а runtime очень нагружен. Так что простого паттерна, когда одна система вызывает другую и получает ответ, недостаточно, потому что в production мы хотим большего. Что еще нужно от корпоративного Service Mesh?
Представим, что нам нужно сделать real-time event processing — систему, которая в реальном времени анализирует действия клиента и может сразу сделать ему релевантное предложение. Чтобы реализовать подобную функциональность, используется архитектурный паттерн под названием event-driven architecture (EDA). Ни один из актуальных Service Mesh такие паттерны нативно не поддерживает, а ведь это очень важно, особенно для банка!
Довольно странно, что «удаленный вызов» Remote Procedure Call (RPC) поддерживают все версии Service Mesh, а с EDA они не дружат. Потому что Service Mesh — это подобие современной распределенной интеграции, а EDA — очень актуальный архитектурный паттерн, который позволяет делать уникальные вещи в плане клиентского опыта.
Наш Enterprise Service Mesh данную проблему должен решать. Кроме того, мы хотим видеть в нем реализацию гарантированной доставки, потоковой и комплексной обработки событий с использованием разнообразных фильтров и шаблонов.
Помимо EDA было бы неплохо иметь возможность передавать файлы: в масштабах Enterprise очень часто возможна только файловая интеграция. В частности, используется архитектурный паттерн ETL (Extract, Transform, Load — «извлечение, преобразование, загрузка»). В нем, как правило, все обмениваются исключительно файлами: используются большие данные, которые нецелесообразно пихать отдельными запросами. Возможность нативной поддержки передачи файлов в Enterprise Service Mesh дает необходимую для бизнеса гибкость.
В крупных организациях почти всегда есть разные команды, которые делают разные продукты. Например, в банке одни команды работают с депозитами, а другие — с кредитными продуктами, и таких кейсов достаточно много. Это разные люди, разные команды, которые делают свои продукты, разрабатывают свои API и предоставляют их другим. И очень часто возникает потребность в композиции этих сервисов, а также имплементации сложной логики последовательного вызова набора API. Для решения данной проблемы необходимо решение в интеграционном слое, которое позволит упростить всю эту композитную логику (вызов нескольких API, описание маршрута запросов и т.д.). Это и есть сервис оркестрации в Enterprise Service Mesh.
Когда микросервисы общаются через единый интеграционный слой, Service Mesh, естественно, знает все о вызовах каждого сервиса. Мы собираем телеметрию: кто кого вызывал, когда, как долго, сколько раз и так далее. Когда этих сервисов сотни тысяч, а вызовов — миллиарды, то все это накапливается и формирует Big Data. Эти данные можно проанализировать средствами ИИ, machine learning и пр., а потом сделать на основе результатов анализа какие-то полезные вещи. Было бы уместно хотя бы частично передать искусственному интеллекту управление всем этим сетевым трафиком и вызовами приложений, интегрированных в Service Mesh.
Как правило, в Service Mesh есть прокси и сервисы, которые обращаются друг с другом внутри доверенного периметра. Но существуют еще и внешние контрагенты. Требования к API, предоставляемым этой группе потребителей, намного серьезнее. Эту задачу мы делим на две основные части.
На текущий момент большинство решений Service Mesh умеют нативно работать только с трафиком HTTP и HTTP2 или в урезанном режиме на уровне TCP/IP. У Enterprise Service Mesh появляется много других весьма специфических протоколов передачи данных. Одни системы могут использовать брокеры сообщений, другие интегрированы на уровне баз данных. Если в компании есть SAP, то он также может использовать собственную систему интеграции. Причем все это работает и является важной частью бизнеса.
Нельзя просто сказать: «Давайте откажемся от legacy и сделаем новые системы, которые смогут использовать Service Mesh». Чтобы подружить все старые системы с новыми (на микросервисной архитектуре), системам, которые могут использовать Service Mesh, понадобится какой-то адаптер, посредник, шлюз. Согласитесь, было бы неплохо, если бы он поставлялся в коробке вместе с сервисом. Шлюз АС как раз и может поддержать любой вариант интеграции. Только представьте, вы просто устанавливаете Enterprise Service Mesh, и он уже готов взаимодействовать со всеми протоколами, которые вам нужны. Для нас такой подход очень важен.
Примерно так мы представляем корпоративную версию Service Mesh (Enterprise Service Mesh). Описанная кастомизация решает большинство проблем, возникающих при попытках использовать готовые open-source версии интеграционной платформы. Появившись всего пару лет назад, архитектура Service Mesh продолжает развиваться, и мы рады, что можем внести вклад в ее развитие. Надеемся, что наш опыт будет вам полезен.
Популярность шаблона Service Mesh растет с популярностью облачных технологий. Он представляет собой выделенный инфраструктурный слой, который упрощает взаимодействие между различными сетевыми сервисами. Современные облачные приложения состоят из сотен и даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.
Взаимодействие между этими сервисами и управление ими — ключевая задача Service Mesh. Фактически это сетевая модель из множества прокси, управляемая централизованно и выполняющая набор весьма полезных функций.
На уровне прокси (data plane):
- Назначение и распространение политик маршрутизации и балансировки трафика
- Распространение ключей, сертификатов, токенов
- Сбор телеметрии, формирование метрик мониторинга
- Интеграция с инфраструктурой безопасности и мониторинга
На уровне управляющего контура (control plane):
- Применение политик маршрутизации и балансировки трафика
- Управление повторами и таймаутами, определение «мертвых» узлов (сircuit breaking), управление сбойными ситуациями (injecting faults) и обеспечение устойчивости (resilence) сервисов через другие механизмы
- Аутентификация/авторизация вызовов
- Отбрасывание метрик (observability)
Круг пользователей, заинтересованных в развитии этой технологии, очень широк — от небольших стартапов до крупных интернет-корпораций, например, PayPal.
Для чего нужен Service Mesh в корпоративном секторе
Использование Service Mesh приносит множество очевидных преимуществ. Прежде всего, это просто удобно разработчикам: для написания кода появляется технологическая платформа, которая существенно упрощает интеграцию в облачную инфраструктуру за счет того, что транспортный слой полностью изолирован от прикладной логики.
Кроме того, Service Mesh упрощает взаимоотношения поставщиков и потребителей. Сегодня поставщикам и потребителям API гораздо проще договориться об интерфейсах и контрактах самостоятельно, не привлекая для этого специального интеграционного посредника и арбитра – корпоративную сервисную шину. Такой подход существенно влияет на два показателя. Увеличивается скорость вывода новой функциональности на рынок (time-to-market), но при этом повышается стоимость решения, так как интеграцию приходится делать самостоятельно. Использование Service Mesh командами разработки бизнес-функциональности позволяет сохранить здесь баланс. В итоге поставщики API могут сфокусироваться исключительно на прикладной составляющей своего сервиса и просто опубликовать его в Service Mesh — API сразу станет доступен всем клиентам, а качество интеграции будет production ready и не потребует ни одной строчки дополнительного кода.
Следующим преимуществом является то, что разработчик, используя Service Mesh, фокусируется исключительно на бизнес-функциональности — на продуктовой, а не на технологической составляющей своего сервиса. Например, уже не приходится думать о том, что в ситуации, когда сервис будет вызываться по сети, где-то может произойти обрыв соединения. Кроме того, Service Mesh помогает сбалансировать трафик между копиями одного и того же сервиса: если одна из копий «умерла», то система переключит весь трафик на оставшиеся живые копии.
Service Mesh — это хорошая основа для создания распределенных приложений, которая скрывает от клиента детали обеспечения вызовов его сервисов как изнутри, так и снаружи. Все приложения, использующие Service Mesh, на транспортном уровне изолированы и от сети, и друг от друга: никакой связи между ними нет. При этом разработчик получает полный контроль над своими сервисами.
Нельзя не отметить, что обновление распределенных приложений в среде, где используется Service Mesh, становится проще. Например, blue/green-развертывание, при котором для установки доступны две среды приложения, одна из которых не обновляется и находится в режиме ожидания. Откат на прошлую версию в случае неудачного релиза осуществляется специальным роутером, с ролью которого прекрасно справляется Service Mesh. Для обкатки новой версии можно использовать и канареечный релиз — переключить на новую версию только 10% трафика или запросы от пилотной группы клиентов. Основной трафик идет на старую версию, ничего не ломается.
Также Service Mesh дает нам контроль SLA в реальном времени. Система распределенных прокси не позволит завалить сервис, когда кто-то из клиентов превысит выданную ему квоту. Если пропускная способность по API ограничена, никто не сможет заддосить его большим количеством транзакций: Service Mesh стоит перед сервисом и не пропускает лишний трафик. Он просто будет отбиваться в интеграционном слое, а сами сервисы продолжат работать, не замечая этого.
Если компания хочет сократить расходы на развитие интеграционных решений, Service Mesh также выручает: на его open-source версии можно перейти с коммерческих продуктов. Наш Enterprise Service Mesh базируется на open-source версии Service Mesh.
Еще одно преимущество — наличие единого полноценного набора интеграционных сервисов. Поскольку вся интеграция строится через этот промежуточный слой, мы можем управлять всем интеграционным трафиком и связями между приложениями, которые формируют бизнес-ядро компании. Это очень удобно.
И наконец Service Mesh стимулирует компанию к переходу на динамическую инфраструктуру. Сейчас многие смотрят в сторону контейнеризации. Распиливать монолит на микросервисы, все это красиво внедрять — тема находится на подъеме. Но когда ты пытаешься перевести на новые рельсы систему, которая уже много лет в продакшне, то сразу сталкиваешься с целым рядом проблем: затолкать все это в контейнеры и развернуть на платформе непросто. А внедрение, синхронизация и взаимодействие этих распределенных компонентов —еще одна сложнейшая тема. Как они будут друг с другом общаться? Не будет ли каскадных сбоев? Service Mesh позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что про логику сетевого обмена можно забыть.
Зачем нужна кастомизация Service Mesh
У нас в компании уживаются вместе сотни систем и модулей, а runtime очень нагружен. Так что простого паттерна, когда одна система вызывает другую и получает ответ, недостаточно, потому что в production мы хотим большего. Что еще нужно от корпоративного Service Mesh?
Сервис обработки событий
Представим, что нам нужно сделать real-time event processing — систему, которая в реальном времени анализирует действия клиента и может сразу сделать ему релевантное предложение. Чтобы реализовать подобную функциональность, используется архитектурный паттерн под названием event-driven architecture (EDA). Ни один из актуальных Service Mesh такие паттерны нативно не поддерживает, а ведь это очень важно, особенно для банка!
Довольно странно, что «удаленный вызов» Remote Procedure Call (RPC) поддерживают все версии Service Mesh, а с EDA они не дружат. Потому что Service Mesh — это подобие современной распределенной интеграции, а EDA — очень актуальный архитектурный паттерн, который позволяет делать уникальные вещи в плане клиентского опыта.
Наш Enterprise Service Mesh данную проблему должен решать. Кроме того, мы хотим видеть в нем реализацию гарантированной доставки, потоковой и комплексной обработки событий с использованием разнообразных фильтров и шаблонов.
Сервис передачи файлов
Помимо EDA было бы неплохо иметь возможность передавать файлы: в масштабах Enterprise очень часто возможна только файловая интеграция. В частности, используется архитектурный паттерн ETL (Extract, Transform, Load — «извлечение, преобразование, загрузка»). В нем, как правило, все обмениваются исключительно файлами: используются большие данные, которые нецелесообразно пихать отдельными запросами. Возможность нативной поддержки передачи файлов в Enterprise Service Mesh дает необходимую для бизнеса гибкость.
Сервис оркестрации
В крупных организациях почти всегда есть разные команды, которые делают разные продукты. Например, в банке одни команды работают с депозитами, а другие — с кредитными продуктами, и таких кейсов достаточно много. Это разные люди, разные команды, которые делают свои продукты, разрабатывают свои API и предоставляют их другим. И очень часто возникает потребность в композиции этих сервисов, а также имплементации сложной логики последовательного вызова набора API. Для решения данной проблемы необходимо решение в интеграционном слое, которое позволит упростить всю эту композитную логику (вызов нескольких API, описание маршрута запросов и т.д.). Это и есть сервис оркестрации в Enterprise Service Mesh.
AI и ML
Когда микросервисы общаются через единый интеграционный слой, Service Mesh, естественно, знает все о вызовах каждого сервиса. Мы собираем телеметрию: кто кого вызывал, когда, как долго, сколько раз и так далее. Когда этих сервисов сотни тысяч, а вызовов — миллиарды, то все это накапливается и формирует Big Data. Эти данные можно проанализировать средствами ИИ, machine learning и пр., а потом сделать на основе результатов анализа какие-то полезные вещи. Было бы уместно хотя бы частично передать искусственному интеллекту управление всем этим сетевым трафиком и вызовами приложений, интегрированных в Service Mesh.
Сервис API Gateway (Шлюз API)
Как правило, в Service Mesh есть прокси и сервисы, которые обращаются друг с другом внутри доверенного периметра. Но существуют еще и внешние контрагенты. Требования к API, предоставляемым этой группе потребителей, намного серьезнее. Эту задачу мы делим на две основные части.
- Безопасность. Вопросы, связанные с ddos, уязвимостью протоколов, приложений, операционных систем и так далее.
- Масштабы. Когда счет API, которые нужно отдать клиентам, идет на тысячи или даже сотни тысяч, возникает необходимость в некоем средстве управления этим набором API. Нужно постоянно отслеживать API: работают они или нет, в каком статусе, какой трафик идет, какая статистика и т.д. Шлюз API должен справляться с этой задачей, делая весь процесс управляемым и безопасным. Благодаря этому компоненту Enterprise Service Mesh учится без лишних сложностей публиковать как внутренний API, так и внешний.
Сервис поддержки специфических протоколов и форматов данных (шлюз АС)
На текущий момент большинство решений Service Mesh умеют нативно работать только с трафиком HTTP и HTTP2 или в урезанном режиме на уровне TCP/IP. У Enterprise Service Mesh появляется много других весьма специфических протоколов передачи данных. Одни системы могут использовать брокеры сообщений, другие интегрированы на уровне баз данных. Если в компании есть SAP, то он также может использовать собственную систему интеграции. Причем все это работает и является важной частью бизнеса.
Нельзя просто сказать: «Давайте откажемся от legacy и сделаем новые системы, которые смогут использовать Service Mesh». Чтобы подружить все старые системы с новыми (на микросервисной архитектуре), системам, которые могут использовать Service Mesh, понадобится какой-то адаптер, посредник, шлюз. Согласитесь, было бы неплохо, если бы он поставлялся в коробке вместе с сервисом. Шлюз АС как раз и может поддержать любой вариант интеграции. Только представьте, вы просто устанавливаете Enterprise Service Mesh, и он уже готов взаимодействовать со всеми протоколами, которые вам нужны. Для нас такой подход очень важен.
Примерно так мы представляем корпоративную версию Service Mesh (Enterprise Service Mesh). Описанная кастомизация решает большинство проблем, возникающих при попытках использовать готовые open-source версии интеграционной платформы. Появившись всего пару лет назад, архитектура Service Mesh продолжает развиваться, и мы рады, что можем внести вклад в ее развитие. Надеемся, что наш опыт будет вам полезен.
