Messaging
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
Сейчас при построении архитектур на базе служб и распределенных бизнес процессов все завязываются на обмен сообщениями.
Архитектура старая и хорошо описанная (в частности в EIP Грегора Хопа).
Если при этом нужна производительность - берем мощный инструмент обмена сообщениями.
Благо арсенал огромен от старого Кролика до свежей Панды
С другой стороны, читаем у того же Хопа (EIP, Введение):
"Системы обмена сообщениями вносят дополнительные издержки в процесс взаимодействия между приложениями. На создание, отправку, получение и обработку сообщения уходят время и ресурсы. К тому же передача большого объема данных может повлечь за собой создание несметного числа сообщений."
и далее
"Если бы настроить готовые приложения на использование одного и того же формата данных было так легко, нам вообще не понадобился бы обмен сообщениями (Messaging); вместо него было бы гораздо практичнее использовать общую базу данных (Shared Database)"
В мире, где во всю правит NoSQL, озвученная выше проблема форматов выглядит как нечто очень неактуальное.
Зачем нам все эти издержки, муки с балансировкой и чанками от messaging ?
Следующую систему строю на Shared Database :)
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍3😁1
Messaging.Topic
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
Возвращаясь к теме обмена сообщениями👆
Чем топик хуже нетипизированого набора данных в БД:
1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное.
Тем более со всей этой распределёнкой порядок сообщений в топике все равно случайный.
Нет, конечно есть всякие KSQL - но это как молотком шурупы вкручивать.
2. Иногда хочется передать сразу весь снапшот, а не дельту, или даже большущий БЛОБ
В топике - чанкаем. В БД просто льем.
3. Как же удобно управлять сообщениями(записями) в базе !
- Любая статистика.
- Удаляй любого на выбор.
- Перекладывать мертвых и инвалидов из топика в топик не надо. Достаточно пометить.
- и т. д. и т. п.
4. Масштабируемость - сколько топиков вытянет ваша система ?
А что делать если эти топики еще и динамически создаются/удаляются ?
У топика только одно преимущество. Он чистится автоматом.
При передачи сообщений через базу нужно быть очень аккуратным, иначе горы мусора гарантированы.
#messaging #performance #производительность #эффективность #Архитектурные_стили
👍1
Прямоугольники и стрелочки
Messaging.Topic Возвращаясь к теме обмена сообщениями👆 Чем топик хуже нетипизированого набора данных в БД: 1. Топик это всегда по очереди, а хочется получать не первое в списке а нужное. Тем более со всей этой распределёнкой порядок сообщений в топике все…
Топики против базы данных (продолжение)
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
Основная проблема разделенной БД (Share Database) - связывание общающихся сервисов через общую схему данных
Если БД используется для передачи сообщений - этой проблемы нет.
Время жизни сообщения - время взаимодействия.
Миграция с нулевым даунтаймом - без проблем.
Конечно, при этом, БД должна допускать любую структуру сообщения (NoSQL)
Месседжеры обещают поставлять сообщения по-очереди - но не справляются со своим единственным контрактом в распределенной системе (либо не по-очереди либо слишком медленно)
У себя организовали прототип (RSocket, Bookeeper)
По отношению к прототипу на Pulsar задержка в 10 раз меньше на том же профиле нагрузки
При этом
- абсолютно не ограничены в количестве клиентов
- можем бегать по сообщениям в базе - выбирая по приоритетам, фильтрам, или как захотим
architectural-decision-records.pdf
266.9 KB
Гайд по ADR от AWS
Forwarded from Антонов такой Антонов
Секреты низкой продуктивности
В 2021 году становится все сложнее сохранить низкую продуктивность. Как это сделать - помогут пять простых советов:
1. Постоянно встречайтесь с кем-то вместо того, чтобы решать всё на онлайн звонках. Это позволит вместо получаса тратить по часу-полутора на каждую встречу, плюс час между ними на разные передвижения, перемещения и просто свободные окна. В результате вы сможете сократить количество полезных разговоров в 3-4 раза!
2. Откажитесь от быстрых транзакций в онлайне и через крипту - передавайте деньги наличными, выставляйте счета, пусть Галочка сделает перевод в банковские часы. Ни к чему отправлять тысячу долларов с телефона с карты на карту - лучше встретится в конце недели и вместе выпить чаю.
3. Старайтесь заниматься всеми делами с телефона, маленький экран поможет тратить побольше времени на чтение разных материалов. А уж как маленький экран помогает медленно печатать!
4. Постарайтесь не делать никаких заметок, которые могут позволить вам лучше понять какую-то информацию, запомнить события или узнать себя. Лучше каждый день начинать с чистого листа, а всё важное вспоминать по ситуации.
5. Не пользуйтесь гуглом, пусть вам лучше кто-нибудь всё объяснит так, как он это видит. Вообще, старайтесь перелопачивать поменьше информации, полагаясь на мнение одного-двух человек, желательно случайных.
Надеюсь, эти секреты помогут вам нарастить отставание от своих коллег и партнеров, а также поспособствуют новым жалобам на несправедливость жизни.
В 2021 году становится все сложнее сохранить низкую продуктивность. Как это сделать - помогут пять простых советов:
1. Постоянно встречайтесь с кем-то вместо того, чтобы решать всё на онлайн звонках. Это позволит вместо получаса тратить по часу-полутора на каждую встречу, плюс час между ними на разные передвижения, перемещения и просто свободные окна. В результате вы сможете сократить количество полезных разговоров в 3-4 раза!
2. Откажитесь от быстрых транзакций в онлайне и через крипту - передавайте деньги наличными, выставляйте счета, пусть Галочка сделает перевод в банковские часы. Ни к чему отправлять тысячу долларов с телефона с карты на карту - лучше встретится в конце недели и вместе выпить чаю.
3. Старайтесь заниматься всеми делами с телефона, маленький экран поможет тратить побольше времени на чтение разных материалов. А уж как маленький экран помогает медленно печатать!
4. Постарайтесь не делать никаких заметок, которые могут позволить вам лучше понять какую-то информацию, запомнить события или узнать себя. Лучше каждый день начинать с чистого листа, а всё важное вспоминать по ситуации.
5. Не пользуйтесь гуглом, пусть вам лучше кто-нибудь всё объяснит так, как он это видит. Вообще, старайтесь перелопачивать поменьше информации, полагаясь на мнение одного-двух человек, желательно случайных.
Надеюсь, эти секреты помогут вам нарастить отставание от своих коллег и партнеров, а также поспособствуют новым жалобам на несправедливость жизни.
😁5👍1
Ориентация на продукт/проект
MSA декларирует ориентацию на продукт (принцип Products not Projects)
В разговоре с коллегами - полное непонимание.
Максимум, что вспоминают - это наличие не человека DevOps-а.
В моём упрощенном и поэтому несколько ущербном представлении:
- Ориентация на проект - это ориентация на выполнение задач,
- Ориентация на продукт- это возможность (can, may) эти задачи ставить.
Если задачи приходят от ПО - команду ориентируют на проект.
Если от ПО приходят истории - а команды перекладывает их в задачи - ориентация на продукт.
Если инциденты приходят от службы эксплуатации - процесс.
Если служба эксплуатации часть команды - продукт (привет DevOps!).
И самое интересное с архитектором.
Архитектор вне команды - процесс.
Архитектор в команде (ArcOps, DevArcOps) -> архитектурный бэклог (enablers) внутри команды - продукт.
Однако, архитектор это один из немногих кто знает где выход из бункера (Silos)
Должен быть вне командный арх. ком. - на котором решают вопросы взаимодействия.
Откуда берутся задачи для арх. кома ?
Ставит ГЛАВНЫЙ архитектор - процесс
Ставит команда (архитектура как сервис) - продукт.
"Главный" архитектор - в роли арбитра и последней инстанции
но без прав и власти (не дает задачи). Хм
Чувствую, тут не всё так однозначно
MSA декларирует ориентацию на продукт (принцип Products not Projects)
В разговоре с коллегами - полное непонимание.
Максимум, что вспоминают - это наличие не человека DevOps-а.
В моём упрощенном и поэтому несколько ущербном представлении:
- Ориентация на проект - это ориентация на выполнение задач,
- Ориентация на продукт- это возможность (can, may) эти задачи ставить.
Если задачи приходят от ПО - команду ориентируют на проект.
Если от ПО приходят истории - а команды перекладывает их в задачи - ориентация на продукт.
Если инциденты приходят от службы эксплуатации - процесс.
Если служба эксплуатации часть команды - продукт (привет DevOps!).
И самое интересное с архитектором.
Архитектор вне команды - процесс.
Архитектор в команде (ArcOps, DevArcOps) -> архитектурный бэклог (enablers) внутри команды - продукт.
Однако, архитектор это один из немногих кто знает где выход из бункера (Silos)
Должен быть вне командный арх. ком. - на котором решают вопросы взаимодействия.
Откуда берутся задачи для арх. кома ?
Ставит ГЛАВНЫЙ архитектор - процесс
Ставит команда (архитектура как сервис) - продукт.
"Главный" архитектор - в роли арбитра и последней инстанции
но без прав и власти (не дает задачи). Хм
Чувствую, тут не всё так однозначно
Завтра веду курс "Современные сервисные архитектуры"
Хочу часть опросов проводить на этом канале
С целью накопления статистики
Хочу часть опросов проводить на этом канале
С целью накопления статистики
🔥2👍1
Какое утверждение Вам ближе всего ?
Anonymous Poll
13%
Микросервисы - это архитектура будущего. Все там будем
2%
Микросервисы - это хайп. Много шуму из ничего
56%
Микросервисы - это здорово. Но мало кто умеет их готовить
11%
Микросервисы решают слишком узкий круг задач. Нужны редко и подходят далеко не всем
10%
Под словом "микросервисы" каждый понимает своё. О чём опрос ?
8%
Другое (в коментариях)
Кто в Ваших проектах принмает архитектурные решения ?
Anonymous Poll
33%
Разработчики (коллегиально)
17%
Разработчик в роли архитектора
16%
Выделенный архитектор в составе команды разработчиков
17%
Внешний (к команде) архитектор, по заданию команды разработчиков
29%
Внешний (к команде) архитектор по заданию из вне
5%
Никто
12%
Хочу просто посмотреть ответы
Вынос логики сервиса.png
60.2 KB
Вынос логики из сервиса
Возможные пути
Возможные пути
DDD vs MSA
Предполагается что MSA идеально ложится на DDD.
Многие повторяют, что MSA это DDD в распределёнке.
Однако, есть нюансы.
На картинке выше - процесс дистилляции сервиса.
Вытягиваем из сервиса всё то, что не есть логика смыслового ядра.
Это один из основных механизмов DDD
Однако, как только всё выделенное попадает в чужие руки - сразу же нарушается принцип MSA "ориентация на бизнес возможности".
Всё что связано с реализацией бизнес-возможности должно быть сцеплено вместе и отдано в руки одной команды
Либо полная хореография с прямым доступом и рендеринг на сервисе, либо три колодца.
Однако, конфликт )
#MSA, #DDD
Предполагается что MSA идеально ложится на DDD.
Многие повторяют, что MSA это DDD в распределёнке.
Однако, есть нюансы.
На картинке выше - процесс дистилляции сервиса.
Вытягиваем из сервиса всё то, что не есть логика смыслового ядра.
Это один из основных механизмов DDD
Однако, как только всё выделенное попадает в чужие руки - сразу же нарушается принцип MSA "ориентация на бизнес возможности".
Всё что связано с реализацией бизнес-возможности должно быть сцеплено вместе и отдано в руки одной команды
Либо полная хореография с прямым доступом и рендеринг на сервисе, либо три колодца.
Однако, конфликт )
#MSA, #DDD
👍1
DDD и MSA
У К. Ричардсона крайне мало информации по декомпозиции.
Всевозможные шлюзы и оркестраторы возникают у него не как результат последовательного архитектурного процесса, а как решение частных проблем.
Спешу компенсировать )
1. Анализ выводит нас на понимание домена (предметной области).
Домены связаны с бизнес возможностями.
За доменами закрепляем команду (принцип MSA)
Если границы домена и сервиса совпадают - имеем паттерн "Автономный сервис"
т.е. сервис включающий в себя и слой представления данных (UI), и слой хранения (DB)
С точки зрения сцепленности всё ОК. MSA этого достаточно. Задача решена.
Но DDD идет дальше
2. Выделяем из домена поддомены. Домен становится смысловым ядром. Поддомены - специального и общего назначения.
DDD это нужно для увеличения ясности. Ясность - основная цель DDD. MSA это не нужно. Если поддомены уползут в чужие руки, теряется скорость выхода на рынок.
Нужно преодолевать барьеры. t2m - основная цель MSA.
Тут от нас могут уйти логика представления (UI), логика бизнес процесса (оркестратор), логика контроллера (шлюз).
Производительность может потребовать вывода механизмов хранения в общую БД
Единственно неразрывными остаются данные и поведение (бизнес логика).
3. Бизнес логика тоже может дробиться на сервисы.
Резон ясность и переиспользуемость (анти-паттерн в MSA)
Один домен превращается во множество под-доменов, а те в свою очередь могут распасться на множество ограниченных контекстов и сервисов.
4. Таким образом, получаем дилемму сцепленность-ясность.
Впрочем это обычное дело в архитектуре )
Агрегация против дистилляции (сравните с БД нормализация против денормализации)
Очередной компромисс.
5. И да, можно поступить хитро. Зацепить команду за доменом и все эти сервисы, шлюзы, оркестраторы будут в одних руках. Однако всегда ли это возможно/целесообразно ?
У К. Ричардсона крайне мало информации по декомпозиции.
Всевозможные шлюзы и оркестраторы возникают у него не как результат последовательного архитектурного процесса, а как решение частных проблем.
Спешу компенсировать )
1. Анализ выводит нас на понимание домена (предметной области).
Домены связаны с бизнес возможностями.
За доменами закрепляем команду (принцип MSA)
Если границы домена и сервиса совпадают - имеем паттерн "Автономный сервис"
т.е. сервис включающий в себя и слой представления данных (UI), и слой хранения (DB)
С точки зрения сцепленности всё ОК. MSA этого достаточно. Задача решена.
Но DDD идет дальше
2. Выделяем из домена поддомены. Домен становится смысловым ядром. Поддомены - специального и общего назначения.
DDD это нужно для увеличения ясности. Ясность - основная цель DDD. MSA это не нужно. Если поддомены уползут в чужие руки, теряется скорость выхода на рынок.
Нужно преодолевать барьеры. t2m - основная цель MSA.
Тут от нас могут уйти логика представления (UI), логика бизнес процесса (оркестратор), логика контроллера (шлюз).
Производительность может потребовать вывода механизмов хранения в общую БД
Единственно неразрывными остаются данные и поведение (бизнес логика).
3. Бизнес логика тоже может дробиться на сервисы.
Резон ясность и переиспользуемость (анти-паттерн в MSA)
Один домен превращается во множество под-доменов, а те в свою очередь могут распасться на множество ограниченных контекстов и сервисов.
4. Таким образом, получаем дилемму сцепленность-ясность.
Впрочем это обычное дело в архитектуре )
Агрегация против дистилляции (сравните с БД нормализация против денормализации)
Очередной компромисс.
5. И да, можно поступить хитро. Зацепить команду за доменом и все эти сервисы, шлюзы, оркестраторы будут в одних руках. Однако всегда ли это возможно/целесообразно ?
👍1
Core Domain против Смыслового Ядра
Введя термин Core Domain Эванс умудрился запутать множество последователей.
Получается, что предметная область (домен) делится на домен и вспомогательные поддомены.
В этом плане русский перевод (Смысловое ядро) намного разумнее.
В результате дистилляции Домен усыхает до смыслового ядра.
Всё отжатое попадает в поддомены.
Предполагаю что Эванс просто напутал с порядком слов )
#DDD
Введя термин Core Domain Эванс умудрился запутать множество последователей.
Получается, что предметная область (домен) делится на домен и вспомогательные поддомены.
В этом плане русский перевод (Смысловое ядро) намного разумнее.
В результате дистилляции Домен усыхает до смыслового ядра.
Всё отжатое попадает в поддомены.
Предполагаю что Эванс просто напутал с порядком слов )
#DDD
Архитектурные стили и паттерны
Архитектора в лёгком замешательстве. На форумах всё чаще можно наблюдать дискуссии о настоящем и не настоящем DDD (REST, MSA и др.)
Сами классики вносят сумятицу.
Фаулер и Левис про MSA
As with any definition that outlines common characteristics, not all microservice architectures have all the characteristics, but we do expect that most microservice architectures exhibit most characteristics.
https://martinfowler.com/articles/microservices.html
Ник Тьюн про каноническое DDD и ddd от комьюнити
https://medium.com/nick-tune-tech-strategy-blog/domain-driven-design-ddd-vs-domain-driven-design-ddd-10ec1d5ca6c7
IMHO всё встает на свои места если вспомнить старое доброе деление на стили и паттерны.
Паттерн имеет четкую цель и чёткие же нерушимые принципы построения
Стиль появляется при освоении паттерна комьюнити. Набор принципов варьируется. Выясняется, что конструкция может приносить пользу не только в рамках означенной цели. И это уже стиль.
Так было с ООП, так было с MVC. Так повторяется с новыми архитектурами.
Например микросервисы.
1. Микросервисы как паттерн (в рамках SOA) решали задачу снижения t2m и поддерживали все принципы Левиса.
2. Микросервисы как стиль - решают разные задачи (уход от надоевшего вендора ESB, организация Agile команд, независимое масштабирование и др.)
И принципы можно выбирать по вкусу. (лучше без общей БД, но можно и с ней)
Подхвачу идею Ника.
Называем паттерны с большой буквы (DDD, Микросервисы)
Называем стиль с маленькой (ddd, микросервисы )
И больше никаких споров )
Архитектора в лёгком замешательстве. На форумах всё чаще можно наблюдать дискуссии о настоящем и не настоящем DDD (REST, MSA и др.)
Сами классики вносят сумятицу.
Фаулер и Левис про MSA
As with any definition that outlines common characteristics, not all microservice architectures have all the characteristics, but we do expect that most microservice architectures exhibit most characteristics.
https://martinfowler.com/articles/microservices.html
Ник Тьюн про каноническое DDD и ddd от комьюнити
https://medium.com/nick-tune-tech-strategy-blog/domain-driven-design-ddd-vs-domain-driven-design-ddd-10ec1d5ca6c7
IMHO всё встает на свои места если вспомнить старое доброе деление на стили и паттерны.
Паттерн имеет четкую цель и чёткие же нерушимые принципы построения
Стиль появляется при освоении паттерна комьюнити. Набор принципов варьируется. Выясняется, что конструкция может приносить пользу не только в рамках означенной цели. И это уже стиль.
Так было с ООП, так было с MVC. Так повторяется с новыми архитектурами.
Например микросервисы.
1. Микросервисы как паттерн (в рамках SOA) решали задачу снижения t2m и поддерживали все принципы Левиса.
2. Микросервисы как стиль - решают разные задачи (уход от надоевшего вендора ESB, организация Agile команд, независимое масштабирование и др.)
И принципы можно выбирать по вкусу. (лучше без общей БД, но можно и с ней)
Подхвачу идею Ника.
Называем паттерны с большой буквы (DDD, Микросервисы)
Называем стиль с маленькой (ddd, микросервисы )
И больше никаких споров )
martinfowler.com
Microservices
Defining the microservices architectural style by describing their nine common characteristics
👍2
EDA и MSA
Интересная книжка по смешиванию стилей
https://www.oreilly.com/library/view/building-event-driven-microservices/9781492057888/
#EDA #MSA
Интересная книжка по смешиванию стилей
https://www.oreilly.com/library/view/building-event-driven-microservices/9781492057888/
#EDA #MSA
O’Reilly Online Learning
Building Event-Driven Microservices
Organizations today often struggle to balance business requirements with ever-increasing volumes of data. Additionally, the demand for leveraging large-scale, real-time data is... - Selection from Building Event-Driven Microservices [Book]
👍2
Получил предложение скачать бесплатно )
Если кому интересно - берите.
Легкое чтение по арх. стилям с картинками
https://get.oreilly.com/ind_software-architecture-patterns.html
Если кому интересно - берите.
Легкое чтение по арх. стилям с картинками
https://get.oreilly.com/ind_software-architecture-patterns.html
O'Reilly
O'Reilly - Software Architecture Patterns
Free report: Software Architecture Patterns, 2nd edition. Get it here.
👍2
Рекомендую
Очень хорошо по стратегическим паттернам DDD и топологии команд
https://www.amazon.com/Adaptive-Systems-Domain-Driven-Wardley-Topologies/dp/0137393032
Очень хорошо по стратегическим паттернам DDD и топологии команд
https://www.amazon.com/Adaptive-Systems-Domain-Driven-Wardley-Topologies/dp/0137393032
👍2