Монолит vs Микросервисы

1.

Монолит vs Микросервисы
astondevs.ru

2.

3.

Монолит
Монолитная архитектура — это традиционная модель разработки программного
обеспечения, в которой одна база кода используется для выполнения нескольких бизнесфункций. Все программные компоненты монолитной системы взаимозависимы из-за
использования встроенных механизмов обмена данными внутри системы.
Монолитные приложения работают достаточно эффективно до тех пор, пока они не
становятся слишком большими и не вызывают проблем с масштабированием.

4.

Микросевисы
Микросервисная архитектура (или просто «микросервисы») представляет собой метод
организации архитектуры, основанный на ряде независимо развертываемых служб. У этих
служб есть собственная бизнес-логика и база данных с конкретной целью. Обновление,
тестирование, развертывание и масштабирование выполняются внутри каждой службы.
Микросервисы разбивают крупные задачи, характерные для конкретного бизнеса, на
несколько независимых баз кода.

5.

6.

Плюсы монолитов
1.
Нет огромного количества интеграций. Чтобы вызвать какой-то сервис, достаточно дернуть метод.
2.
Выше производительность - в централизованной базе кода и репозитории один интерфейс API часто
может выполнять ту функцию, которую при работе с микросервисами выполняют многочисленные API.
3.
Простое развертывание. Использование одного исполняемого файла или каталога упрощает
развертывание. Но не локально.
4.
Удобная отладка. Весь код находится в одном месте, благодаря чему становится легче выполнять
запросы и находить проблемы.
5.
Тестирование — проще проводить приемочное тестирование, т.к. монолит проще поднять нежели 10ки микросервисов.

7.

Минусы монолитов
1.
Горизонтальное масштабирование – если часть сервисов в монолите будут очень популярными и один
инстанс перестанет справляться, то нам придется поднимать второй, это не эффективное
распределение ресурсов.
2.
Отказоустойчивость – если упадет монолит, то упадет все.
3.
Единая кодовая база – различные языки лучше подходят под различные операции.
4.
Порог вхождения разработчиков выше, чем в микросервисной архитектуре т.к. требуется больше
времени на изучение большой кодовой базы монолита, в случае микросервиса разработчик может
разобраться за 1 – 2 дня.
5.
Препятствия для внедрения технологий. Любые изменения в инфраструктуре или языке разработки
влияют на приложение целиком, что зачастую приводит к увеличению стоимости и временных затрат.
6.
Развертывание. При внесении небольшого изменения потребуется повторное развертывание всего
монолитного приложения.

8.

Минусы монолитов
1.
Локальное развертывание — монолиты тяжело разворачивать и программировать локально. Чтобы
поднять монолит, может не хватить 16 ГБ ОЗУ. Приходится искать хаки или что-то выключать.
Круто, что в разработке монолита можно проваливаться в классы, смотреть реализацию интерфейса.
Но неприятен тот момент, когда монолит перестает запускаться на твоей локальной тачке, и ты через
боль начинаешь его программировать.
2.
Тестирование — т.к. много тестов, всё медленно запускается. Другая часть проблемы — тестировать
сложно, потому что большая связность всех компонентов, т.е. сложно тестировать отдельные
интеграции, т.к. все зависят друг от друга.

9.

Плюсы микросервисов
1.
Масштабируемость - когда микросервис достигает предельной нагрузки, можно быстро выполнить
развертывание новых экземпляров данной службы и снизить нагрузку.
2.
Отказоустойчивость – если упал какой-нибудь сервис, остальные продолжат работать.
3.
Различные микросервисы можно писать при помощи различных языков.
4.
Непрерывное развертывание – проще внедрять частые развертывания (несколько раз в день).
5.
Независимое развертывание. Микросервисы представляют собой отдельные модули, поэтому с ними
можно легко и быстро выполнять независимое развертывание отдельных функций.
6.
Ниже порог вхождения разработчиков.
7.
Проще проводить тестирование. Юнит/интеграционные тесты быстро отрабатывают. Плюс всегда
можно локально поднять микросервис и посмотреть как он работает.

10.

Минусы микросервисов
1.
Распределенные данные - при использовании микросервисов, данные распределены между
сервисами и если нам нужно будет их собрать, придется идти во все сервисы.
2.
Все что касается интеграций между сервисами – боль (поддержание контрактов, что делать если сервис
не доступен, сеть не надежная, нужно как-то поддерживать транзакции)
3.
Согласованность контрактов – множество сервисов должны как-то общаться. Для нормального
взаимодействия между сервисами используются общие контракты – json документы описывающие
формат дто, на основе которых обычно генерируются конкретные классы.
Возможен кейс, когда всё согласовали, всё работает, а потом в одном из сервисов сторонняя команда
взяла и что-то изменила. И теперь нужно пройтись по всем сервисам и всё обновить.
4.
Транзакции – как обеспечить транзакционность между множеством сервисов(адовый ад).
5.
Инфраструктура – кто-то должен настраивать и поддерживать инфраструктуры (Кубернет,
контейнеризация и тд)
6.
Мониторинг – мониторить микросервисы сложнее, например логи в монолите идут в одно место и у
нас есть прямой и простой способ их увидеть. В микросервисах множество доменов, каждый из
которых откидывает логи/метрики и для централизованного доступа к ним нужны инструменты (ELK
стек).

11.

12.

Выводы
В каждом из подходов есть как плюсы, так и минусы, поэтому нужно отталкиваться от ситуации.
1.
Если нужно быстро протестировать какую-нибудь идею и проверить, будет ли она пользоваться
успехом - вполне подходит монолит.
2.
Если вы работаете в большой компании и есть четкие требования какой функционал нужно
реализовать, в таком случае можно сразу начинать с микросервисов.

13.

14.

Database per service
Основная рекомендация при переходе на микросервисы — предоставить каждому сервису собственное
хранилище данных, чтобы не было сильных зависимостей на уровне данных. При этом имеется в виду
именно логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же
физическую базу данных, но в ней они должны взаимодействовать с отдельной схемой, коллекцией или
таблицей.
Основанный на этих принципах паттерн Database Per Service повышает автономность микросервисов и
уменьшает связь между командами, разрабатывающими отдельные сервисы.
У паттерна есть и недостатки: усложняется обмен данными между сервисами и предоставление
транзакционных гарантий ACID.

15.

API Gateway
Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после
применения к ним паттерна Database Per Service. Он предлагает создать отдельное API, которое будет
вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них
результатов в памяти.

16.

Транзакции
A distributed transaction is a very complex process with a lot of moving parts that can fail. Also, if these parts
run on different machines or even in different data centers, the process of committing a transaction could
become very long and unreliable.
This could seriously affect the user experience and overall system bandwidth. So one of the best ways to solve
the problem of distributed transactions is to avoid them completely.
Usually, a microservice is designed in such way as to be independent and useful on its own. It should be able to
solve some atomic business task.
К сожалению, возможна ситуация, когда все таки придется обеспечивать распределенные транзакции.
На пример, есть приложение, к которому применялся паттерн Database per Service. Теперь у каждого
сервиса приложения есть своя собственная база данных. Некоторые бизнес транзакции охватывают сразу
несколько сервисов, так что нужен механизм, обеспечивающий согласованность данных между этими
сервисами.

17.

Вопрос на 1 балл
Как обеспечить транзакционность между сервисами?

18.

Saga
Один из вариантов обеспечения транзакционности – паттерн Сага.
Сага представляет собой набор локальных транзакций. Каждая локальная транзакция обновляет базу
данных и публикует сообщение или событие, инициируя следующую локальную транзакцию в саге. Если
транзакция завершилась неудачей, например, из-за нарушения бизнес правил, тогда сага запускает
компенсирующие транзакции, которые откатывают изменения, сделанные предшествующими локальными
транзакциями.
Существует два способа координации саг:
1.
Хореография (Choreography) — каждая транзакция публикует события, которые запускают транзакции в
других сервисах.
2.
Оркестровка (Orchestration) — оркестратор говорит участникам, какие транзакции должны быть
запущены.

19.

Хореография
Хореография — это способ координации саг, где участники обмениваются событиями без централизованной
точки контроля. С помощью хореографии каждая локальная транзакция публикует события домена, которые
запускают локальные транзакции в других службах.

20.

Хореография
Преимущества
1.
Хорошо подходит для простых рабочих процессов, требующих нескольких участников и не требующих
логики координации.
2.
Не требует дополнительной реализации и обслуживания службы.
3.
Не представляет ни одной точки неудачи, так как обязанности распределяются между участниками
саги.
Недостатки
1.
Рабочий процесс может запутаться при добавлении новых шагов, так как сложно отследить, какие
участники саги слушают какие команды.
2.
Существует риск циклической зависимости между участниками саги, так как им приходится потреблять
команды друг друга.
3.
Тестирование интеграции сложно, так как для имитации транзакции должны выполняться все службы.

21.

Оркестрация
Оркестрация — это способ координации саг, где централизованный контроллер сообщает участникам саги,
какие локальные транзакции следует выполнять. Оркестратор saga обрабатывает все транзакции и сообщает
участникам, какие операции следует выполнить на основе событий. Оркестратор выполняет запросы saga,
сохраняет и интерпретирует состояния каждой задачи, а также обрабатывает восстановление сбоев с
компенсирующими транзакциями.

22.

Оркестрация
Преимущества
1.
Хорошо подходит для сложных рабочих процессов с участием большого количества участников или
новых участников, добавленных с течением времени.
2.
Подходит, когда есть контроль над каждым участником процесса и контроль над потоком действий.
3.
Не вводит циклических зависимостей, так как оркестратор в одностороннем порядке зависит от
участников саги.
4.
Участникам Saga не нужно знать о командах для других участников. Четкое разделение задач упрощает
бизнес-логику.
Недостатки
1.
Для дополнительной сложности проектирования требуется реализация логики координации.
2.
Существует дополнительная точка сбоя, так как оркестратор управляет полным рабочим процессом.

23.

Ссылки
1.
https://vc.ru/u/1389654-machine-learning/617047-8-shablonov-proektirovaniya-mikroservisov-dlya-opytnyhrazrabotchikov - 8 основных паттернов, которые стоит знать
2.
https://mcs.mail.ru/blog/26-osnovnyh-patternov-mikroservisnoj-razrabotki - 26 паттернов микросервисов,
изучать сразу все – бессмысленно, можно рассматривать, как задел на будущее.