Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB.

1. Архитектура масштабируемых приложений.
Микросервисы, CQRS, ESB.

2. Страница 2
www.sms-a.ru
Монолитные приложения и их проблемы
DB
DAL
Бизнес-логика
UI

3. Страница 3
www.sms-a.ru
Монолитные приложения и их проблемы
DB
DAL
Бизнес-логика
UI
DB
DAL
Бизнес-логика
UI
DAL
Бизнес-логика
UI

4. Страница 4
www.sms-a.ru
Монолитные приложения и их проблемы
Проблемы монолитных приложений:
 Растущая сложность системы при внесении новых
изменений
 Растущая сложность поддержки
 Разобраться трудно — если система переходила из
поколения в поколение, логика забывалась, люди
уходили и приходили, а комментариев и тестов нет
 Мало тестов
 Дорого вносить изменения
 Устаревание технологий

5. Страница 5
www.sms-a.ru
Развитие монолитной системы, куб
масштабирования
X-axis scaling - consists of running multiple copies of an
application behind a load balancer. If there are N copies
then each copy handles 1/N of the load. This is a simple,
commonly used approach of scaling an application.
Y-axis scaling - Unlike X-axis and Z-axis, which consist of
running multiple, identical copies of the application, Y-axis
axis scaling splits the application into multiple, different
services. Each service is responsible for one or more
closely related functions.
Z-axis scaling - When using Z-axis scaling each server
runs an identical copy of the code. In this respect, it’s
similar to X-axis scaling. The big difference is that each
server is responsible for only a subset of the data. Some
component of the system is responsible for routing each
request to the appropriate server.
Шардинг
Зеркалирование
Сервисы

6. Страница 6
www.sms-a.ru
Теорема CAP
Принцип был предложен
профессором Калифорнийского
университета в Беркли Эриком
Брюером в 2000 году

7. Страница 7
www.sms-a.ru
Теорема CAP
CA — consistency + availability
Данные во всех узлах согласованы и доступны. Доступность означает, есть гарантируемый отклик
за предсказуемое время. Это время большим. При этом мы жертвуем разделением на секции — не
можем развернуть 300 таких хостов и распределить всех пользователей по этим хостам. Так
работать система не будет, потому что не будет согласованности транзакций. Яркий пример CA —
ACID-транзакции, присутствующие в классических монолитах.
CP – consistency + partitioning
Данные во всех узлах согласованы и распределены на независимые секции. При этом мы готовы
пожертвовать временем, которое требуется на согласование всех транзакций — отклик будет очень
долгим. Это значит, что, если два пользователя последовательно будут запрашивать одни и те же
данные, неизвестно, как долго будут согласовываться данные для второго пользователя.
Такое поведение характерно для монолитов, которым пришлось масштабироваться, несмотря на
древность.
AP — availability + partitioning
Система доступна с предсказуемым временем отклика и распределена. При этом придется
отказаться от целостности результата — наши данные больше не консистентны в каждый момент
времени, и среди них появляются устаревшие (от микросекунд до дней).
Яркий пример —DNS-системы, которые синхронизируются с задержкой до дней.

8. Страница 8
www.sms-a.ru
Требования ACID – требования к транзакционной
системе
Atomicity — Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут
либо выполнены все её подоперации, либо не выполнено ни одной.
Consistency — Согласованность
Транзакция, достигающая своего нормального завершения и, тем самым, фиксирующая свои
результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция
по определению фиксирует только допустимые результаты. Это условие является необходимым для
поддержки четвёртого свойства.
Isolation — Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её
результат. Изолированность — требование дорогое, поэтому в реальных БД существуют режимы, не
полностью изолирующие транзакцию.
Durability — Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в
оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться
сохранёнными после возвращения системы в работу.

9. Страница 9
www.sms-a.ru
Микросервисы
Микросервисы – это архитектурный шаблон в котором сервисы:
• маленькие – разрабатывается одной командой, содержит
ограниченный набор возможностей
• сфокусированные – решает одну бизнес задачу и решает
ее хорошо, может быть использован отдельно от
остальных сервисов
• слабосвязанные – изменение в одном сервисе не требует
изменения в других
• высокосогласованные – сервис содержит все необходимые
методы для решения задачи

10. Страница 10
www.sms-a.ru
Микросервисы и SOA
Микросервисы – это частный случай SOA.

11. Страница 11
www.sms-a.ru
Характеристики микросервисов
• Разделение на компоненты
• Группировка по бизнес задачам

12. Страница 12
www.sms-a.ru
Характеристики микросервисов
Децентрализованное хранение данных – каждый сервис имеет свою БД

13. Страница 13
www.sms-a.ru
Характеристики микросервисов
• Автоматизация развертывания и мониторинга – непрерывная интеграция и поставка,
мониторинг большого числа сервисов
• Умные сервисы и простые коммуникации – не надо перегружать ESB логикой
• Design for Failure – при разработке исходим из гипотезы, что в сервису могут не ответить, может
не получится отправить или принять сообщение и т.д.

14. Страница 14
www.sms-a.ru
Доступ клиентского приложения к микросервисам
API Gateway – точка входя для взаимодействия клиента со всеми сервисами

15. Страница 15
www.sms-a.ru
Взаимодействие между микросервисами
Варианты взаимодействия
• Service Discovery (RPC Style) — сервисы знают друг о друге и общаются напрямую.
• Message Bus (Event-driven) — взаимодейтвие происходит при помощи ESB сервисы
подписываются на события и генерируют собственные события.
• Hybrid — смешанный вариант, когда для одних случаев применяется RPC, а для других —
message bus.

16. Страница 16
www.sms-a.ru
Взаимодействие между микросервисами
Service Discovery
• Сервис знает адреса других сервисов и
напрямую адресует им сообщения
• Минусы подхода состоят в том, что если
есть несколько экземпляров вызываемого
сервиса, то надо их знать и уметь выбирать
нужный. Так же адреса могут изменяться со
временем.

17. Страница 17
www.sms-a.ru
Взаимодействие между микросервисами
Server-Side Service Discovery
• Сервис не знает адреса других сервисов, запросы отправляются балансировщику
• Балансировщик узнает адрес конечного сервиса у сервиса Service Registry
• Service Registry – реализует справочник

18. Страница 18
www.sms-a.ru
Взаимодействие между микросервисами
Messge Bus
Плюсы
• Message Bus определяет, какая у вас будет
архитектура.
• Позволяет легко добавлять сервисы, сервисы не
знают про другие.
• Message Bus изначально построен так, чтобы все
системы масштабировались.
• Есть готовые решения, которые писали не вы, —
такой код не надо поддерживать, и он хорошо
работает.
Минусы
• Надо описывать message-контракты, которые со
временем могут изменяться и требовать
версионирования.
• Асинхронные взаимодействия.
• Еще один элемент в инфраструктуре.

19. Страница 19
www.sms-a.ru
RabbitMQ – знакомство
Простой пример

20. Страница 20
www.sms-a.ru
RabbitMQ – реализация протокола AMQP
Основные понятия

21. Страница 21
www.sms-a.ru
RabbitMQ – точки обмена
Типы точек обмена

22. Страница 22
www.sms-a.ru
RabbitMQ – пример сервиса
Примеры работы

23. Страница 23
www.sms-a.ru
RabbitMQ – вызов RPC
Примеры работы

24. Страница 24
www.sms-a.ru
Использование шины сообщений
Плюсы
• Масштабирование из коробки – сервисы могут быть размещены на разных серверах в нужном
количестве, отказ одного из сервисов не приведет к отказу системы
• Гарантированная доставка сообщений – при использовании долговечных очередей подписчик
получит сообщение, даже если будут проблемы с сетью
• Надежность – сторонне ПО, которое используется в
высоконагруженных приложениях по всему миру
• Сообщество – все возможные вопросы заданы
Минусы
• Дополнительный компонент в системе
• Обучение разработчиков

25. Страница 25
www.sms-a.ru
Пример работы с RabbitMq - демонсрация

26. Страница 26
www.sms-a.ru
Паттерн CQRS
Command-query separation (CQS) или command-query responsibility
segregation (CQRS)
Методы объекта нужно разделить на:
1. Queries - возвращают результат, не изменяя состояние объекта.
2. Commands - изменяют состояние, не возвращая значение.

27. Страница 27
www.sms-a.ru
Паттерн CQRS
Было

28. Страница 28
www.sms-a.ru
Паттерн CQRS
Стало

29. Страница 29
www.sms-a.ru
Паттерн CQRS
Команда

30. Страница 30
www.sms-a.ru
Паттерн CQRS
Запрос

31. Страница 31
www.sms-a.ru
Паттерн CQRS
Потоки данных в монолитной архитектуре

32. Страница 32
www.sms-a.ru
Паттерн CQRS – модификация репозитория

33. Страница 33
www.sms-a.ru
Паттерн CQRS – модификация репозитория

34. Страница 34
www.sms-a.ru
Паттерн CQRS – модификация репозитория

35. Страница 35
www.sms-a.ru
Паттерн CQRS – модификация репозитория

36. Страница 36
www.sms-a.ru
Паттерн CQRS – модификация репозитория
Отдельный класс из метода

37. Страница 37
www.sms-a.ru
Паттерн CQRS – модификация репозитория
Маленькие объекты
• Меньше зависимостей в каждом классе
• SRP
• Проще заменить
• Проще тестировать
• Делают дизайн кода однотипным
• При расширении функциональности системы сложность увеличивается
(почти) линейно

38. Страница 38
www.sms-a.ru
Микросервисы – за и против
Преимущества
Модульное деление
Разбиение задач по сервисам даст
возможность компоновки приложения.
Высокая доступность
Сервисы могут работать не все — при этом
все остальное будет работать.
Разнообразие технологий
Возможность использовать правильный
инструмент.
Масштабирование и независимое
развертывание
Из-за слабой связанности микросервисы
проще разворачивать, и меньше
вероятность отказа системы.
Недостатки
Сложность разработки и отладки
Вместо одного монолита надо поднимать несколько
приложений – микросервисов.
Конечная согласованность
Из за распределенных потоков данных может
возникнуть сложность отслеживания транзакций.
Сложность операционной поддержки
Нужны грамотные DevOps-инженеры, непрерывное
развертывание и автоматический мониторинг.

39. Страница 39
www.sms-a.ru
Логические микросервисы
• Микросервисный подход можно применить при проектировании приложения
• Достаточно изолировать модули друг от друга, включая доменную модель и хранилище данных
• Если говорить в терминах .NET, то возможно разворачивать сервисы в рамках одного домена
приложения или в рамках одного IIS сервера.
• Взаимодействие между изолированными модулями, может происходить через оперативную
память, либо через REST запросы к локальному серверу приложений.

40. Страница 40
www.sms-a.ru
Демонстрация
Примеры
• https://github.com/treshnikov/cqrs_esb_infrastructure

41. Страница 41
www.sms-a.ru
Event Sourcing
Event Sourcing – архитектурный паттерн.

42. Страница 42
www.sms-a.ru
Источники
• http://www.dataart.ru/blog/2016/03/microservices-kak-pravil-no-delat-i-kogda-primenyat/
• http://blog.byndyu.ru/2014/07/command-and-query-responsibility.html
• https://www.cloudamqp.com/blog/2015-05-18-part1-rabbitmq-for-beginners-what-is-
rabbitmq.html
• https://www.nginx.com/blog/
• https://www.nginx.com/blog/introduction-to-microservices/
• https://www.nginx.com/blog/building-microservices-inter-process-communication/
• http://plainoldobjects.com/presentations/decomposing-applications-for-deployability-and-
scalability/
• http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-
integration-usi.html
• https://lostechies.com/gabrielschenker/2016/01/27/service-discovery/
• http://microservices.io/
• http://martinfowler.com/articles/microservices.html

43. Страница 43
www.sms-a.ru
Спасибо за внимание!
Презентацию подготовил Трешников П.В.
Начальник отдела прикладного программного обеспечения
ГК СМС-Автоматизация
email: pavel.treshnikov@sms-a.ru