software craftsmanship, system integration, message bus, queues, latency, throughput

1. Software Craftsmanship
meetup #4
Интеграция систем и очереди
сообщений
Павел Вейник
CTO @ Splitmetrics
CEO @ Hard & Soft Skills

2. Зачем митапы?
Поделиться с разработчиками Splitmetrics
Поделиться со всеми разработчиками
Обкатать новый курс для техлидов
Пообщаться

3. Для кого митапы?
Для разработчиков
Для тестировщиков
Для сочувствующих и интересующихся

4. Мы на новом месте
Зарегистрировались 89 человек
И на этот раз есть место для всех

5. Кто проводит митапы
Компания Splitmetrics
35 человек, все в офисе в Минске
2 продукта в области рекламы, 5 лет
Продажи SaaS из РБ на запад
Python, pg, Kafka, RabbitMq, Celery…

6. Кто проводит митапы

7. План митапов
1. Software Craftsmanship & Agile.
Как не делать говно?
2. Принципы хранения данных
3. Обзор баз данных
4. Очереди сообщений
5. Кэши и файловые хранилища

8. Software Craftsmanship
 Working software over
comprehensive documentation
 Responding to change over
following a plan
 Individuals and interactions
over processes and tools
 Customer collaboration over
contract negotiation
 Not only working software, but
also well-crafted software
 Not only responding to change,
but also steadily adding value
 Not only individuals and
interactions, but also a
community of professionals
 Not only customer collaboration,
but also productive
partnerships

9. Давай практику!
Запросы на «практические задачи»
Заканчиваются повторением ошибок, которые
пройдены уже лет 30-50 назад
И развитие останавливается
Знание одного принципа освобождает от
знания тысячи фактов

10. План этого митапа
1. Интеграция систем
2. Очереди сообщений
3. Производительность и детали
4. Задачки на архитектуру

11. Проблемы интеграции
Ненадежные сети
Медленные сети
Все приложения
разные
Изменения
неизбежны
Много верных
решений
Что верно, понятно
через много месяцев
Нет четких правил

12. Синхронные архитектуры интеграции

13. Синхронные децентрализованные
Прямолинейно – кому надо тот и вызывает
Не подходит для сложных потоков данных
Не подходит для часто изменяемых систем
Неудобно для highload

15. Синхронные оркестрированные
последовательные
Более гибкое управление – все на
оркестраторе
Грузит оркестратор, одна точка отказа
Подходит для системы с highload чтением

17. Синхронные оркестрированные
параллельные
Более эффективно, меньше время ответа
Сложнее управлять оркестрацией
Больше пропускная способность
Подходит для highload чтения

18. Недостатки синхронных подходов
 Отдельное управление мощностью каждого сервиса
 Возможны каскадные падения, эффект домино
 Сложнее балансировать
 Сложнее service discovery
 Высокая связность
Каждый знает API каждого
Трудно с версиями

19. Асинхронные архитектуры интеграции

20. Асинхронные choreographed события
 Каждый компонент в ответ шлет новое событие, которое
принимает следующий компонент
 Все еще сильная связность компонентов
 Хорошо для явных действий, таких как индексирование,
оповещения, обработка ошибок
 Хорошо масштабируется
 Трудно управлять потоком обработки
 Удобно для highload записи

22. Последовательные оркестрованные
асинхронные события
Одна точка отказа
Легко менять поток обработки
Хорошо для highload записи
Низкая связность, все только в оркестраторе

23. Гибридные с оркестрацией и хореографией
Оркестрация хороша для явного управления
потоком
Хореография прячет некоторые компоненты от
оркестратора

24. Недостатки асихронных архитектур
Вся система сложнее
Нужны асинхронные обертки для синхронных
потребителей сообщений

25. Недостатки асихронных архитектур
Оптимизация или только для чтения, или
только для записи для систем среднего
размера
Одна точка отказа
Eventual consistency – можем прочитать не
последние данные

26. Service Oriented Architecture SOA
 Основана на сервисах, отражающих бизнес-задачи
 Использует оркестрацию
 Высокие требования к инфраструктуре
 Реализация сервисов зависит от инфраструктуры, сервисы без
контекста не имеют смысла
 Требуют строгости при реализации

27. Message Oriented Middleware MOM
 Шлем сообщения между распределенными системами
 Системы могут быть на разных технологиях, платформах
 Уменьшает сложность разработки
 Позволяют независимую разработку систем-участниц

28. Преимущества MOM
Хранить сообщения в буфере
Управлять потоком сообщений
Преобразовывать сообщения

29. Преимущества MOM – асинхронность
Если получатель или отправитель оффлайн –
все остальное работает
Бэкап сообщений
Падение одного не влияет на остальных
Получается низкая связность

30. Преимущества MOM – перенаправление
сообщений
Послать сообщение всем клиентам broadcast
Некоторым клиентам – multicast
И более сложные схемы направления
сообщений в зависимости от их содержания
или других параметров

31. Преимущества MOM – преобразование
сообщений
Возможно преобразование сообщения в
процессе передачи
Можно работать с разными форматами
данных, не меняя компоненты, преобразуя на
лету
Ниже связность между компонентами

32. Недостатки MOM
+1 компонент
Нужен дополнительный агент, которые
получает, передает, хранит, преобразовывает
сообщения
Компоненту нужна инфраструктура,
поддержка, конфигурирование, мониторинг
Система в целом сложнее

33. Недостатки MOM – проблемы с
синхронностью
Нельзя прямо реализовать синхронный вызов
Есть эмуляция синхронности
Между отправкой сообщения и его обработкой
может пройти много времени

34. Другие подходы к интеграции
Передача файлов
Разделяемая бд
RPC

35. Шаблоны проектирования
 Шаблоны – экстернализованный опыт других умных людей
 Наша задача – освоить опыт, о котором говорится в шаблоне
 Перевести опыт в интуицию
 Нельзя выбирать шаблоны людям с небольшим опытом
 Проще думать о том, чего нельзя делать в проектировании, чем помнить
все возможные варианты шаблонов
 Нет хуже подхода, чем «сделать – страдать – переделать»
 Желательно сначала подумать

36. Как выбирать шаблон проектирования?
Интуитивно
Рассмотреть несколько вариантов
Формального критерия нет
Есть корреляция между опытом архитектора и
качеством системы
Нет корреляции между формальными признаками и
качеством

37. Шаблон Message Bus
Какая архитектура позволяет системам работать
вместе, но так чтобы систему можно было добавить и
удалить, не влияя на другие системы?
По мере роста всего решения, как можно снизить
расходы на добавление или удаление систем?

38. Требования к интеграции систем
 Зависимости между системами должны быть минимальны
 Количество связей между системами (n*(n-1)/2 связей в
полном графе) должно быть небольшим
 Объем изменений в каждой системе должен быть небольшим
 Легкость добавления еще одной системы

39. Шаблон Message Bus – решение

40. Шаблон Message Bus – решение
Шина передает сообщения между приложениями
Ключевые элементы:
Набор схем данных для сообщений
Набор сообщений
Общая инфраструктура для отправки и получения
сообщений

41. Очереди сообщений
Всего примерно 40-50
queues.io
Бывают
Brokerless – p2p
Brokered – есть сервер

42. Популярные очереди
Nanomsg
ZeroMQ
ActiveMQ
NATS
Kafka
Kestrel
NSQ
RabbitMQ
Redis
ruby-nats

43. Производительность очередей
Latency
Время передачи одного сообщения
Throughput
Количество сообщений в секунду

44. Throughput

45. Throughput

46. Latency

47. Latency

48. Latency

49. Latency

50. Задача 1
Давайте придумаем, как сделать
Яндекс.Метрику )
Не только про очереди
А еще про много всякого

51. Задача
Предложите свои задачи
Не менять постановку после озвучивания
Только уточнять
Постановка – 5 предложений

52. Ссылки
 https://medium.com/@priyaaank/patterns-for-microservices-e57a2d71ff9e
 http://queues.io/
 https://medium.com/startlovingyourself/need-of-messaging-queues-in-microservices-architecture-
91de0db89120
 https://www.enterpriseintegrationpatterns.com/patterns/messaging/
 https://bravenewgeek.com/dissecting-message-queues/
 https://habr.com/ru/post/326880/
 https://nats.io/about/
 https://github.com/tylertreat/mq-benchmarking
 https://bravenewgeek.com/benchmarking-message-queue-latency/
 http://highload.guide/blog/queues-and-lock.html

53. Задайте мне вопрос