Потоковая обработка данных и Микросервисная...

Вячеслав Бенедичук Менеджер с большим техническим опытом и опытом управления продуктами.

Создал первое коммерческое приложение в 15 лет.

Опыт в ИТ 20 лет.

Опыт управления проектами и продуктами 9+ лет.

Максимальная команда 25 человек.

Самый большой проект более 15 человеко-лет

https://ru.linkedin.com/in/vbenedichuk

https://ru.linkedin.com/in/vbenedichuk

План презентации

История развитияПредпосыли появления

(проблемы)Решение Преимущетсва Недостатки Примеры систем Рекомендации по

реализации

Связанные шаблоны

проектированияВопросы

История развития

История развития

Приложение Business logic DTO

DAL

UIСервис

СервисСервис

Сервис

Сервис

История развитияПредпосыли появления (проблемы)

Решение Преимущетсва Недостатки Примеры систем Рекомендации по реализации

Связанные шаблоны

проектированияВопросы

Предпосылки появления Рост сложности логики приложений

• Увеличение сложности решаемых задач и рост объема кода• Усложнение логики взаимодействия между слоями приложения• Больше коммуникаций между разработчиками• Необходимость тестирования более сложных сценариев

Рост объемов данных требующих обработки

• Классические приложения требуют много ресурсов в одном физическом узле и сложны для горизонтального масштабирования• Дефект в одной из частей приложения часто приводит к выходу из строя всего приложения

Нестабильность потоков данных

• Активность пользователей в соцсетях варьируется в зависимости от времени суток• Активность покупателей в онлайн магазине варьируется в зависимости от времени суток и времени года• Железо купленное под пиковые нагрузки большую часть времени используется неэффективно• Железо купленное под средние нагрузки может не справляться с пиками

История

развития

Предпосыли появления (проблемы)

Решение

Преи

мущетсва

Недостатки

При

меры систем

Рекомендации

по реализации

Связанные

шаблоны проектирования

Вопросы

Решение

Построение приложения из набора маленьких (50-300 строк кода) слабо связанных модулей.

• Каждый микросервис работает независимо• Обмен между сообщениями происходит с использованием стандартных сообщений• Связь между сервисами осуществляется через очереди сообщений. Могут использоваться и иные способы

обмена (например обычные REST сервисы), однако очереди сообщений повышают общую стабильность системы.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

ПреимуществаОбзор

Отказоустойчивость

Масштабируемость

Простота оценки производительности

и оптимизации стоимости владения

Простота разработки

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

ПреимуществаОтказоустойчивость

Число единых точек отказа минимально, либо их нет. Выход из строя одного экземпляра сервиса или одного из узлов не приводит к отказу всей системы. Краткосрочно влияет только на производительность.

Service 1

SaaS очередь

Service 2

Service 3 Service 3

SaaS очередь

Service 2 Service 2

Service 1 Service 1

Service 3

SaaS база данных

Отказоустойчивость

ПреимуществаМасштабируемость

Масштабируемость

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

Глобальные пики нагрузки (десятки секунд и больше) сглаживаются запуском новых экземпляров сервисов требующих большей пропускной способность.

Отказоустойчивость при DDoS атаках огранична только объемом финансирования доступного для поддержки инфраструктуры.

Service 1

SaaS очередь

Service 2

Service 3 Service 3

SaaS очередь

Service 1 Service 1

Service 3


В очереди 5 сообщений

В очереди 100500 сообщений

Service 3(запускается)

Service 2 (выключается)

Service 3(запускается)Service 3

(запускается)

ПреимуществаПростота оценки производительности и оптимизации стоимости владения

Простота оценки производительности

Максимальная нагрузочная способность каждого отдельного сервиса может быть измерена независимо.

На основании “лабораторных” измерений производительности и прогнозируемой входной нагрузки может быть построена оптимальная топология сети обработки и определена минимальня стоимось владения.

Различные комбинации инфраструктурных решений могут сравниваться на основе фактических цифр а не “на глазок”.

Обычно, вложения в инфраструктуру растут не скачками а пропорционально с ростом бизнеса.

Можно произвольно распределять части системы между in-house и cloud датацентрами.

SaaS очередь

Service 2 Измеренная производительность 300 сообщений в секунду.

SaaS очередь

Тестовый поток

Накопили 100500000 сообщений

Через 1 час 1080000 сообщений

При минимальном потоке 450 сообщений в

секунду с часовыми пиками до

1500 требуется 2 экземпляра

pre-paid (или in house) и до 3-4-х on-

demand.

ПреимуществаПростота разработки

Простота разработки

Код микросервисов прост в подержке за счет малого размера.

Независимость микросервисов позволяет использовать в рамках одной системы микросервисы построенные на разых платформах и с использованием разных технологических стеков, без накладных расходов на интеграцию.

Service 1 (php)

SaaS очередь

Service 2 (c#)

Service 3 (Java) Service 3 (Java)

SaaS очередь

Service 2 (c#)

Service 1 (php)


100 Строк кодаvs

1000 Строк кода

ПреимуществаОбновление системы не требует ее остановки

Новая версия системы может запускаться путем последовательной замены части микросервисов.

Старая и новая версия системы могут работать параллельно.

SaaS очередь (накопленные данные)

Service 2 V1

Service 3 V1

SaaS очередь

Service 2 V1 Service 2 V2

Service 1 V2


Обновление системы не требует остановки

Service 3 V1

SaaS очередь

Service 3 V1

ПреимуществаУпрощение A/B тестирования и регрессионного тестирования

Для A/B тестирования отдельных микросервисов, они могут работать параллельно. Часть запросов обрабатывается новой версией, в то время как основной поток обработки идет сквозь старую.

Для регрессионного тестирования можно запустить тестируемый модуль параллельно существующему в Production окружении и сравнивать результаты их работы.

Service 1 V1

Service 2 V1 Service 2 V2

Service 1 V2Упрощение A/B тестирования и регрессионного тестирования

Comparator

SaaS очередь

SaaS очередь

Duplicator

НедостаткиСложность первичного развертывания

• Каждый микросервис имеет отдельный инсталлятор. Ручное развертывание больших систем требует значительного времени. Должно решаться автоматизированным развертыванием. Например с помощью Docker.

Сложность ручного обновления

• Много мелких сервисов распределенных по разным физическим устройствам или датацентрам требуют автоматизации обновлений.

Дополнительные трудозатраты на мониторинг

• По умолчанию, единый лог событий/ошибок отсутствует. Нужно использовать промышленные решения, например Zabbix. Это может потребовать дополнительных трудозатрат программиста на передачу показателей.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Примеры системФинансовый сектор. Оценка кредитоспособности клиента.

За счет масштабов бизнеса высокий поток заявок.Процесс оценки многоступенчатый.Система состоит из нескольких независимых рабочих мест.Система делает большое число длительных запросов во внешние системы (БКИ).Процесс оценки регулярно меняется.В системе параллельно может функционировать несколько процессов.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Примеры системSMM. Портрет аудитории.

Огромный поток сообщений. (миллионы сообщений в сутки).Активность пользователей циклично меняется в течение суток.Каждое сообщени влияет на несколько показателей, которые вычисляются независимо.Каждое сообщение должно быть учтено в статистике.Статистика должна формироваться в реальном времени.Требуются дополительные длительные запросы к источникам для получения информации по ссылкам.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Примеры системOnline продажа авиабилетов. Обработка заказов.

Большое количество пользователей. Активность пользователей циклично меняется в течение суток.Количество пользователей велико, но количество билетов ограничено, нужно избежать ситаций, когда продано билетов больше, чем есть в наличии.Есть много независимых каналов продаж, поэтому точная информация о наличии билетов есть только у поставщика услуги.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Рекомендации по реализации Удобно иметь один формат сообщения проходящий через все сервсы, даже если каждый сервис будет работать только счастью общего пакета. Это позволить легко добавлять новые сервисы и расширять функции существующих

Обработку данных и сохранение результата в персистентное хранилище лучше разнести в отдельные микросервисы.

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

При использовании XaaS инфраструктур обязательно нужно рассчитывать стоимость эксплуатации как самих микросервисов так и сопутствующей инфраструктуры (очереди, хранилища и т.д.). Архитектурная чистота не должна превалировать над экономикой финального решения. Иногда имеет смысл объединить сервисы для снижения инфраструктурных расходов.

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Связанные шаблоны проектирования

CQRS (Command and Query Responsibility Separation)

Event Sourcing

Key-Value storage

NoSQL

Memory Cache

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Вопросы?

История

развития


Решение

Преи

мущетсва


При




Связанные


Вопросы

Потоковая обработка данных и Микросервисная...

Software