SAGA - один из первых шаблонов для реализации транзакционной логики в распределенных системах. Он появился раньше чем микросервисная архитектура, но особую популярность приобрел вместе с микросервисами.
Идея шаблона сводится к идеи "целостность в конечном итоге", он состоит из цепочки нод, которые имеют свое состояние и работают по транзакционной модели ACID, каждая из нод либо выполняет транзакцию, либо инициирует цепочку отмены транзакции.
Взаимосвязь нод строится на базе событий, которые могут распространяться как синхронно, так и асинхронно.
Идея шаблона сводится к идеи "целостность в конечном итоге", он состоит из цепочки нод, которые имеют свое состояние и работают по транзакционной модели ACID, каждая из нод либо выполняет транзакцию, либо инициирует цепочку отмены транзакции.
Взаимосвязь нод строится на базе событий, которые могут распространяться как синхронно, так и асинхронно.
Существует несколько вариантов реализации паттерна на практике, все зависит от конечных свойств, которые нужно получить в решении:
Атомарность vs Модульность
Синхронность vs Асинхронность
Оркестрация vs Хореография
Атомарность vs Модульность
Синхронность vs Асинхронность
Оркестрация vs Хореография
Вариант атомарного, синхронного, оркестрированного поведения:
- существует одна большая распределенная транзакция (пунктир на рисунке)
- запросы получает медиатор, который принимает решение о том как исполнять запрос внутри транзакции
- существует одна большая распределенная транзакция (пунктир на рисунке)
- запросы получает медиатор, который принимает решение о том как исполнять запрос внутри транзакции
- ошибки обрабатывает так же медиатор, выполняя "откат транзакции" на уровне каждой ноды
- все запросы синхронные (например, http) и по результату запросу сразу приходит статус (медиатор ждет результата обработки)
- все запросы синхронные (например, http) и по результату запросу сразу приходит статус (медиатор ждет результата обработки)
Сегодня выпустил стрим для патронов на тему SAGA, слайды тут - https://s0er.ru/codelabs/arch_stream_18
Вопрос: в чем разница между модульностью и грануляцией?
Ответ:
- модульность - это набор требований позволяющих провести разделение системы на составные части, часто слабо зацепленные друг на друга
- грануляция - это набор требований позволяющий найти оптимальный размер составных частей, без потери функциональности
грубо говоря модульность - про то как разделить на части, грануляция - про то как не делать сильно большие или сильно мелкие компоненты.
Чтобы понять когда менять грануляцию системы, нужно учесть следующие моменты по мере уменьшения важности и влияния на грануляцию:
- функциональность (исходим из бизнес-задач при объединении или разделении)
- домен изменений (если код неустойчив к изменениям и требует слишком много правок в разных частях, то пытаемся сгранулировать правильно)
- масштабирование и производительность (адаптируем размер компонент под задачи масштабирования)
- устойчивость к сбоям (стоит задуматься в случае если гранулирование может поменять эту характеристику в лучшую сторону)
- безопасность (точно так же как и устойчивость к сбоям, иногда грануляция помогает решить проблемы требований по безопасности, тогда имеет смысл провести новые границы)
Ответ:
- модульность - это набор требований позволяющих провести разделение системы на составные части, часто слабо зацепленные друг на друга
- грануляция - это набор требований позволяющий найти оптимальный размер составных частей, без потери функциональности
грубо говоря модульность - про то как разделить на части, грануляция - про то как не делать сильно большие или сильно мелкие компоненты.
Чтобы понять когда менять грануляцию системы, нужно учесть следующие моменты по мере уменьшения важности и влияния на грануляцию:
- функциональность (исходим из бизнес-задач при объединении или разделении)
- домен изменений (если код неустойчив к изменениям и требует слишком много правок в разных частях, то пытаемся сгранулировать правильно)
- масштабирование и производительность (адаптируем размер компонент под задачи масштабирования)
- устойчивость к сбоям (стоит задуматься в случае если гранулирование может поменять эту характеристику в лучшую сторону)
- безопасность (точно так же как и устойчивость к сбоям, иногда грануляция помогает решить проблемы требований по безопасности, тогда имеет смысл провести новые границы)
👍2
YaTalks - крупнейшая конференция Яндекса для разработчиков, которая пройдет онлайн 3-4 декабря 2021 под эгидой «IT как новый космос». Приглашают каждого, кто пишет код или работает над продуктом. Вас ждут два дня интересных докладов, дебатов и дискуссий по 6 трекам Lifestyle, Backend, Frontend, ML, Mobile, Product с 80 экспертами из мировых и российских компаний. Регистрируйтесь бесплатно:
https://clck.ru/YsJYh
https://clck.ru/YsJYh
yatalks.yandex.ru
YaTalks 2023 — Yandex's premier conference for the IT community
On December 5-6, Moscow and Belgrade will host over 100 IT industry experts and scientists delivering technical presentations on development, ML, and giving popular science lectures.
👍2
Чем отличается архитектура и декомпозиция?
Преамбула
часто на митингах звучит фраза "а теперь давайте обсудим архитектуру проекта" и далее начинается обсуждение того как нужно правильно разделить программу на классы и каким образом выстроить файловую структуру проекта. На самом деле речь идет не об архитектуре, а о декомпозиции, почему так? Давайте разбираться.
Определения:
Декомпозиция — операция мышления, состоящая в разделении целого на части. Также декомпозицией называется общий приём, применяемый при решении проблем, состоящий в разделении проблемы на множество частных проблем, а также задач, не превосходящих суммарно по сложности исходную проблему, с помощью объединения решений которых, можно сформировать решение исходной проблемы в целом. (ист. википедия)
Архитектура программного обеспечения — совокупность важнейших решений об организации программной системы. Архитектура включает:
- выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
- соединение выбранных элементов структуры и поведения во всё более крупные системы;
- архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение.
(ист. википедия)
Основная мысль:
На самом деле определение архитектуры приложения имеет много трактовок, но все так или иначе сходятся в том, что архитектура - это выделение главного и принятие решений о функционировании системы в целом. Процесс выработки архитектурного решения, как правило, состоит из следующих шагов:
- формулирование требований (ограничения, желаемые свойства системы и т.д.)
- анализ и выработка "правил" функционирования программной системы (общие архитектурные решения, которые помогают принимать решение при написании кода или построении архитектурных представлений)
- подготовка архитектурных представлений (как правило графическая декомпозиция системы на графические представления, разделенные на уровни абстракции)
- анализ конечных свойств системы (проверка на соответствие требования и ограничениям).
Таким образом "декомпозиция" действительно используется как составной компонент построения архитектуры программной системы, но само понятие архитектуры гораздо шире, чем само понятие декомпозиции. Так же важно понимать, что архитектурная декомпозиция строится как правило на базе функциональной декомпозиции, а не модульной или классовой.
Таким образом, если речь идет о разделении программы на классы (не о выделении интерфейсов, не о распределении обязанностей, не о выработке требований и т.д.), а только о "географическом" размещении файлов и вынесении кода в эти файлы, то это с большим натягом можно отнести к процессу построения архитектуры приложения, но правильнее всего называть "модульная декомпозиция" или "классовая декомпозиция". Архитектуре же строится по принципу "от общего к частному" и начинается со сбора и формирования требований.
Преамбула
часто на митингах звучит фраза "а теперь давайте обсудим архитектуру проекта" и далее начинается обсуждение того как нужно правильно разделить программу на классы и каким образом выстроить файловую структуру проекта. На самом деле речь идет не об архитектуре, а о декомпозиции, почему так? Давайте разбираться.
Определения:
Декомпозиция — операция мышления, состоящая в разделении целого на части. Также декомпозицией называется общий приём, применяемый при решении проблем, состоящий в разделении проблемы на множество частных проблем, а также задач, не превосходящих суммарно по сложности исходную проблему, с помощью объединения решений которых, можно сформировать решение исходной проблемы в целом. (ист. википедия)
Архитектура программного обеспечения — совокупность важнейших решений об организации программной системы. Архитектура включает:
- выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
- соединение выбранных элементов структуры и поведения во всё более крупные системы;
- архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение.
(ист. википедия)
Основная мысль:
На самом деле определение архитектуры приложения имеет много трактовок, но все так или иначе сходятся в том, что архитектура - это выделение главного и принятие решений о функционировании системы в целом. Процесс выработки архитектурного решения, как правило, состоит из следующих шагов:
- формулирование требований (ограничения, желаемые свойства системы и т.д.)
- анализ и выработка "правил" функционирования программной системы (общие архитектурные решения, которые помогают принимать решение при написании кода или построении архитектурных представлений)
- подготовка архитектурных представлений (как правило графическая декомпозиция системы на графические представления, разделенные на уровни абстракции)
- анализ конечных свойств системы (проверка на соответствие требования и ограничениям).
Таким образом "декомпозиция" действительно используется как составной компонент построения архитектуры программной системы, но само понятие архитектуры гораздо шире, чем само понятие декомпозиции. Так же важно понимать, что архитектурная декомпозиция строится как правило на базе функциональной декомпозиции, а не модульной или классовой.
Таким образом, если речь идет о разделении программы на классы (не о выделении интерфейсов, не о распределении обязанностей, не о выработке требований и т.д.), а только о "географическом" размещении файлов и вынесении кода в эти файлы, то это с большим натягом можно отнести к процессу построения архитектуры приложения, но правильнее всего называть "модульная декомпозиция" или "классовая декомпозиция". Архитектуре же строится по принципу "от общего к частному" и начинается со сбора и формирования требований.
👍5❤1
Так ли важно называть вещи правильно?
По сути какая разница "классовая декомпозиция" или "архитектура приложения"? Разницы действительно нет, если, называя вещи неправильно, вы правильно выстраиваете процессы, т.е. делаете не только декомпозицию, но выработку общих проектных решений, формирование интерфейсов, анализ требований и т.д.
Неправильно использование термина - это всего лишь один из признаков, который может говорить о том, что в процессе разработки упускаются важные аспекты. Если вещи называть своими именами, то и контроль над правильной работой команды делать проще.
По сути какая разница "классовая декомпозиция" или "архитектура приложения"? Разницы действительно нет, если, называя вещи неправильно, вы правильно выстраиваете процессы, т.е. делаете не только декомпозицию, но выработку общих проектных решений, формирование интерфейсов, анализ требований и т.д.
Неправильно использование термина - это всего лишь один из признаков, который может говорить о том, что в процессе разработки упускаются важные аспекты. Если вещи называть своими именами, то и контроль над правильной работой команды делать проще.
👍2
Завел резервный канал на Яндекс Дзен - https://zen.yandex.ru/id/5f578bdf22e26e081a67cfd2
Дзен
S0ER | Дзен
Канал автора «S0ER» в Дзен ⭐: undefined
👍4
Media is too big
VIEW IN TELEGRAM
Зрители канала предложили использовать телеграм в том числе для постинга видео с канала.
Решил для начала перенести сюда несколько хороших видео и посмотреть что получится.
Внимание! Это старое видео "Три замечательные книги по алгоритмам".
Решил для начала перенести сюда несколько хороших видео и посмотреть что получится.
Внимание! Это старое видео "Три замечательные книги по алгоритмам".
👍41🔥2🤔1
Теперь Телеграм заменит мне все социальные сети. Раньше какие-то свои мысли я писал в Твиттер, что-то писал в постах на ютбе, что-то писал на сайте https://soer.pro
Но теперь у меня будет моноаккаунт в телеге. Здесь и посты, и видео, и размшления. И что самое важное - общение по OpenSource проектам.
- Сейчас у меня уже вложен черновик (потому что пока проектом я стесняюсь эту поделку назвать) OBSOverlay - https://github.com/soerdev/obsoverlay
- Кроме этого фронтовая часть сайта soer.pro - https://github.com/soerdev/soer
Последний, кстати, это как раз пример того, что я буду двигать на канале и для патронов - пример полноценной реактивной архитектуры и разработки на базе монорепозитория.
Монорепо - потому что я "маленький", т.е. у меня нет команды и все приходится делать самому, а монорепо помогает снизить издержки.
Некоторые архитектурные идеи я пока не могу реализовать. Например, пришлось экстренно решать вопрос с приемом платежей на soer.pro, по-хорошему можно было сделать нормально функционирующий сервисно-ориентированный платежный шлюз, который далее использовать и для xdonate и для soer.pro. Но время заставляет делать на скорую руку. Стандартная боль стартапов. Правда, это позволит в будущем показать как разруливать такие ситуации и эволюционировать в сторону нормальных архитектур.
Но теперь у меня будет моноаккаунт в телеге. Здесь и посты, и видео, и размшления. И что самое важное - общение по OpenSource проектам.
- Сейчас у меня уже вложен черновик (потому что пока проектом я стесняюсь эту поделку назвать) OBSOverlay - https://github.com/soerdev/obsoverlay
- Кроме этого фронтовая часть сайта soer.pro - https://github.com/soerdev/soer
Последний, кстати, это как раз пример того, что я буду двигать на канале и для патронов - пример полноценной реактивной архитектуры и разработки на базе монорепозитория.
Монорепо - потому что я "маленький", т.е. у меня нет команды и все приходится делать самому, а монорепо помогает снизить издержки.
Некоторые архитектурные идеи я пока не могу реализовать. Например, пришлось экстренно решать вопрос с приемом платежей на soer.pro, по-хорошему можно было сделать нормально функционирующий сервисно-ориентированный платежный шлюз, который далее использовать и для xdonate и для soer.pro. Но время заставляет делать на скорую руку. Стандартная боль стартапов. Правда, это позволит в будущем показать как разруливать такие ситуации и эволюционировать в сторону нормальных архитектур.
👍76🔥12
Проблема построения архитектуры приложений заключается в том, что устоявшейся теории не существует. Одни и те же идеи у разных авторов могут называться по-разному, так например гексагональная архитектура и порты адаптеры - это одно и то же, но описаны в разных источниках. Поэтому когда речь заходит про архитектуру - это всегда поле для самых жестких холиваров. Не претендуя на абсолютную истину я считаю про архитектуру нужно говорить, причем как можно больше. Систематизировать разрозненный материал из разных источников и приводить в единую систему. Это работа не для одного человека, но ее нужно кому-то делать.
В этом посте я хочу отметить некоторые моменты касающиеся реактивности и интерактивности, тут тоже есть разные взгляды. Кто-то считает, что реактивность - частный случай интерактивности, я считаю, что это два разных подхода.
Хорошее дополнение, на мой взгляд, которое добавить к видео - это указать, что интерактивная архитектура - больше похожа на набор компонентов, функционирующих по принципу "один к одному", мы можем объединять такие компоненты в композицию или каскады, но всегда из сложной композиции можно выделить пару компонентов, которые взаимодействуют друг с другом, где один будет источником действия, второй приемником.
Реактивная же архитектура больше похожа на стриминг, где компоненты работают по принципу "один ко многим". Частным случаем такой архитектуры будет когда "множество" состоит из одного компонента, и это будет похоже на "один к одному", но при этом жесткого зацепление между парой компонент все равно не будет. И расширить количество компонентов можно будет не меняя архитектуру.
Поэтому реактивная архитектура гораздо гибче в плане роста в ширину, новые компоненты могут быть самостоятельными и незацепленными на другие компоненты. Но так же требует более мощных средств управления компонентами (речь про механизмы оркестрации или хореографии).
Поэтому архитектор выбирая тот или иной вариант архитектуры должен исходить из того, что интерактивная архитектура гораздо проще реализуется на старте, расширяется за счет усложнения композиции и довольно быстро растет сложность сопровождения (лес зависимых компонентов), а реактивная архитектура значительно сложнее на старте, но сложность управления практически не меняется при увеличении компонентов (т.е. сложность добавления нового компонента линейна, если время на добавление одного компонента - Х, то на 10 компонентов понадобится 10Х).
В этом посте я хочу отметить некоторые моменты касающиеся реактивности и интерактивности, тут тоже есть разные взгляды. Кто-то считает, что реактивность - частный случай интерактивности, я считаю, что это два разных подхода.
Хорошее дополнение, на мой взгляд, которое добавить к видео - это указать, что интерактивная архитектура - больше похожа на набор компонентов, функционирующих по принципу "один к одному", мы можем объединять такие компоненты в композицию или каскады, но всегда из сложной композиции можно выделить пару компонентов, которые взаимодействуют друг с другом, где один будет источником действия, второй приемником.
Реактивная же архитектура больше похожа на стриминг, где компоненты работают по принципу "один ко многим". Частным случаем такой архитектуры будет когда "множество" состоит из одного компонента, и это будет похоже на "один к одному", но при этом жесткого зацепление между парой компонент все равно не будет. И расширить количество компонентов можно будет не меняя архитектуру.
Поэтому реактивная архитектура гораздо гибче в плане роста в ширину, новые компоненты могут быть самостоятельными и незацепленными на другие компоненты. Но так же требует более мощных средств управления компонентами (речь про механизмы оркестрации или хореографии).
Поэтому архитектор выбирая тот или иной вариант архитектуры должен исходить из того, что интерактивная архитектура гораздо проще реализуется на старте, расширяется за счет усложнения композиции и довольно быстро растет сложность сопровождения (лес зависимых компонентов), а реактивная архитектура значительно сложнее на старте, но сложность управления практически не меняется при увеличении компонентов (т.е. сложность добавления нового компонента линейна, если время на добавление одного компонента - Х, то на 10 компонентов понадобится 10Х).
👍76❤10