2. Вячеслав Бенедичук
Менеджер с большим техническим опытом и опытом управления продуктами.
Опыт в ИТ 15 лет.
Опыт управления проектами и продуктами 9+ лет.
Максимальная команда 25 человек.
Самый большой проект более 15 человеко-лет
https://ru.linkedin.com/in/vbenedichuk
5. История развития
Приложение Business logic DTO
DAL
UI
Сервис
Сервис
Сервис
Сервис
Сервис
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
6. Предпосылки появления
Рост сложности логики приложений
•Увеличение сложности решаемых задач и рост объема кода
•Усложнение логики взаимодействия между слоями приложения
•Больше коммуникаций между разработчиками
•Необходимость тестирования более сложных сценариев
Рост объемов данных требующих обработки
•Классические приложения требуют много ресурсов в одном физическом узле и сложны для горизонтального
масштабирования
•Дефект в одной из частей приложения часто приводит к выходу из строя всего приложения
Нестабильность потоков данных
•Активность пользователей в соцсетях варьируется в зависимости от времени суток
•Активность покупателей в онлайн магазине варьируется в зависимости от времени суток и времени года
•Железо купленное под пиковые нагрузки большую часть времени используется неэффективно
•Железо купленное под средние нагрузки может не справляться с пиками
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
7. Решение
Построение приложения из набора маленьких (50-300
строк кода) слабо связанных модулей.
• Каждый микросервис работает независимо
• Обмен между сообщениями происходит с использованием
стандартных сообщений
• Связь между сервисами осуществляется через очереди сообщений.
Могут использоваться и иные способы обмена (например обычные
REST сервисы), однако очереди сообщений повышают общую
стабильность системы.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
8. Преимущества
Обзор
Отказоустойчивость Масштабируемость
Простота оценки
производительности
и оптимизации
стоимости владения
Простота разработки
Обновление системы
не требует ее
остановки
Упрощение A/B
тестирования и
регрессионного
тестирования
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
9. Преимущества
Отказоустойчивость
Число единых точек отказа
минимально, либо их нет.
Выход из строя одного
экземпляра сервиса или одного
из узлов не приводит к отказу
всей системы. Краткосрочно
влияет только на
производительность.
Service 1
SaaS очередь
Service 2
Service 3 Service 3
SaaS очередь
Service 2 Service 2
Service 1 Service 1
Service 3
SaaS база данных
Отказоустойчивость
10. Преимущества
Масштабируемость
Масштабируемость
Локальные пики нагрузки (секунды)
сглаживаются очередями сообщений.
Снижается время реакции на
отдельный запрос, однако не
происходит отказа в обслуживании.
Глобальные пики нагрузки (десятки
секунд и больше) сглаживаются
запуском новых экземпляров
сервисов требующих большей
пропускной способность.
Отказоустойчивость при DDoS атаках
огранична только объемом
финансирования доступного для
поддержки инфраструктуры.
Service 1
SaaS очередь
Service 2
Service 3 Service 3
SaaS очередь
Service 1 Service 1
Service 3
SaaS база данных
В очереди 5
сообщений
В очереди 100500
сообщений
Service 3
(запускается)
Service 2 (выключается)
Service 3
(запускается)Service 3
(запускается)
11. Преимущества
Простота оценки производительности и оптимизации стоимости владения
Простота оценки
производительности
Максимальная нагрузочная способность каждого
отдельного сервиса может быть измерена
независимо.
На основании “лабораторных” измерений
производительности и прогнозируемой входной
нагрузки может быть построена оптимальная
топология сети обработки и определена
минимальня стоимось владения.
Различные комбинации инфраструктурных
решений могут сравниваться на основе
фактических цифр а не “на глазок”.
Обычно, вложения в инфраструктуру растут не
скачками а пропорционально с ростом бизнеса.
Можно произвольно распределять части
системы между in-house и cloud датацентрами.
SaaS
очередь
Service 2
Измеренная производительность
300 сообщений в секунду.
SaaS
очередь
Тестовый поток
Накопили 100500000 сообщений
Через 1 час 1080000 сообщений
При
минимально
м потоке 450
сообщений в
секунду с
часовыми
пиками до
1500
требуется 2
экземпляра
pre-paid (или
in house) и
до 3-4-х on-
demand.
12. Преимущества
Простота разработки
Простота разработки
Код микросервисов прост в
подержке за счет малого
размера.
Независимость микросервисов
позволяет использовать в
рамках одной системы
микросервисы построенные на
разых платформах и с
использованием разных
технологических стеков, без
накладных расходов на
интеграцию.
Service 1 (php)
SaaS очередь
Service 2 (c#)
Service 3 (Java) Service 3 (Java)
SaaS очередь
Service 2 (c#)
Service 1 (php)
SaaS база данных
100 Строк кода
vs
1000 Строк кода
13. Преимущества
Обновление системы не требует ее остановки
Новая версия системы может
запускаться путем
последовательной замены
части микросервисов.
Старая и новая версия системы
могут работать параллельно.
SaaS очередь
(накопленные данные)
Service 2 V1
Service 3 V1
SaaS очередь
Service 2 V1 Service 2 V2
Service 1 V2
SaaS база данных
Обновление системы не требует
остановки
Service 3 V1
SaaS очередь
Service 3 V1
14. Преимущества
Упрощение A/B тестирования и регрессионного тестирования
Для A/B тестирования отдельных
микросервисов, они могут
работать параллельно. Часть
запросов обрабатывается новой
версией, в то время как основной
поток обработки идет сквозь
старую.
Для регрессионного
тестирования можно запустить
тестируемый модуль
параллельно существующему в
Production окружении и
сравнивать результаты их работы.
Service 1 V1
Service 2 V1 Service 2 V2
Service 1 V2Упрощение A/B тестирования и
регрессионного тестирования
Comparator
SaaS очередь
SaaS очередь
Duplicator
15. Недостатки
Сложность первичного развертывания
• Каждый микросервис имеет отдельный инсталлятор. Ручное развертывание больших систем
требует значительного времени. Должно решаться автоматизированным развертыванием.
Например с помощью Docker.
Сложность ручного обновления
• Много мелких сервисов распределенных по разным физическим устройствам или датацентрам
требуют автоматизации обновлений.
Дополнительные трудозатраты на мониторинг
• По умолчанию, единый лог событий/ошибок отсутствует. Нужно использовать промышленные
решения, например Zabbix. Это может потребовать дополнительных трудозатрат программиста
на передачу показателей.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
16. Примеры систем
Финансовый сектор. Оценка кредитоспособности клиента.
За счет масштабов бизнеса высокий поток заявок.
Процесс оценки многоступенчатый.
Система состоит из нескольких независимых рабочих мест.
Система делает большое число длительных запросов во внешние системы (БКИ).
Процесс оценки регулярно меняется.
В системе параллельно может функционировать несколько процессов.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
17. Примеры систем
SMM. Портрет аудитории.
Огромный поток сообщений. (миллионы сообщений в сутки).
Активность пользователей циклично меняется в течение суток.
Каждое сообщени влияет на несколько показателей, которые вычисляются независимо.
Каждое сообщение должно быть учтено в статистике.
Статистика должна формироваться в реальном времени.
Требуются дополительные длительные запросы к источникам для получения информации по
ссылкам.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
18. Примеры систем
Online продажа авиабилетов. Обработка заказов.
Большое количество пользователей.
Активность пользователей циклично меняется в течение суток.
Количество пользователей велико, но количество билетов ограничено, нужно избежать ситаций,
когда продано билетов больше, чем есть в наличии.
Есть много независимых каналов продаж, поэтому точная информация о наличии билетов есть
только у поставщика услуги.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
19. Рекомендации по реализации
Удобно иметь один формат сообщения проходящий через все сервсы, даже если каждый
сервис будет работать только счастью общего пакета. Это позволить легко добавлять новые
сервисы и расширять функции существующих
Обработку данных и сохранение результата в персистентное хранилище лучше разнести в
отдельные микросервисы.
Если в системе присутствует рабочее место требующее интерактивной работы пользователя с
данными, объем информации в его оперативном хранилище имеет смысл минимизировать.
Если данные могут потребоваться вновь, можно сохранять их в архив и извлекать по
необходимости.
При использовании XaaS инфраструктур обязательно нужно рассчитывать стоимость
эксплуатации как самих микросервисов так и сопутствующей инфраструктуры (очереди,
хранилища и т.д.). Архитектурная чистота не должна превалировать над экономикой
финального решения. Иногда имеет смысл объединить сервисы для снижения
инфраструктурных расходов.
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы
20. Связанные шаблоны проектирования
CQRS (Command and Query Responsibility Separation)
Event Sourcing
Key-Value storage
NoSQL
Memory Cache
История развития
Предпосыли
появления
(проблемы)
Решение Преимущетсва Недостатки Примеры систем
Рекомендации по
реализации
Связанные
шаблоны
проектирования
Вопросы