Size: a a a

Архитектура ИТ-решений

2020 August 25

S

Sdobridnuk in Архитектура ИТ-решений
😂
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
На самом деле скорее - контролировать состояние, чем управлять.

Оркестрация вызывает ощущение контроля.

При хореографии машина что-то там делает сама по себе.
источник

I

Ivan in Архитектура ИТ-решений
Gennadiy Kruglov
Машины состояний, которые можно представить в виде направленного ацикличного графа идеально строить с помощью хореографии. Потому что как только появляются циклы, в том числе из-за компенсаций, появляется необходимость в оркестраторе, иначе управлять состоянием становится очень сложно.

В одном из проектов мы даже нарабатывали навык "спрямления" процессов в ацикличные графы.
Кстати, в последней книге Сэм Ньюмана, которую недавно вспоминали, он рассматривает еще и комбинированные САГА-транзакции, внутри команды (team) - оркестровые, ибо дешевле сопровождать, а между командами - хореографические, чтобы меньше coupling и не нарушать автономности команд.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
Кстати, в последней книге Сэм Ньюмана, которую недавно вспоминали, он рассматривает еще и комбинированные САГА-транзакции, внутри команды (team) - оркестровые, ибо дешевле сопровождать, а между командами - хореографические, чтобы меньше coupling и не нарушать автономности команд.
Да. @dphil выше кстати примерно тоже самое и сказал) только на другом уровне
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
Кстати, в последней книге Сэм Ньюмана, которую недавно вспоминали, он рассматривает еще и комбинированные САГА-транзакции, внутри команды (team) - оркестровые, ибо дешевле сопровождать, а между командами - хореографические, чтобы меньше coupling и не нарушать автономности команд.
Ты уже успел прочитать?)
источник

I

Ivan in Архитектура ИТ-решений
Gennadiy Kruglov
Ты уже успел прочитать?)
Нет. Просто был какой-то вопрос по работе, я этот эпизод почитал у него.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
САГИ-оркестратратры и САГИ-хореографы хорошо у Ричардсона описаны.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
Нет. Просто был какой-то вопрос по работе, я этот эпизод почитал у него.
Подумал, что скорочтение, которым я не владею)
источник

I

Ivan in Архитектура ИТ-решений
Gennadiy Kruglov
Подумал, что скорочтение, которым я не владею)
😂 , да нет, она у меня уже несколько месяцев лежит, я эпизодически к ней обращался))
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ivan
😂 , да нет, она у меня уже несколько месяцев лежит, я эпизодически к ней обращался))
А у меня уже почти новый комплекс образовался))
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ivan
Кстати, в последней книге Сэм Ньюмана, которую недавно вспоминали, он рассматривает еще и комбинированные САГА-транзакции, внутри команды (team) - оркестровые, ибо дешевле сопровождать, а между командами - хореографические, чтобы меньше coupling и не нарушать автономности команд.
Ну, я еще и не верю в саги - так как "обратимость операции" гораздо сложнее в реализации, нежели "слабая идемпотентность".
А сага предполагает, что все операции обратимые (теоретически).
источник
2020 August 26

S

Sdobridnuk in Архитектура ИТ-решений
Наверное это про 'абсолютную сагу' так можно сказать, которая может откатиться абсолютно в исходную точку. А на деле приходилось встречать и аргумент ' но мы же столько уже всего сделали, зачем же все откатывать' с просьбой сделать кнопочку с ручным режимом финализации в стиле' и так сойдет' . Или учесть, что имея граф с неограниченным числом переходов по одному и тому же ребру, мы получаем алгоритмически недетерминированный результат. Т.е. мы и теоретически и реально можем придти к тупику с разрушенный консистентостью и отсутствием выхода. Получается и в этом случае надо иметь 'кнопочку' чтобы решить проблему системы выйдя за рамки системы. Скажем решить проблему технической ошибки организационные путем, например простить ошибочно расчитанную комиссию.. Вместо того чтобы долго и муторно искать ту микросекунду и данные, которые привели к спорадическому сбою.  Кстати и Машина Тьюринга базовоя теория современных языков программирования имеет случаи алгоритмического недетерминизма, не надо питать иллюзий. Это например кейс с 'бесконечным циклом'
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sdobridnuk
Наверное это про 'абсолютную сагу' так можно сказать, которая может откатиться абсолютно в исходную точку. А на деле приходилось встречать и аргумент ' но мы же столько уже всего сделали, зачем же все откатывать' с просьбой сделать кнопочку с ручным режимом финализации в стиле' и так сойдет' . Или учесть, что имея граф с неограниченным числом переходов по одному и тому же ребру, мы получаем алгоритмически недетерминированный результат. Т.е. мы и теоретически и реально можем придти к тупику с разрушенный консистентостью и отсутствием выхода. Получается и в этом случае надо иметь 'кнопочку' чтобы решить проблему системы выйдя за рамки системы. Скажем решить проблему технической ошибки организационные путем, например простить ошибочно расчитанную комиссию.. Вместо того чтобы долго и муторно искать ту микросекунду и данные, которые привели к спорадическому сбою.  Кстати и Машина Тьюринга базовоя теория современных языков программирования имеет случаи алгоритмического недетерминизма, не надо питать иллюзий. Это например кейс с 'бесконечным циклом'
Вариант "ручного" восстановления консистентности нужно учитывать всегда, особенно есть помнить про RPO, которое практически никогда не бывает нулевым в катастрофоустойчивых решениях.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Sdobridnuk
Наверное это про 'абсолютную сагу' так можно сказать, которая может откатиться абсолютно в исходную точку. А на деле приходилось встречать и аргумент ' но мы же столько уже всего сделали, зачем же все откатывать' с просьбой сделать кнопочку с ручным режимом финализации в стиле' и так сойдет' . Или учесть, что имея граф с неограниченным числом переходов по одному и тому же ребру, мы получаем алгоритмически недетерминированный результат. Т.е. мы и теоретически и реально можем придти к тупику с разрушенный консистентостью и отсутствием выхода. Получается и в этом случае надо иметь 'кнопочку' чтобы решить проблему системы выйдя за рамки системы. Скажем решить проблему технической ошибки организационные путем, например простить ошибочно расчитанную комиссию.. Вместо того чтобы долго и муторно искать ту микросекунду и данные, которые привели к спорадическому сбою.  Кстати и Машина Тьюринга базовоя теория современных языков программирования имеет случаи алгоритмического недетерминизма, не надо питать иллюзий. Это например кейс с 'бесконечным циклом'
Угу, в реальной жизни обычно стратегия "дожать" удобнее, нежели "откатить". И "откатить" обычно или в очень специальных местах или в виде "упасть, пусть живой человек разбирается". Но это уже не совсем про паттерн сага )
источник

AZ

Anton Zhbankov in Архитектура ИТ-решений
Gennadiy Kruglov
Вариант "ручного" восстановления консистентности нужно учитывать всегда, особенно есть помнить про RPO, которое практически никогда не бывает нулевым в катастрофоустойчивых решениях.
Смелое заявление
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Anton Zhbankov
Смелое заявление
В каком смысле?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
RPO де-факто редко бывает нулевым, хотя конечно хочется чтобы оно было нулевым. Есть законы физики правда, данные тупо могут не доехать между геораспределёнными ЦОДами при наличии значимых задержек
источник

AZ

Anton Zhbankov in Архитектура ИТ-решений
В самом прямом смысле. Синхронная репликация и метрокластеры - это RPO = 0
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Только тут производительности никакой...
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Да
источник