База знаний Антона Сидорова
База знаний по аналитике, ИТ архитектуре, API. Документирование. Тесты инструментов.
Project maintained by daemon110282
Hosted on GitHub Pages — Theme by mattgraham
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
- eShopOnContainers
- About
Microservices on .Net platforms which used Asp.Net Web API, Docker, RabbitMQ, MassTransit, Grpc, Ocelot API Gateway, MongoDB, Redis, PostgreSQL, SqlServer, Dapper, Entity Framework Core, CQRS and Clean Architecture implementation.
- ДБО (СДО)
Чек-лист по сервису
- Логи пишутся в консоль/stdout в формате json
- Конфигурация в ЕNV-переменных
- Миграции для БД
- Swagger
- Идемпотетность. Идемпотентным называют такой метод API, повторный вызов которого не меняет состояние. НО: результат идемпотентного вызова может меняться.
- Кэш
- Отсутствие состояния - Stateless состояние не внутри сервиса: а в бд, redis.
- масштабировать непосредственно сервера приложений проще
- сделать так, чтобы как можно меньше было хранения состояний в самом приложении
- stateful vs stateless
todo
[Mock, test(https://microcks.io/documentation/getting-started/)
Паттерн повествование, коммуникаций
Кейсы недоступности, ошибок
Sla: rps, таймаут время ответа/отклика
Чек-лист по сервису
Умный HealthCheck