Асинхронная коммуникация в Go: от понятного к душному. Дима Некрасов, Otello, 2ГИС

Этот доклад — не про rocket science и не про «всё и сразу». Здесь 20% практики, которой хватит, чтобы закрыть 80% задач. Остальное — духота, но иногда без неё нельзя: когда масштаб, нагрузка, или просто пора уже делать «как надо».

Простой мир синхронных вызовов рано или поздно заканчивается. Сначала появляется очередь. Потом — очередь для очереди. Потом — типы сообщений, форматы, порядок, idempotency, и вся эта «архитектура». Сначала ты просто пишешь сервис. Потом ты отвечаешь за то, чтобы сообщения не терялись.

Ты можешь не запоминать всё. Но что-то точно пригодится. А если не сейчас — то через два созвона и один инцидент.

Transcript

1. Асинхронная коммуникация Некрасов Дмитрий, 
 технический руководитель Otello
2. Кто я? • Больше 10 лет в ИТ; • Работал в отечественных и иностранных компаниях; • Тех лид, архитектор, программист; филантроп, миллиардер; • Фокус на: • маленькие команды и большие проекты; • какие эвристики позволяют затаскивать проекты быстро. • На 146% уверен, что архитектура ускоряет разработку и позволяет делать в срок.
3. Disclaimer • Будут эвристики, которые помогают быстро принять решение. • В проектировании в первую очередь полагаюсь на две метрики: • Связность системы (coupling) - на сколько взаимозависимы модули • КТО выполнит работу • КОГДА выполнит работу • Влияние на бизнес • Core / non-core domain • Влияние при падении • Здесь точно не будет всего, только основное.
4. Disclaimer • Эвристика – это упрощенные практические правила, благодаря которым делать что-то становится проще и легче. — Насим Талеб.
5. Disclaimer • Эвристика – это упрощенные практические правила, благодаря которым делать что-то становится проще 
 и легче. 
 — Насим Талеб. 
 • Главное преимущество таких правил в том, 
 что применяющий их знает: они далеки 
 от совершенства и всего лишь полезны.
 Опять — Насим Талеб.
6. Откуда родилась идея рассказать ?
7. О чем пойдет речь • Зачем мне это надо ? • Теоретическая часть • Виды асинхронной коммуникации • Порядок • Типы сообщений • Тип полезной нагрузки в сообщение • Тип полезной нагрузки по полезности • Немного про размер • Повседневные эвристики
8. Зачем мне это надо? Синхронность — совпадение и связь по времени чего-либо совершающегося (википедия) • Можно все построить на синхронных вызовах, RPC и тд • Делайте так в базовом случае • Точно знаем когда будет выполнено • Блокируемся ожидая ответа • Результат нужен здесь и сейчас Асинхронность — не совпадающий с чем-либо во времени (википедия) • Антоним синхронности • Мы не знаем когда выполнится • У нас может быть только обещание, что работа будет выполнена • Не блокируемся ожидая ответа • Результат не нужен здесь и сейчас
9. • Когда выбирать асинхронность: • Когда не нужен мгновенный ответ • Сама природа процесса асинхронная • Необходима доступность системы • Необходима масштабируемость системы • Стабильность системы • И тд. Зачем мне это надо?
10. Сама природа процесса асинхронная • Онлайн платежи • На платеж выделяется 20 минут, 
 нет смысла блокироваться.
11. Необходима доступность 
 системы (availability) «Впитать нагрузку»: 
 телеметрия с устройств
12. Необходима масштабируемость 
 системы (scalability) Ресурсоемкие задачи: обработка картинок, 
 расчет логистики
13. Стабильность системы Не смешивать core домены с supporting 
 и generic (см. Core domain charts / DDD)
14. Обзорная экскурсия в мире асинхронной коммуникации
15. на принятие решения, но знать полезно Редко влияют
16. Виды асинхронной коммуникации Плюсы: • можно брать данные не сразу • можно работать батчами • можно делать перепроцессинг Минусы: • если нагрузка не высокая то будет крутиться в холостую • сложнее масштабироваться под пиковые нагрузки Pull based
17. Виды асинхронной коммуникации Push based Плюсы: • шина мгновенно шлет сообщение в потребителя • легко масштабироваться под пиковые нагрузки Минусы: • нет лога сообщений • может натолкать много событий в потребителя
18. Гибридный через back-pressure • Включает в себя плюсы подходов • Редкий зверь Виды асинхронной коммуникации
19. Почему редко влияют? Виды асинхронной коммуникации • Используйте то, что принято у вас в компании • Должна быть серьезная причина
 использовать что-то другое
20. Порядок (ordering) • Проблемы с порядком событий будут встречаться
 практически во всех подходах • О них надо знать и понимать откуда они происходят
21. • Необходимо учитывать бизнес • Сложно дать общую рекомендацию • Использовать векторные часы, которые укажут на порядок и причинность : 
 Created { Version : 1 }
 Booked { Version : 2 } • можно использовать механизм версионирования из RDBMS • Смотреть технологии, которые используются у вас в компании и что предлагают для решения проблем. • Завязываетесь на конкретную технологию Порядок (ordering)
22. То, что чаще влияет на принятие решений
23. Виды сообщений • Мы командуем кому-то выполнить задачу, 
 повелительное наклонение • Это оркестрация — клиент определяет место
 потребителя в бизнесс процессе • Связность - знаем КТО будет выполнять работу • N клиентов -> 1 обработчик • Ок, когда в пределах одного домена: 
 команда изменить размер картинки Команды (commands):
24. Виды сообщений Команды (commands):
25. События (events) • хореография - потребитель сам определяет 
 свое место в бизнесс процессе • нет связности - не знаем КТО и КОГДА • отчет о том что произошло 
 в системе - payment_paid, 
 booking_booked • можно использовать 
 вместо команд • 1 событие ->
 N потребителей Виды сообщений
26. Как трансформировать событие 
 в команду • На стороне публикатора ( open-host ) • Публикатор знает про потребителя
27. Как трансформировать событие 
 в команду • На стороне потребителя (anti-corruption layer ) • Потребитель знает про публикатора
28. Как трансформировать 
 событие в команду • Не у публикатора 
 и не у потребителя • У вас есть менеджер процессов. • В вашей системе его может 
 и не быть.
29. Виды сообщений Я бы еще выделил уведомления (notifications): • считаю, что это анти-паттерн • полезно знать • использовать осторожно • связность сильная
30. Проблемы нотификации (notifications) Проблемы: • Cвязность сильная • Потребители порождают M (кол-во событий) x N (кол-во потребителей) нагрузку • Когда потребитель придет за данными он может получить новые данные
31. Полезные уведомления (notifications) Иногда могут быть полезны: • Строгие требования к длине сообщения - смс, твиттер • Смс от МЧС с предупреждением и ссылкой на прогноз • Переправить большие данные
32. Виды полезной нагрузки в сообщении • Состояние (state, fact) • Разница (delta, diff, action)
33. Разница (delta, diff, action) Плюсы: • События будут меньше по размеру • Если изменения частые – можно выиграть в трафике Минусы: • Исправление проблем со схемой событий ( например: gdpr ) • Придется сильнее думать об event ordering • Может понадобиться полный агрегат • Сложно выработать формат передачи Виды полезной нагрузки в сообщении
34. Разница (delta, diff, action) Пример: ImageResized { "ImageId" : 123, "NewSize" : "500x500" }
35. Состояние (state, fact) Плюсы: • Легко имплементировать • Получаем текущий слепок состояния • Если меняется схема событий – проще исправить одно state событие, чем много delta; Минусы: • Cобытие может оказаться слишком большим • Не понятно что изменилось, если ордеринг событий нарушится • Если изменения частые, может быть действительно слишком много лишних данных об одном и том же Виды полезной нагрузки в сообщении
36. Состояние (state, fact) Пример: ImageResized { "ImageId" : 123, "Sizes" : [ "500x500", "640x480", ], "PathToFile": "resizedImages/123" }
37. Виды полезной нагрузки в сообщении • Гибрид • Шлют состояние 
 и то, что изменилось ImageResized { "State": { "ImageId": 123, "Sizes": ["500x500", "640x480"], "PathToFile": "resizedImages/123" }, "Action": { "NewSize": "500x500" } }
38. Полезность / полнота полезной нагрузки ( Event granularity ) • Coarse ( обобщенный ) • Fine ( конкретный, гранулярный )
39. Полезность / полнота полезной нагрузки ( Event granularity ) Coarse ( обобщенный ) • События большие и общие, имею обобщенное имя и много данных не обязательных; • Необходимо проверять, что же все-таки случилось и принимать решение реагировать или нет; • Обобщенность позволяет легче развивать домен. PaymentChanged { "Status" : "Paid", "PaymentId" : 123, "TotalAmount" : 12345, "CustomerEmail" : "hello_lamoda@test.ru", "CustomerPhone" : «8999123123123", "Transactions" : [ { "OpperationType" : "Charge", "Status" : "Success" } ] }
40. Полезность / полнота полезной нагрузки ( Event granularity ) Fine ( конкретный, гранулярный) • Такие события слишком мелкие и специфичные; • Чаще нормально называются; • Но тяжело обеспечивать поддержку событий которых может быть слишком много; • Может не хватать данных для реакции PaymentPaid { "PaymentId" : 123, "TotalAmount" : 12345 }
41. Fine ( конкретный, гранулярный ) Гранулярных событий может быть слишком много: BookingCreated {} BookingPending {} BookingWaitingForProvider {} BookingSentToProvider {} BookingBooked {} BookingPenaltyAdded {} BookingPenaltyApplied {} BookingCheckedOut {} BookingComplete {} …
42. Полезность / полнота полезной нагрузки 
 (Event granularity) 
 
 Спасибо Антону Давыдову.
43. Полезность / полнота полезной нагрузки 
 (Event granularity) • В 2GIS распространен стриминговый подход • Используют Coarse + State
44. Размер 
 сообщения
45. Размер сообщения • В идеале — меняй архитектуру • Не получается архитектуру — меняй форматы: ✓Avro, MessagePack и тд. • В ход может пойти даже компрессия.
46. 20%
47. Тип сообщения • Событие (еvent, domain event) • Почему?: • Низкая связность • Легко имплементировать • Подходит под много сценариев • Может заменить собой команду 
 (через anti-corruption layer)
48. Тип полезной нагрузки в сообщение • Состояние (state, fact, модель целиком) • Почему: • Легко имплементировать; • Подходит многим; • Не надо аккумулировать агрегат.
49. • Coarse (грубая, обобщенная): • С нюансами • Выделить три вида событий: создание, изменение, завершение • Почему: • легко имплементировать; • меньше думать над порядком; • закрывает много сценариев. Тип полезной нагрузки по полезности (event granularity)
50. Спасибо! Ссылка на материал