Service Mesh — это известный архитектурный шаблон для интеграции микросервисов и перехода к облачной инфраструктуре.
Сегодня в мире облачных контейнеров без него довольно сложно обойтись.
На рынке уже доступны несколько реализаций сервисной сетки с открытым исходным кодом, но их функциональность, надежность и безопасность не всегда достаточны, особенно когда речь идет о требованиях крупных финансовых компаний по всей стране.
Именно поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим поговорить о том, что в Service Mesh круто, что не очень и что мы собираемся с этим делать.
Популярность паттерна Service Mesh растет вместе с популярностью облачных технологий.
Это выделенный уровень инфраструктуры, который упрощает взаимодействие между различными сетевыми службами.
Современные облачные приложения состоят из сотен или даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.
Взаимодействие и управление этими сервисами является ключевой задачей Service Mesh. По сути, это сетевая модель множества прокси, управляемых централизованно и выполняющих набор очень полезных функций.
На уровне прокси (плоскости данных):
- Назначение и распространение политик маршрутизации и балансировки трафика.
- Раздача ключей, сертификатов, токенов
- Сбор телеметрии, формирование метрик мониторинга
- Интеграция с инфраструктурой безопасности и мониторинга
- Применение политик маршрутизации и балансировки трафика
- Управление повторными попытками и таймаутами, обнаружение «мертвых» узлов (обрыв цепи), управление внесением сбоев и обеспечение устойчивости обслуживания с помощью других механизмов.
- Аутентификация/авторизация вызова
- Удаление метрик (наблюдаемость)
Зачем Service Mesh нужен в корпоративном секторе?
Использование Service Mesh имеет множество очевидных преимуществ.В первую очередь это просто удобно для разработчиков: для написания кода появляется технологическая платформа , что существенно упрощает интеграцию в облачную инфраструктуру за счет того, что транспортный уровень полностью изолирован от логики приложения.
Кроме, Service Mesh упрощает отношения между поставщиками и потребителями.
Сегодня поставщикам API и потребителям гораздо проще согласовывать интерфейсы и контракты самостоятельно, без привлечения специального интеграционного посредника и арбитра — корпоративной сервисной шины.
Такой подход существенно влияет на два показателя.
Скорость вывода нового функционала на рынок (time-to-market) увеличивается, но при этом увеличивается стоимость решения, поскольку интеграцию приходится производить самостоятельно.
Использование Service Mesh командами разработки бизнес-функций помогает поддерживать здесь баланс.
В результате поставщики API могут сосредоточиться исключительно на прикладной составляющей своего сервиса и просто опубликовать ее в Service Mesh — API сразу станет доступен всем клиентам, а качество интеграции будет готовым к производству и не потребует ни единого строка дополнительного кода.
Следующее преимущество состоит в том, что разработчик, использующий Service Mesh, фокусируется исключительно на бизнес-функциональности — на продукте, а не на технологической составляющей его услуги.
Например, вам больше не придется думать о том, что в ситуации, когда по сети вызывается сервис, где-то может произойти сбой соединения.
Кроме того, Service Mesh помогает балансировать трафик между копиями одного и того же сервиса: если одна из копий «умирает», система переключит весь трафик на оставшиеся живые копии.
Сервисная сетка — это хорошая основа для создания распределенных приложений , который скрывает от клиента детали предоставления обращений к его сервисам как внутри, так и снаружи.
Все приложения, использующие Service Mesh, изолированы на транспортном уровне как от сети, так и друг от друга: между ними нет связи.
В этом случае разработчик получает полный контроль над своими сервисами.
Необходимо отметить, что Обновление распределенных приложений в среде Service Mesh становится проще.
Например, синее/зеленое развертывание, при котором для установки доступны две среды приложений, одна из которых не обновляется и находится в режиме ожидания.
Откат к предыдущей версии в случае неудачного релиза осуществляется специальным роутером, с ролью которого хорошо справляется Service Mesh. .
Чтобы протестировать новую версию, вы можете использовать канарейка релиз — переходить на новую версию только 10% трафика или запросов от пилотной группы клиентов.
Основной трафик идет на старую версию, ничего не ломается.
Также Service Mesh дает нам контроль SLA в режиме реального времени .
Распределенная прокси-система не позволит сервису выйти из строя при превышении одним из клиентов назначенной ему квоты.
Если пропускная способность API ограничена, никто не сможет перегрузить его большим количеством транзакций: Service Mesh стоит перед сервисом и не пропускает лишний трафик.
Он просто будет отбиваться на уровне интеграции, а сами сервисы продолжат работать, даже не заметив этого.
Если компания хочет снизить затраты на разработку интеграционных решений, Service Mesh также помогает: Вы можете перейти на его версию с открытым исходным кодом из коммерческих продуктов.
.
Наша Enterprise Service Mesh основана на версии Service Mesh с открытым исходным кодом.
Другое преимущество - наличие единого полноценного набора интеграционных услуг .
Поскольку вся интеграция осуществляется с помощью этого промежуточного программного обеспечения, мы можем управлять всем интеграционным трафиком и соединениями между приложениями, которые составляют ядро бизнеса компании.
Это очень удобно.
И наконец Service Mesh побуждает компании переходить к динамической инфраструктуре.
Сейчас многие смотрят в сторону контейнеризации.
Разрезать монолит на микросервисы, красиво всё это реализовать — тема на подъеме.
Но когда пытаешься перенести на новую платформу систему, находящуюся в продакшене уже много лет, сразу сталкиваешься с рядом проблем: запихнуть все это в контейнеры и развернуть на платформе непросто.
А реализация, синхронизация и взаимодействие этих распределенных компонентов — еще одна очень сложная тема.
Как они будут общаться друг с другом? Будут ли каскадные сбои? Service Mesh позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что можно забыть о логике сетевого обмена.
Зачем вам нужна настройка Service Mesh?
В нашей компании сосуществуют сотни систем и модулей, и среда выполнения очень загружена.Таким образом, простой модели, когда одна система вызывает другую и получает ответ, недостаточно, потому что в производстве мы хотим большего.
Что еще вам нужно от корпоративной сервисной сети? 
Служба обработки событий
Представим, что нам нужно сделать обработку событий в реальном времени — систему, которая анализирует действия клиента в режиме реального времени и может сразу сделать ему актуальное предложение.Для реализации аналогичной функциональности используйте архитектурный шаблон, называемый событийно-ориентированной архитектурой (EDA) .
Ни одна из существующих сейчас Service Mesh изначально не поддерживает такие шаблоны, но это очень важно, особенно для банка! Довольно странно, что Remote Process 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. Эти данные можно проанализировать с помощью искусственного интеллекта, машинного обучения и т. д., а затем на основе результатов анализа сделать что-то полезное.
Было бы целесообразно хотя бы частично передать управление всем этим сетевым трафиком и вызовами приложений, интегрированных в Service Mesh, искусственному интеллекту.
Служба шлюза API
Обычно Service Mesh имеет прокси и сервисы, которые взаимодействуют друг с другом в пределах доверенного периметра.Но есть и внешние контрагенты.
Требования к API, предъявляемым к этой группе потребителей, гораздо более строгие.
Эту задачу мы разделим на две основные части.
- Безопасность .
Проблемы, связанные с ddos, уязвимостью протоколов, приложений, операционных систем и так далее.
- Шкала .
Когда количество API, которые необходимо обслуживать клиентам, исчисляется тысячами или даже сотнями тысяч, возникает необходимость в каком-то инструменте управления этим набором API. Вам необходимо постоянно следить за API: работают они или нет, какой у них статус, какой трафик идет, какая статистика и т. д. API-шлюз должен справиться с этой задачей, делая при этом весь процесс управляемым и безопасным.
Благодаря этому компоненту Enterprise Service Mesh учится легко публиковать как внутренние, так и внешние API.
Служба поддержки конкретных протоколов и форматов данных (шлюз AS)
В настоящее время большинство решений Service Mesh могут работать только с трафиком HTTP и HTTP2 или в сокращенном режиме на уровне TCP/IP. Enterprise Service Mesh появляется вместе со многими другими очень специфическими протоколами передачи данных.Некоторые системы могут использовать брокеры сообщений, другие интегрированы на уровне базы данных.
Если у компании есть SAP, то она также может использовать собственную систему интеграции.
Более того, все это работает и является важной частью бизнеса.
Нельзя просто сказать: «Давайте откажемся от наследия и создадим новые системы, которые смогут использовать Service Mesh».
Чтобы соединить все старые системы с новыми (на микросервисной архитектуре), системам, которые могут использовать Service Mesh, понадобится какой-то адаптер, посредник, шлюз.
Согласитесь, было бы неплохо, если бы оно шло в коробке вместе с сервисом.
Шлюз AC может поддерживать любой вариант интеграции.
Представьте себе: вы просто устанавливаете Enterprise Service Mesh, и он готов взаимодействовать со всеми необходимыми вам протоколами.
Для нас этот подход очень важен.
Примерно так мы представляем себе корпоративную версию Service Mesh (Enterprise Service Mesh).
Описанная настройка решает большую часть проблем, возникающих при попытке использовать готовые открытые версии интеграционной платформы.
Архитектура Service Mesh, представленная всего пару лет назад, продолжает развиваться, и мы рады возможности внести свой вклад в ее развитие.
Надеемся, что наш опыт будет вам полезен.
Теги: #ит-инфраструктура #облачные сервисы #Микросервисы #Распределенные системы #Сбербанк
-
Атака Dhcp, Часть 3. Dhcp + Apple = Mitm
19 Oct, 24 -
9 Новых Способов Космического Туризма
19 Oct, 24 -
Иногда Поднимай Задницу Со Стула
19 Oct, 24
