Anton Sidorov homepage

Bookmark this to keep an eye on my project updates!

Follow me on GitHub

Microservice architecture

Зачем

Архитектурный стиль.

  • Сокращение time2market
  • Независимость
  • Небольшие команды
  • Разделение
  • Одна функция
  • Корректно описанные интерфейсы
  • Весь жизненный цикл
  • Минимизация коммуникаций
  • Уменьшение масштаба изменений

Плюсы и минусы

Критерии

Плюсы

  • Слабая связность Модульность
  • Непрерывная интеграция/развертывание сложных приложений
  • Не велики, просты в сопровождении
  • Разворачиваются независимо друг от друга
  • Масштабируемость независимо друг от друга
  • Независимая эволюция
  • Автономные команды разработчиков
  • Независимый тех стек. Простота экспериментов с новыми технологиями и их внедрения
  • Проще тестировать
  • Эффективная изоляция сбоев

Минусы

  • Сложно идентифицировать оптимальный набор сервисов при декомпозиции приложения (подходы DDD, Event Storming)
    • Если границы по-настоящему хорошо не определены, случится так, что — даже в случае теоретической возможности изолированного деплоя сервисов всплывут взаимные зависимости между сервисами, из-за которых придётся деплоить наборы сервисов как группу (архитектурный квант).
      • независимо масштабируемые сервисы вряд ли помогут, потому что остаётся влияние производительности зависимостей
  • Распределенные системы сложны по своей природе
    • Сложность распределенных транзакций (Сага)
  • Сложная инфраструктура (DevOps)
    • Разработка, тестирование и развертывание в распределенных сред требуют специальных навыков и инструментов
    • Инфраструктурный код
  • Развертывание изменений, которые затрагивают несколько служб, требует тщательной координации

Не подходит для:

  • Стартапов MVP
  • «Ядерных» систем бизнеса, требующих ACID транзакций

MSA vs Монолит

В сравнении с монолитом плюсы:

  • Независимое развертывание и обновление
  • При необходимости отдельные микросервисы могут быть развернуты или масштабированы независимо
  • Независимый релизный цикл
  • Разные языки программирования и БД в разных сервисах
    • Интересный стек технологий для разработчиков
  • Повторное использование
  • Микросервисы это изоляция по функционалу и по данным (каждый микросервис должен хранить данные в своей базе данных иначе считается что это не настоящие микросервисы).
  • Гибкое перераспределение нагрузки на всех уровнях
  • Высокая скорость доставки
  • Выделение и изолирование функциональности
  • Канареечные релизы
  • Небольшие команды
  • Возможность перепридумать решение с нуля
  • Высокая отказоустойчивость
  • Актуальные технологии индустрии, появилось большое число качественных opensource платформ
  • Слабая связанность
  • Можно быстро переписать код
  • Легко заменять модули
  • Устойчивость
  • Улучшение доступности за счет изоляции сбоев в границах отдельного сервиса
  • Изоляция и слабая связанность ведут к возможностям более гибкой эволюции в границах модуля
  • Поддержка множества платформ и языков
  • Быстрое тестирование
  • Быстрый деплой
  • Автономный деплой
  • Использование трассировки запросов между сервисами
  • Быстрота решения инцидентов
  • Быстрее локальная разработка - не нужно все разворачивать
  • Возможность динамического распределения нагрузки
  • Независимая разработка
  • Проще рефакторить, меньше тех.долга - проще переписать один независимый сервис
  • Свой архитектурный подход для каждого сервиса (DDD, CRUD)

Минусы:

  • Транзакции сложно, в идеале без них
  • Согласованность данных сложно обеспечить
  • наивно полагать, что микросервисы полностью избавят вашу ИТ-среду от сложности.
  • увеличении сложности управления, разработки и поддержки по причине их децентрализации.
  • Более того, не каждое приложение в корпоративной среде подходит для архитектуры микросервисов.
  • Сложность управления и мониторинга транзакций
  • Сложность сопровождения
  • Сложность проектирования
  • Сложный вход, так как толстый технологический стек
  • Дублирование данных (но не доменных сущностей)
  • Проблемы с целостностью межсервисных операций
  • Сквозное логирование бизнес-процесса
  • Дорогие специалисты
  • Сложность отладки
  • Сложность в поиске специалистов и обучении команд
  • Отсутствует качественная “теория” по моделированию распределенных асинхронных процессов - BPMN и прочие UML не эффективны
  • Сложность диагностики
  • Сложность проектирования и разработки
  • У каждой успешной компании в MSA свой “опыт” и “заплатки” трудно обобщать
  • Сложно всем этим зоопарком управлять
  • Сложность управлением памятью
  • Сложность системы в целом
  • Дольше разрабатывать
  • Сложнее определить требования к ресурсам
  • Стоимость владения может оказаться выше
  • Высокие затраты на входе
  • Производительность массовых операций из-за межсетевых вызовов
  • Поиск ошибок среди всего множества сервисов
  • Сложность использования общих библиотеки
  • Необходимость наличия культуры в организации
  • Сложность декомпозиции
  • Наличие множества БД и их поддержки
  • Необходимость в большом количестве инфраструктурных ресурсов
  • Требуется организация взаимосвязи между микросервисами
  • Больше оборудования чем в монолите
  • Без должной автоматизации деплой сложнее

Паттерны

Принципы к проектированию сервисов

  • У сервиса должна быть конкретная ответственность. Если для его полноценного функционирования нужен ещё сервис, то это ошибка проектирования, их нужно либо объединять, либо пересматривать архитектуру.
  • Критично смотрим на любые синхронные обращения. Для сервисов в одном направлении это допустимо, но для общения между сервисами разных направлений — нет
  • Share nothing - Мы не ходим в БД сервисов в обход них самих. Все запросы только через API.
  • Specification First - Сначала описываем и утверждаем протоколы.
  • Изменение, которое нарушает концептуальную целостность
  • Запросы вновь обнаруженных заказчиков
  • Новые каналы взаимодействия
  • Асинхронные обработчики исключений основного сценария
  • Автоматическую замену ручных операций
  • Справочники и основные данные
  • Graceful shutdown
  • Горизонтальное масштабирование
  • Идемпотентность
    • Повторы неизбежны
    • Делайте методы идемпотентными
    • Регистрируйте уже принятые ID событий
    • Игнорируйте более давние события

Reference Architecture

Чек-лист по сервису

  • Логи пишутся в консоль/stdout в формате json
  • Конфигурация в ЕNV-переменных
  • Миграции для БД
  • Swagger
  • Идемпотетность. Идемпотентным называют такой метод API, повторный вызов которого не меняет состояние. НО: результат идемпотентного вызова может меняться.
  • Кэш
  • Отсутствие состояния - Stateless состояние не внутри сервиса: а в бд, redis.
    • масштабировать непосредственно сервера приложений проще
    • сделать так, чтобы как можно меньше было хранения состояний в самом приложении
    • stateful vs stateless

todo

[Mock, test(https://microcks.io/documentation/getting-started/)

Паттерн повествование, коммуникаций

Кейсы недоступности, ошибок Sla: rps, таймаут время ответа/отклика Чек-лист по сервису Умный HealthCheck