Вы поймёте service mesh, поработаете руками с технологией, выполнив практические задания. Все это поможет понять необходимость внедрения и подготовиться к нему без костылей в архитектуре.
Бизнес-кейсы, которые будем решать
- Проблема #1. Мониторинга нет, или он слабо развит. Система периодически тормозит, но непонятно, в каких местах.
- Проблема #2. Клиенты жалуются, что сервисы иногда отдают ошибки. Из мониторинга видно, что падения кратковременные, но частые. Менять что-то в приложении можно, но дорого — много разных стеков.
- Проблема #3. Нужно выкатить новую фичу, но нет уверенности, что все пойдет как надо. Времени на всеобъемлющее тестирование нет, нужно выкатывать.
- Проблема #4. В системе появляется новый компонент который отвечает за процессинг кредитных карт. Появляются требования к безопасности системы всей системы.
- Проблема #5. Приложение разрослось. Клиенты жалуются на долгое время ответа. На серверной стороне все ок. Похоже проблема с удаленными геолокациями.
Зачем нужен service mesh
- Оbservability — прозрачный мониторинг API вызовов в системе, позволяет значительно сократить время на поиск и устранение проблем.
- Унифицированные политики прокси Envoy упрощают взаимодействие между любым количеством микросервисов, написанных на любых языках — все приводится к общему знаменателю.
- Service mesh обеспечивает прозрачное управление входящим и исходящим трафиком в едином месте, систему можно гибко тюнить, добавляя или удаляя правила.
