Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>У самодельного нет ни одного плюса. Хуже того, людей способный более менее сносно реализовать очередь — по пальцам одной руки.
S>>А в чем тут rocket science?
НС>В HA у stateful сервиса и прочих распределенных вещах.

HA и statefull -- это cassandra? Rmq сюда не подходит?

Здравствуйте, Sharov, Вы писали:

НС>>>>У самодельного нет ни одного плюса. Хуже того, людей способный более менее сносно реализовать очередь — по пальцам одной руки.
S>>>А в чем тут rocket science?
НС>>В HA у stateful сервиса и прочих распределенных вещах.
S>HA и statefull -- это cassandra? Rmq сюда не подходит?

Не понимаю о чем ты. HA и stateful это любая приличная очередь. В том числе и rmq.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>HA и statefull -- это cassandra? Rmq сюда не подходит?
НС>Не понимаю о чем ты. HA и stateful это любая приличная очередь. В том числе и rmq.

Пардон, думал у rmq нету кластеров.

Здравствуйте, Sinclair, Вы писали:

F_>>Но в реальности требуется статически доказать что они действительно 100% CA, так как во всех виденных мной системах была масса не очевидных на первый взгляд путей через граф их состояния, которые приводили к потере либо C либо A. Хотя все такие пути ну очень маловероятны, но их большое количество и склонность корреляции приводили к снижению С и A где-то до 95% от вероятности аварии.
S>Хотелось бы понять, как именно вы придаёте численные значения метрикам С и P.
S>Если с A всё понятно, то что такое C=80%, или P=51%?

Конечно в самой кап теореме этого нет. Поскольку она описывает математическую абстракцию в дискретном мире. Но задачка математически определить эти коэффициенты любопытная. Смог придумать два определения. Одно простое и понятное, но к сожалению, совершенно неправильное и на практике неприменимое. Второе боле-менее правильное и применимое на практике, но немного сложное.

Первое описание: кап теорема описывает абстрактную систему, в которой есть всего одно состояние, и в которой есть всего один тип связи, и которая может сломаться одним единственным способом. Реальная система имеет множество состояний, и много типов связей, которые нарушаются множеством различных способов. Такую систему можно представить, как составленную из множества систем подчиняющихся CAP теореме. Каждая из этих подсистем не обязана вести себя одинаково. Некоторые могут быть AP, некоторые CP, некоторые СА. Так как эти подсистемы взаимодействуют на границе их взаимодействия буду присутствовать системы, имеющие только одну букву. Например, на границе недоступной системы (CP) и некосистентной (АP) будет присутствовать система, которая одновременно недоступна, и некосистентна (только P). Посчитав отношение количества подсистем, которые являются доступными к общему количеству подсистем мы найдем коэффициент A. Также поступим для остальных континентов.

Это совершено неправильно с математической точки зрения, зато понятно.

Вот более правильное объяснение, которое еще и практически применимо. Я постарался обойтись только теорией конечных автоматов. Думаю, все программисты ее хорошо знают:

Представим узел нашей системы Ak виде конечного автомата (A: actor), у которого есть множество возможных состояний Sk (S: state). Акторов в системе k=[1.. ∞). На каждом шаге, n, ленты Ak производит символ rk (r: responce) принадлежащий алфавиту (множеству) R ответов пользователю, зависящее только от входящего символа, и текущего состояния rk=f(Sk,ik). Алфавит R включает пустой элемент (r0), который означает что на этом шаге у A нет ответа пользователю. Поскольку мы имеем дело с распределенной системой, то кроме ответов пользователю, A на каждом шаге производит сообщение для каждого k узла системы mk эти сообщения собраны в упорядоченную последовательность mOk=(m1,m2,…, mk) (кортеж Message Output). Таким образом выходной алфавит A состоит из упорядоченной пары символов (r, mO). Для каждого A существует бесконечный автомат N (N: network). N принимает упорядоченную пару из символов L=[1..∞) (L: Latency) и mO от всех A. Nk возвращает символ mik (message input) который равен кортежу из символов mOk для узла Ak, полученный на шаге n-L. Входящий символ конечного автомата Ak принадлежит алфавиту, представлявшему собой кортеж из трех символов (mik, qk, ek). Символ q (Q, query) принадлежит алфавиту Q запросов пользователя. Символ e (E: Event) событие которое случилось с нашим актором. Событие принадлежит множеству E состоящему из таких событий как истечение таймаута, перезагрузка узла, удаление базы узла, изменение настроек узла и т.п. Акторы Ak и Nk можно представить виде единого бесконечного автомата (актора) Gk (G: Grap node) принимающего на вход ленту Tk (tape) из кортежей (qk, ek, Lk) и возвращающего символ rk. Информационную систему состоящею из акторов G1, G2, …, Gk можно представить в виде бесконечного автомата r=G(s,t) принимающему символ t из алфавита виде кортежа T=(T1, T2, …, Tk) и возражающую кортеж символов r=(R1, R2, …, Rk) и имеющий состояние виде кортежа (S1,S2,..,Sk).

Применив ко множеству всех входных сообщений, актор G находящий в начальном состоянии s0. Мы получим множество состояний S1 достижимых на первом шаге ленты. Мы можем представить их в виде направленного графа состоящего из дуг (s0, G(s0,t)). Продолжая процесс рекурсивно бесконечное число раз, мы получим направленный слабый граф всех достижимых состояний SR (state, reachable) информационной системы G. Все возращённые в ходе обхода графа ответы являются множеством достижимых ответов RR. Мы будем рассматривать только детерминированные актёры, у которых мощность множества RR меньше максимальной комбинаторной мощьности Q (=Σ(i=1..|Q|) |Q|!*|Q-i|/i!*(|Q|-i)!), для |Q|=2 |RR|<=5. Используя цепи Маркова и зная вероятность события E мы можем получить вероятность попадания в каждое состояние sr.
Чтобы проанализировать CAP теорему наложим на нашу систему следующие ограничения. Для простоты, число возможных запросов пользователя, то есть мощность множества Q двумя.
CAP теорема рассматривает только системы в состоянии аварии по разделению. Пути в графе SR где возникала изоляция актора Ai (isolated actor) от как минимум одного актора Ax x ∈ 1, 2, ..,k; x≠i. Тесть значения Lx этих акторов, увеличивалось по сравнению с предыдущим шагом). Назовём такие состояния в SR партиционированными. Все возможные пути, исходящие из партиционированного состояния непрерывно проходящие через состояния, в которых сохранялось партиционирование, назовем партиционированными путями выполнения. Если в течении партиционированного пути выполнения, на актор Ax поступил запрос Q1 и при этом он не поступал ранее, назовем такой путь подчиняющимся CAP теореме или CAP путем. Если на пути подчиняющимся CAP теореме любой из актеров возвратил ответ R связанный с запросом Q1 то такой путь мы будем называть путем где сохранилась доступность. Коэффициент доступности будет равен суммарной вероятности попадания на пути где сохранилась доступность по отношению суммарной вероятности попадания на CAP путь. Если мощность RR на всех путях, исходящих из SR принадлежащего CAP пути меньше пяти то такой CAP путь мы будем называть консистентным.Это возможно если запросы Q1 и Q2 обрабатывались акторами в одном порядке, или запросы не связаны (результат не зависит от порядка их обработки). Коэффициент консистентной равен суммарной вероятности попадания на консистентные пути по отношению к общей вероятности попадания на CAP путь. Коэффициент устойчивости разделению – это средний процент узлов, которые были доступны, в путях где сохранилась доступность. Легко проверить численными методами что для любого конечного автомата, у которого операции связаны (результат операций зависит от последовательности их поступления) сумма коэффициентов меньше или равна двум.

Тут наверняка есть куча косяков. Так как люди, которые могу написать такое определение правильно, работают в гугле за много бабок, а не формочки в банке клепают. Но у меня есть железная отмазка. Я писал это доказательство в пятницу вечером . А последнюю его часть вообще глубокой ночью. Но буду благодарен за указания на эти косяки.

PS Из такого определения следует несколько важных выводов. Первый что если запросы пользователя не взаимодействую, или можно сделать чтобы они не взаимодействовали на каком-то отрезке графа, то мы можем получить все три буквы СAP. Кап теорема вообще не применима к системам со случайным поведением. Оба этих свойства очень интересны с точки зрения проектирования криптовалют третьего поколения.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Finder_b, Вы писали:

F_>>В реальном приложении разделение кода и настроек workflow вливается в нереальный ад, поскольку при любом значимом изменении в коде, требeуется задеплоить workflow одновременно новыми шагами. Это не возможно, по этому возникает необходимость многофазных деполев, с копипастой изменяемого кода — чтобы получить одновременно старую и новую версию шага. При том ад начинается еще до первого релиза. По этому сейчас от концепции динамически-конфигурируемых воркфло уходят.

НС>В текущей компании опыт строго противоположный. Старый продукт как раз как ты описываешь — WF прошиты в коде. На практике это вылилось в реальный show stopper для бизнеса, даже прикрученные возможности дописывать на JS правила в определенных точках не особо спасают.
НС>Ты забываешь один немаловажный момент. Иногда цепочка вендор:конечный пользователь чуть длиннее. И там есть всякие 3d party в середине. Которым, к примеру, возможность чего то деплоить в публичный сервис принципиально недоступна.

Полностью согласен. Если нет возможности деплоить приложение в прод хотя бы раз в неделю, возможность править настройки workflow через базу становится совершено необходимой. Я об этом даже писал где-то выше по треду. Но следует учесть что настройки workflow это такой-же код, как и любой другой. Просто написан на специфическом языке программирования. И если есть возможность выкладывать в базу новые настроки workflow, то значит можно точно также выкладывать патчи на приложение. Такие ограничения носят чисто административный характер. Обычно это связанно с плохо-поставленым процессом тестирования, или не использованием практик канареечного тестирования и blue-green deploement. По этому прослойки по средине и начинают городить бюракратию, чтобы как-то защитить своих пользователей, путем канареечного деплоя для пользователей не принадлежащих этой прослойке. Но иногда бюрократия самозарождается, без всяких на то причин. И тогда программистам приходится страдать .

Здравствуйте, Finder_b, Вы писали:

F_>Но следует учесть что настройки workflow это такой-же код, как и любой другой. Просто написан на специфическом языке программирования. И если есть возможность выкладывать в базу новые настроки workflow, то значит можно точно также выкладывать патчи на приложение. Такие ограничения носят чисто административный характер.

Ты, кажется, меня не понял. Еще раз — бывает так, что те люди, которые пишут код, и те люди, которые рисуют воркфлу — это совсем разные люди из разных компаний. И если первые что то пишут на Java, C#, Go или, не приведи господь, на С++, то вторые ничего такого не знают и не умеют. Зато они знают про свой бизнес и свои документы, и умеют настраивать процесс обработки в UI. И совершенно неважно с какой частотой ты можешь деплоить изменения, хоть каждый час.
Low code/no code — слышал про такое? Так вот в связанных с WF областях это сейчас мейнстрим, а вот жестко нарезанные программистами заранее WF — исключение.
Это я, кстати, еще про онпрем не вспоминал.

Здравствуйте, Finder_b, Вы писали:

F_>Полностью согласен. Если нет возможности деплоить приложение в прод хотя бы раз в неделю, возможность править настройки workflow через базу становится совершено необходимой. Я об этом даже писал где-то выше по треду. Но следует учесть что настройки workflow это такой-же код, как и любой другой. Просто написан на специфическом языке программирования. И если есть возможность выкладывать в базу новые настроки workflow, то значит можно точно также выкладывать патчи на приложение. Такие ограничения носят чисто административный характер. Обычно это связанно с плохо-поставленым процессом тестирования, или не использованием практик канареечного тестирования и blue-green deploement. По этому прослойки по средине и начинают городить бюракратию, чтобы как-то защитить своих пользователей, путем канареечного деплоя для пользователей не принадлежащих этой прослойке. Но иногда бюрократия самозарождается, без всяких на то причин. И тогда программистам приходится страдать .
Все верно, настройки это такой же код. Однако важно, кто этот код пишет и деплоит.
И очевидно, что код который заточен под один специфический сценарий, например, описание правил или воркфлоу, имеет гораздо более низкий порог вхождения, его намного проще тестировать и валидировать, а в идеале можно выразить вообще графически, что существенно облегчит жизнь всем участникам процесса.
У меня сейчас тоже подход — "это тоже код, пусть разрабы пишут" + "ну и фиг с ним, аналитиков кодить научим", при отсутствии проблем с деплоем, вылился в полную фрустрацию бизнеса. Причина в том, что разработчики с аналитиками код новых правил писать не успевают, в итоге они в виде спецификаций попадает к внешнему подрядчику, который имплеминтирует правила в виде кода и деплоит на что уходит несколько дней, а в идеале нужно писать несколько правил в день, а то и несколько десятков. То есть, создание конфигураций стало узким местом ровно потому, что используется обычный код, со всеми плюсами и минусами.

Здравствуйте, vsb, Вы писали:

vsb>1. Использовать полновесный сервер очередей. Сто лет назад я работал с websphere mq. Наверное сейчас есть получше что-нибудь. Суть в том, что сервисы вместо того, чтобы дёргать друг друга, кладут нужные данные в очередь и забывают про это. Будем считать, что очередь работает всегда и данные в ней никогда не теряются. А принимающий сервис из очереди достаёт данные, обрабатывает, если не получилось обработать, то откатывает транзакцию и данные остаются в очереди, достаём следующие данные и тд.

На практике данные, естественно, теряются. Стандартный дизайн для надежной предачи данных из палок и желудей — положить данные в РСУБД, пульнуть нотификацию через какой-нибудь 0mq, с другой стороны принять нотификацию и забрать данные. А для того чтобы пережить временную недоступность сервисов, использовать heartbeat.

vsb>2. Использовать легковесный сервер очередей, что-то вроде kafka. С ней я толком не работал, но представляю это так: в очередь кладём не данные, а только id. На отдающем сервере делаем endpoint, который по этому id отдаёт данные. Принимающий сервер вытаскивает id, а данные вытаскивает уже из отдающего сервиса по этому id. Этот вариант нравится чуть больше, но в целом тоже полагаемся на то, что сервер очередей работает 100% надёжно, не уверен, что kafka этому соответствует.

Через кафку можно пересылать сами данные, причем кафка это чуть ли не единственный сервер очередей гарантирующий, что данные не потеряются где-то по дороге.

vsb>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.

Оно примерно так и есть. Значительная часть сложности системы ("сложности", в Холмогоровском смысле) находится не в коде, а в оркестрации сервисов. Из готовых решений для "оркестрации мышкой" могу предложить только AWS. Но с ней лучше не связываться без сертифицированного архитектора, знающего ограничения и возможности амазонвских сервисов.

Здравствуйте, Miroff, Вы писали:

M>Оно примерно так и есть. Значительная часть сложности системы ("сложности", в Холмогоровском смысле) находится не в коде, а в оркестрации сервисов. Из готовых решений для "оркестрации мышкой" могу предложить только AWS. Но с ней лучше не связываться без сертифицированного архитектора, знающего ограничения и возможности амазонвских сервисов.

AWS к сожалению не вариант, данные должны храниться и обрабатываться в Казахстане, а в Казахстане нет ни одного приличного облака, только самопальные кубернетесы на VPS.

Здравствуйте, Finder_b, Вы писали:

F_>Применив ко множеству всех входных сообщений, актор G находящий в начальном состоянии s0. Мы получим множество состояний S1 достижимых на первом шаге ленты. Мы можем представить их в виде направленного графа состоящего из дуг (s0, G(s0,t)). Продолжая процесс рекурсивно бесконечное число раз, мы получим направленный слабый граф всех достижимых состояний SR (state, reachable) информационной системы G. Все возращённые в ходе обхода графа ответы являются множеством достижимых ответов RR. Мы будем рассматривать только детерминированные актёры, у которых мощность множества RR меньше максимальной комбинаторной мощьности Q (=Σ(i=1..|Q|) |Q|!*|Q-i|/i!*(|Q|-i)!), для |Q|=2 |RR|<=5. Используя цепи Маркова и зная вероятность события E мы можем получить вероятность попадания в каждое состояние sr.
F_>Чтобы проанализировать CAP теорему наложим на нашу систему следующие ограничения. Для простоты, число возможных запросов пользователя, то есть мощность множества Q двумя.
F_>CAP теорема рассматривает только системы в состоянии аварии по разделению. Пути в графе SR где возникала изоляция актора Ai (isolated actor) от как минимум одного актора Ax x ∈ 1, 2, ..,k; x≠i. Тесть значения Lx этих акторов, увеличивалось по сравнению с предыдущим шагом). Назовём такие состояния в SR партиционированными. Все возможные пути, исходящие из партиционированного состояния непрерывно проходящие через состояния, в которых сохранялось партиционирование, назовем партиционированными путями выполнения. Если в течении партиционированного пути выполнения, на актор Ax поступил запрос Q1 и при этом он не поступал ранее, назовем такой путь подчиняющимся CAP теореме или CAP путем. Если на пути подчиняющимся CAP теореме любой из актеров возвратил ответ R связанный с запросом Q1 то такой путь мы будем называть путем где сохранилась доступность. Коэффициент доступности будет равен суммарной вероятности попадания на пути где сохранилась доступность по отношению суммарной вероятности попадания на CAP путь. Если мощность RR на всех путях, исходящих из SR принадлежащего CAP пути меньше пяти то такой CAP путь мы будем называть консистентным.
Не вполне понял, откуда взялась константа 5.
F_>Это возможно если запросы Q1 и Q2 обрабатывались акторами в одном порядке, или запросы не связаны (результат не зависит от порядка их обработки). Коэффициент консистентной равен суммарной вероятности попадания на консистентные пути по отношению к общей вероятности попадания на CAP путь. Коэффициент устойчивости разделению – это средний процент узлов, которые были доступны, в путях где сохранилась доступность. Легко проверить численными методами что для любого конечного автомата, у которого операции связаны (результат операций зависит от последовательности их поступления) сумма коэффициентов меньше или равна двум.
Интересный подход. Что-то подобное, кмк, я встречал в работах по распределённым алгоритмам.
Сходу не соображу, как его применить — реальные системы имеют довольно-таки большое пространство состояний; как за обозримое время выполнить предлагаемую вами свёртку мне непонятно.
Я попробовал другой подход — берём метрику согласованности, которая специфична для нашей прикладной задачи; берём модель кластера, которая реализует точный или "оптимистичный" вариант консенсуса. Берём псевдослучайное расписание сбоев (разделений сети). Берём некий набор клиентских запросов — и смотрим, как ведёт себя система, путём выполнения относительно большого количества экспериментов.

F_>Тут наверняка есть куча косяков. Так как люди, которые могу написать такое определение правильно, работают в гугле за много бабок, а не формочки в банке клепают. Но у меня есть железная отмазка. Я писал это доказательство в пятницу вечером . А последнюю его часть вообще глубокой ночью. Но буду благодарен за указания на эти косяки.

F_>PS Из такого определения следует несколько важных выводов. Первый что если запросы пользователя не взаимодействую, или можно сделать чтобы они не взаимодействовали на каком-то отрезке графа, то мы можем получить все три буквы СAP. Кап теорема вообще не применима к системам со случайным поведением. Оба этих свойства очень интересны с точки зрения проектирования криптовалют третьего поколения.
Тут не всегда легко понять, где взаимодействуют, а где — нет.
Ну, вот например запрос на пополнение счёта никак не зависит от всех предыдущих запросов, поэтому его не обязательно обрабатывать через кворум. Чисто так, достаточно подтверждения от небольшого количества узлов, чтобы избежать потери durability при необратимом сбое носителя.
А вот запросы на списание сильно зависят от всех предыдущих запросов. При разделении сети можно легко получить несколько историй, которые локально корректны, но при слиянии нарушают согласованность.
Запросы на списание/пополнение разных счетов в целом коммутативны; но они могут стать некоммутативными, если мы включим в транзакцию перевод с одного счёта на другой.