Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.

Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать. Поэтому в первом сервисе заводим статус service_2_sent, заводим cron job, который делает select по этому статусу и допуливает данные во второй сервис. То же делаем во 2 сервисе. В итоге у нас целая куча cron job-ов, всё асинхронно пуляется туда-сюда, в бд куча статусов, в общем всё сложно. Ещё нет наглядности, когда что-то не работает, приходится лазить по сервисам, базам, логам и тд.

Чувствую, что есть какой-то способ сделать всё нормально, т.к. текущая ситуация не очень приятная. Помимо прочего на каждом шаге теряется время, в итоге в системе куча искусственных задержек, что не критично, но и не совсем хорошо.

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

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

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

3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд. Тогда мне это не понравилось, показалось, что сову натянули на глобус. Но может быть тот движок был плох, сейчас мне кажется, что такой подход был бы хорош. В моём понимании надо нарисовать бизнес-процесс, движок должен отслеживать статусы, повешать вызовы, например rest-методов на переходы, движок должен отслеживать fails, а также рисовать красивый интерфейс, в котором можно найти конкретную сущность и связанный с ней граф и посмотреть, на каком шаге оно находится, какие ошибки произошли. Прописывать правила retry, удлинение времени вызова и всё такое.

Пункт 3 не нравится тем, что на такой движок всё будет завязано и его ограничения могут вылиться в боль. Менеджмент предлагает использовать airflow в виде такого движка.

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

По-моему направление верное. Общение между сервисами надо организовывать сообщениями, а не request-response. Всё очень упрощается.
websphere mq — и аналоги это по-моему жуткий монстр, прошлый век.

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

vsb> Принимающий сервер вытаскивает id, а данные вытаскивает уже из отдающего сервиса по этому id. Этот вариант нравится чуть больше, но в целом тоже полагаемся на то, что сервер очередей работает 100% надёжно, не уверен, что kafka этому соответствует.
Кафка надёжен, но надо внимательно разобраться как правильно организовывать надёжный кластер, но это не рокет-сайненс, разобраться можно. Его можно использовать даже в виде своебразной базы данных, как постоянное хранилище.
Единственный тонкий момент, что он не предназначен для посылки массивных сообщений. По дефолту максимальный размер сообщений около 1мб. Оптимально лучше, если сообщение порядка килобайт. Если у тебя всё укладывается в такие ограничения, то всё круто.
Если тебе нужно передавать большие порции данных, то тут два варианта:
— упомянутый тобой id+отдельное хранилище (можно это назвать сообщение с аттачментами), это имеет смысл если сообщение содержит некий неделимый блоб (или несколько), ну видеоролик какой-нибудь многомегабайтный.
— либо разбивать массивные сообщения на более мелкие, это хорошо в случае если в данных есть какая-то структура. Напимер, вместо того, чтобы посылать 100тыс строк csv, ты посылаешь 100тыс сообщений на каждую строку.

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

vsb>Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать.
Как ещё один вариант — делать ha-сервисы. Т.е. обеспечивать чтобы сервисы работали всегда, через load balancer какой-нибудь запускать несколько инстансов. При падении одного инстанса запросы обрабатывают другие. При апгрейде — делать rolling update.
Преимущество — это можно сделать относительно просто если у тебя какой-нибудь REST везде. Недостаток — если один важный сервис таки упадёт, то всё может стать колом по цепочке.

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

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

·>По-моему направление верное. Общение между сервисами надо организовывать сообщениями, а не request-response. Всё очень упрощается.
·>websphere mq — и аналоги это по-моему жуткий монстр, прошлый век.

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

А почему все сразу нельзя передать, id + данные, если их не много?

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

vsb>>>2. Использовать легковесный сервер очередей, что-то вроде kafka. С ней я толком не работал, но представляю это так: в очередь кладём не данные, а только id. На отдающем сервере делаем endpoint, который по этому id отдаёт данные.
S>·> а если отдающий сервис в это время перестал быть доступным? Нужно отдельное хранилище организовать.
S>А почему все сразу нельзя передать, id + данные, если их не много?
Это я просто покритиковал сам подход "На отдающем сервере делаем endpoint". А так да, неясно тоже, почему он хочет передавать только id, про количество/характер данных из его слов ничего неизвестно.

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

vsb>Ещё нет наглядности, когда что-то не работает, приходится лазить по сервисам, базам, логам и тд.

Молодцы! Сэкономили на обозримости (observability). Здесь два аспекта.

Первый — метрик и уведомления (alerts). В частности, идут метрики по основному сценарию (успешно, неуспешно). И отдельно идут метрики по восстановлению (сколько элементов подняла задача восстановления, сколько из них успешно, сколько — нет). В центрах оперативного мониторинга (dashboards) обычно сразу видно, работает оно или нет. Выражается в виде пиков/возрастания ошибок для основного сценария (если поток большой — ошибки идут отдельным графиком). А также отличием от 0 метрик восстановления. И очень плохо, если восстановление не приходит в 0. На основе метрик потом делаются уведомления (alerts), прямо по тем же критериям — наличие/количество ошибок в основном сценарии, отсутствие 0 на восстановлении. Правда пока мало разработчиков умеет делать метрики, но это уже другая история.

Второе — централизованное логирование (centralized logging) и распределенное трассирование (distributed tracing). С этим ситуация в целом гораздо лучше. Есть много инструментов, разработчики и девопсы их знают. Распределенное трассирование обычно поддерживается для типичных сценариев фреймворками или библиотеками от прозиводителей коммерческих решений. Правда через границу восстановления (базу) контекст все равно вручную надо будет протаскивать. Инструменты визуализации при этом позволяют просмотреть логи запроса со всех сервисов в одном инструменте. Т.е. вы можете найти какое-то исключение, потом кликнуть на trace id и получить все остальные логи.

vsb>1. Использовать полновесный сервер очередей.
vsb>2. Использовать легковесный сервер очередей, что-то вроде kafka.

Вы зачем-то смешиваете две несвязные вещи.

Первая — что передавать. Можно передавать ID, можно передавать все сообщение (всю сущность/entity). Данное решение в общем случае не зависит от того, какой транспорт используется для передачи сообщений (есть ограничения на размер, но это редко является решающим фактором).

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

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

Ну да, оно и есть. Схему при желании можно сделать явной. Это нормально ложится на всякие REST API в виде "ваш запрос обрабатывается". Внутри сервиса "обрабатывается" может соответствовать нескольким вариантам (вызвали сервис A, ждем сервис Б и т.д.).

Еще практическое замечание. Двухфазный коммит и прочие инструменты надежности нужно делать всегда. Очередь может не работать. Например, закончился диск или нарушилась связность сети. Полагаться на абсолютную нажедность неправильно. В принципе, для многих приложений подходит "гибридный" механизм. Я обычно делаю сервис "гарантированной доставки" с использованием базы и очередей сообщений. "Послать сообщение" вызывается в рамках исходной транзакции, модифицирующей данные (кстати, вы подумали, что ваш сервис может быть безжалостно убит между записью в базу и отправкой сообщения?) и сообщение записывается в таблицу. По завершению транзации оно отправляется в очередь и затем из таблицы удаляется. Докатка/восстановление периодически смотрит таблицу и досылает сообщения. Основной плюс решения — не нужно дублировать код между различными сущностями. Есть и стандартный минус — потенциальное изменение порядка сообщений (reordering). Хотя обычно это не проблема — изменение порядка может быть вызвано разными причинами и правильные обработчики (и производительности) умеют делать версионирование данных.

vsb>Пункт 3 не нравится тем, что на такой движок всё будет завязано и его ограничения могут вылиться в боль. Менеджмент предлагает использовать airflow в виде такого движка.

Правильно! Боль будет. Решение может временно помочь с обозримостью (хотя исходную проблему остутствия инфраструктуры и практик кодирования не решит). И будет узким местом в пропускной способности (throughput), задержках (latency), оказоустойчивости (resilence/fault tolerance). Вот упадет этот движок (или база у него), что будете делать? И я не уверен, что через 5-10 лет у вас не появится куча сценариев, которые на движок никак не ложатся.

Я еще настроен против продуктов Apache. Во всех продукта, с которыми я работал, были какие-то страшные технические недоработки. Вплоть до архитектурного уровня. Поэтому прежде чем брать готовый продукт, я бы просил тестирование. Особенно тестирование сценариев отказов и восстановлений.

Судя по всему, вам вообще нужен кореец архитектор, который на этом деле собаку съел. Хотя-бы на начальное время. Соображения у вас правильные. Чтобы дать более конкретный совет, нужно изучать вашу организацию подробнее (продукты и план развития, команды). А пока у вас менеджеры пытаются принимать технические решения. Ничем хорошим это не закончится.

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

vsb>Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.
vsb>Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать.
Задача совершенно типовая и имеет два типовых решения.

1. Промежуточный сервис очередей. Изменение кладется в промежуточную очередь. Промежуточная очередь недостаточно стабильна, для гарантий репликации. По этому сами запросы, вызывающие изменения в сервисе тоже должны поступать через промежуточную очередь. Чтобы повторятся до тех пор, пока сервис не сумеет пропихнуть запрос дальше. Или внешний сервис должен гарантировать что будет повторять запрос, пока ему не ответят ок. Сейчас для этого обычно использую Kafka — так как другие очереди слишком тяжеловесны, и слишком ненадежны и плохо переваривают большие объекты.
   
2. Реализовать внутри сервиса конечный автомат, который гарантирует что при поступлении запроса выполнит все шаги связанные с запросами. Это все называется паттерном Saga. У него много вариаций, например паттерн Workflow. Есть готовые библиотеки, и свервисы реалзующи его. Но ни чего удобного для использования нет, по этому обычно копании вынуждены пилить свой велосипед.

Первый вариант значительно проще в реализации, но имеет ряд ограничений. Ключевых недостатков два — резкое возрастание латентности в обработке запросов, и очень сложно реализовать решение в парадигме запрос-ответ. Вообще вариант с очередью, хорошо работает, в тех случаях когда не нужно знать результаты обработки запроса. Это называет event-streaming. С некоторым опытом, примерно в 90% случаев, можно написать систему так, чтобы пользователю или сервису не будет нужен ответ. Например если пользователь постит сообщение в чатик, ему не нужно знать что сообщение уже размещено, достаточно написать что сообщение отправлено. В той же телеге, с начало сообщение без галочек (поставлено в очередь на отправку на клиенте), потом с галочкой (поставлено в очередь сервера), потом с двумя галочками (прочитано абонентом). Если требуется получать ответы на запрос, то все начинает превращаться в ад. Вариант с сагами лишен этих недостатков. То-есть латентность низкая, результаты обработки получаются легко, ответ внешнему абоненту дать еще проще. Хорошо подходит для сложных бизнес процессов, когда любой запрос проходит через десятки разных стадий, при этом на каждой следующей стадии используются результаты предыдущей. Но требует использования сложных библиотек, которые придется дорабатывать под конкретные потребности.


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

vsb>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

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

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

vsb>3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд.
Это реализации паттерна workflow. Но заточенные на другое. Раньше ими решали проблему того как быстро поправить бизнес процесс, если деплой приложения происходит один раз в два года. Я надеюсь у вас не так и вы можете деплоится хотябы раз в неделю? Ну и влажная мечта всех менеджеров — возможность нарисовать бизнес-просесс не привлекая программистов, что не осуществимо по определению — тот кто рисует бизнес процесс в компьютере и зовется программистом. Мой опыт говорит, что если нужен результат, то конфигурация Workflow должна деплоится строго вместе с приложением, и ни как иначе. Иначе разработка становится бесконечной и бессмысленной корпоративной работой без всякого результата на выходе. Желательно чтобы конфигурация Workflow была написана на том же языке программирования, на котором и остальной код.


vsb>Менеджмент предлагает использовать airflow в виде такого движка.
Airflow это и артефакт той эпохи, когда искренне верили что менеджеры смогут писать код рисуя красивые блок-схемы. Но его с тех пор сильно допилили, так что на нем вполне можно сделать то что вам нужно. Но я бы посоветовал поискать что-нибудь легковеснее. Сейчас опенсурсят по пять сага-фремворков в год. Лидер вроде как еще не определился. Я уверен что есть весьма достойные кандидаты.

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


vsb>>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
F_>Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
"Выберите 2 из 3".

vsb>>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
F_>Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа. Нормальные реализации паттерна Сага позволяют собрать это все в одно место, например в один класс.
vsb>>3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд.
F_>Это реализации паттерна workflow. Но заточенные на другое.

А чем в данном контексте state machine от workflow отличается?

F_>Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года.

Т.е. пропатчить dll с соотв. wf и отправить заказчику?

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

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


vsb>>>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
F_>>Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

S>А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
S>"Выберите 2 из 3".
Для очереди в бинес-приложени Сonsistency очень важно — его отсутствие означает как потерю сообщений так и их реордеринг. Остается A или P. Чистое CA и CP существуют лишь в математическом мире. Они обычно довольно бессмысленные в реальной системе. По тому что такая система будет рассыпаться от малейшего чиха, без возможности ее поднять. Обычно делают какую-то комбинацию из всех трех. Например, приложение в 80% аварий себя как CP и 5% аварий ведет себя как AP. Это классическая база данных с репликаций на стандбай, в другой датацентр. С подтверждением записи из другого датацентра при комите. Если связь между датацентрами рвется то админы отключат репликацию на стенбай. При этом С неизбежно теряется. При последующем отказе мастера, база стенбай уже не сможет вернуть тот-же ответ на запрос. Падения аплинка и базы одновременно не так маловероятно, как может показаться на первый взгляд, так как аварии сильно коррелирует, например из-за человеческого фактора. Формулу такой реальной базы данных можно написать так C:0.80 P:0.80 A:0.05 . 35% съедают не оптимальности реализации. Например админы могут случайно включить стендбай в продовый режим при разрыве связи. Провести некорректную смену мастера. Криво настроить сеть. В базе данных есть баги мешающее корректной репликации и тп. Вообще получить чистую CP систему можно только в идеальном математическом мире. Возможно получить 100% в Consistency. Я делал статическую валидацию кода, которая доказывала что программа обладает 100% Consistency. Но тот код который который проходил эту валидацию, я ни кому не пожелал бы увидеть в проде. Там одновременно использовалась теория графов, теория параллельных вычислений, дискретные топологи, event-soursing и теория акторов. Еще и элементы из блокчейна, связанные с нахождение целостности цепочки. Без блокчейна можно было обойтись, но это было забавно . Изначальный алгоритм, который я реализовывал, был в разы проще чем у кафки.

Таким образом поскольку мы не можем получить ста процентов на ни на A ни на P. Система будет плохо масштабироватся, и часто ломаться. Мы можем только управлять этими вероятностями. Хуже всего то, что иногда она будет ломаться при попытке масштабироватся. Что для программы, у которой не доказано что она 100% C, почти гарантированно приводит к потере Сonsistency. Что ведет нас к рердеренгу сообщений или их потере (в реальной системе обычно нет разницы что из двух произошло).

vsb>>>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
F_>>Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа.
F_>>Это реализации паттерна workflow. Но заточенные на другое.
S>А чем в данном контексте state machine от workflow отличается?
С математической точки зрения не чем не отличается. Они изоморфны друг-другу. То-есть помощью достаточного количества вложенных саг, можно реализовать любой workflow. С помощью достаточно сложного workflow можно описать любую сагу. Оба это частные случаи eventualy-consistensy конечного автомата. Я это различия понимаю так. Сага — это линейное последовательность шагов выполняемых строго один за другим, для каждого из которых на случай сбоя описан сценарий отката, который тоже состоит из линейной последовательности шагов. При реализации в лоб получается n*(n+1)/2 шагов. Workflow это полноценный граф состояний, в котором мы описываем в куда мы можем перейти из каждого состояния в каждом возможном случае. В случае если результат операции такой — переходим сюда, если второй переходим туда, если случалась ошибка1 в третье состояние, если ошибка2 то в четвертое. При том во многих концепциях мы еще и управляем данными которые получаем на каждом шаге. Это мягко скажем не правильно объяснение, зато простое и понятное .
Чистые саги как и чистые воркфло не кто не использует. Представь как прописывать сотни шагов отката для большой саги из чуть более десятка шагов, или сотни возможных переходов для такого же форквло. На такое извращение не способны даже суровые корпоративные программисты. По этому в реальности использую гибриды.

F_>>Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года.
S>Т.е. пропатчить dll с соотв. wf и отправить заказчику?
Нет воркфло хранились централизованно в базе данных в виде различных конфигов или в специальном сервисе который отдавал эти настройки. Конечно, в теории, код в виде конфигов ни чем не отличается от кода в виде текста на языке программирования. Практика показывает, что сломать его еще проще — тесты на конфиги я не видел не разу в жизни. Но в забюрократизированных компаниях согласовать обновление конфигурации гораздо проще чем обновление приложения. Хотя знал одну систему где критически к обновлению код хранился в блобах базы данных, в виде собраных модулей (class фалы java, загружались специальным класс-лоадром).

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

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

S>>А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
S>>"Выберите 2 из 3".
F_>Для очереди в бинес-приложени Сonsistency очень важно — его отсутствие означает как потерю сообщений так и их реордеринг. Остается A или P. Чистое CA и CP существуют лишь в математическом мире. Они обычно довольно бессмысленные в реальной системе.
F_>Таким образом поскольку мы не можем получить ста процентов на ни на A ни на P. Система будет плохо масштабироватся, и часто ломаться. Мы можем только управлять этими вероятностями. Хуже всего то, что иногда она будет ломаться при попытке масштабироватся. Что для программы, у которой не доказано что она 100% C, почти гарантированно приводит к потере Сonsistency. Что ведет нас к рердеренгу сообщений или их потере (в реальной системе обычно нет разницы что из двух произошло).


Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).

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

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

S>>>А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
S>>>"Выберите 2 из 3".
F_>>Для очереди в бинес-приложени Сonsistency очень важно — его отсутствие означает как потерю сообщений так и их реордеринг. Остается A или P. Чистое CA и CP существуют лишь в математическом мире. Они обычно довольно бессмысленные в реальной системе. По тому что такая система будет рассыпаться от малейшего чиха, без возможности ее поднять. Я делал статическую валидацию кода, которая доказывала что программа обладает 100% Consistency. Но тот код который который проходил эту валидацию, я ни кому не пожелал бы увидеть в проде.
F_>>Таким образом поскольку мы не можем получить ста процентов на ни на A ни на P. Система будет плохо масштабироватся, и часто ломаться. Мы можем только управлять этими вероятностями. Хуже всего то, что иногда она будет ломаться при попытке масштабироватся. Что для программы, у которой не доказано что она 100% C, почти гарантированно приводит к потере Сonsistency.
Я позволил себе вернуть часть поскипанного текста, важную для обсуждения.

S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
Я согласен с тобой — получить 100% CA возможно. Просто такая система получатся ну ооочень сложной, и крайне чувствительной к латентности сети. Если у нас P меньше 51% процента, то при стопроцентном C — то любая операция связная с конкурентным доступом, будет потребует не менее латентность*6 времени (*3 если за латентность считать время запрос-ответ). В реальной системе показатель даже хуже, из-за сложности получения математически оптимального результата и того что редко-кода удается обойтись одним конкурентным доступом. В системе которую разработал я, среднее время операции было в 24 раза больше латентности (p порядка 38%), а время гарантированного завершения 99.999% операций было вообще в двести с чем то раз больше латентности сети (значение рассчитано теоретически). По этому такой мейнфрейм может быть расположен только в одном датацентре, или в лучшем случае в одном городе. Что уже намекает что с A у нас не все порядке. При стопроцентном A мы должны мочь пережить отключение света в пределах всего одного города страны. И даже отключение света в одной стране должны пережить, но в России в связи с особенностью законодательства о персональных данных это не возможно. К тому-же непонятно как систему восстанавливать после того как авария с сетью произошла. При стопроцентном CA это выглядит ну очень затруднительной процедурой.

Из чудовищной сложности таких систем, процедур их обслуживания, и их общей тормазнутости — я сделал вывод что в реальном мире они не встречаются. Приношу извинения, это не некорректная генерализация. Допускаю что такие системы где-то действительно есть. Но в реальности требуется статически доказать что они действительно 100% CA, так как во всех виденных мной системах была масса не очевидных на первый взгляд путей через граф их состояния, которые приводили к потере либо C либо A. Хотя все такие пути ну очень маловероятны, но их большое количество и склонность корреляции приводили к снижению С и A где-то до 95% от вероятности аварии.

Статическая валидация маломальски-сложного алгоритма тоже не представляется возможным. К примеру я в свое время я разрабатывал криптовалюту, на строгом алгоритме синхронизации. До миллиона tps, удаление старых транзакций, время достижения полной согласованности сети 5-20 секунд, время достижения локальной согласованности 400 миллисекунд. С=1,A=0.30,P=0.30 в локальном сегменте сети P до 80% ценой длительной потери A с другими сегментами. В примитивном конечном автомате этой кроиптовалюты, если мне не изменят память, было полсотни состояний. Если исключить изоморфные (хз как правильно сказать, в общем приводимых к одному и тому же состоянию, путем эквивалентных преобразований). А теоретическое время ее полной статической валидации было 20 дней на весьма мощной машине. Даже та часть конечного автомата которую я успел реализовать (около 15 состояний) — валидировалась что-то около 15 секунд. К сожалению все заглохло, так как проект большой, а я не совершено не умею подорвать. Но ни сколько не сомневаюсь, что 20 дней на одной машине это крайне оптимистичная оценка. Теперь представьте мейнфрейм в котором миллиарды возможных состояний. Вы всерьез верите что хоть одни человек может проверить их в голове? Со статической валидаций таких алгоритмов ни кто вообще не заморачивается. Это критично для крипты, которую буду абузить, а не для менфрейма. По этом я не думаю что они 100% CA где-то кроме рекламных буклетов.

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

S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).

Так в этом и суть CAP — сети ненадежны.
Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
Это при условии что один клиент может запрашивать данные записываемые другим клиентом.

В условиях локальной сети таким условием можно пренебречь, потому что там сеть или падает полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.


Из этого проистекает простой архитектурный принцип локальности:
Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).

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


S>>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
G>Так в этом и суть CAP — сети ненадежны.
G>Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
G>Это при условии что один клиент может запрашивать данные записываемые другим клиентом.
G>В условиях локальной сети таким условием можно пренебречь, потому что там сеть падает или полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.
G>Из этого проистекает простой архитектурный принцип локальности:
G>Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
G>система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).

Все так, я с этим не спорил. Просто для CA покупали мейнфрейм и P вообще была не нужна.

Здравствуйте, Finder_b, Вы писали:
F_>Я согласен с тобой — получить 100% CA возможно. Просто такая система получатся ну ооочень сложной, и крайне чувствительной к латентности сети. Если у нас P меньше 51% процента, то при стопроцентном C — то любая операция связная с конкурентным доступом, будет потребует не менее латентность*6 времени (*3 если за латентность считать время запрос-ответ). В реальной системе показатель даже хуже, из-за сложности получения математически оптимального результата и того что редко-кода удается обойтись одним конкурентным доступом. В системе которую разработал я, среднее время операции было в 24 раза больше латентности (p порядка 38%), а время гарантированного завершения 99.999% операций было вообще в двести с чем то раз больше латентности сети (значение рассчитано теоретически). По этому такой мейнфрейм может быть расположен только в одном датацентре, или в лучшем случае в одном городе. Что уже намекает что с A у нас не все порядке. При стопроцентном A мы должны мочь пережить отключение света в пределах всего одного города страны. И даже отключение света в одной стране должны пережить, но в России в связи с особенностью законодательства о персональных данных это не возможно. К тому-же непонятно как систему восстанавливать после того как авария с сетью произошла. При стопроцентном CA это выглядит ну очень затруднительной процедурой.

F_>Из чудовищной сложности таких систем, процедур их обслуживания, и их общей тормазнутости — я сделал вывод что в реальном мире они не встречаются. Приношу извинения, это не некорректная генерализация. Допускаю что такие системы где-то действительно есть. Но в реальности требуется статически доказать что они действительно 100% CA, так как во всех виденных мной системах была масса не очевидных на первый взгляд путей через граф их состояния, которые приводили к потере либо C либо A. Хотя все такие пути ну очень маловероятны, но их большое количество и склонность корреляции приводили к снижению С и A где-то до 95% от вероятности аварии.

F_>Статическая валидация маломальски-сложного алгоритма тоже не представляется возможным. К примеру я в свое время я разрабатывал криптовалюту, на строгом алгоритме синхронизации. До миллиона tps, удаление старых транзакций, время достижения полной согласованности сети 5-20 секунд, время достижения локальной согласованности 400 миллисекунд. С=1,A=0.30,P=0.30 в локальном сегменте сети P до 80% ценой длительной потери A с другими сегментами. В примитивном конечном автомате этой кроиптовалюты, если мне не изменят память, было полсотни состояний. Если исключить изоморфные (хз как правильно сказать, в общем приводимых к одному и тому же состоянию, путем эквивалентных преобразований). А теоретическое время ее полной статической валидации было 20 дней на весьма мощной машине. Даже та часть конечного автомата которую я успел реализовать (около 15 состояний) — валидировалась что-то около 15 секунд. К сожалению все заглохло, так как проект большой, а я не совершено не умею подорвать. Но ни сколько не сомневаюсь, что 20 дней на одной машине это крайне оптимистичная оценка. Теперь представьте мейнфрейм в котором миллиарды возможных состояний. Вы всерьез верите что хоть одни человек может проверить их в голове? Со статической валидаций таких алгоритмов ни кто вообще не заморачивается. Это критично для крипты, которую буду абузить, а не для менфрейма. По этом я не думаю что они 100% CA где-то кроме рекламных буклетов.

Хотелось бы понять, как именно вы придаёте численные значения метрикам С и P.
Если с A всё понятно, то что такое C=80%, или P=51%?

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

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

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

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

vsb>Чувствую, что есть какой-то способ сделать всё нормально, т.к. текущая ситуация не очень приятная. Помимо прочего на каждом шаге теряется время, в итоге в системе куча искусственных задержек, что не критично, но и не совсем хорошо.

Я думаю, тебе так или иначе нужна абстракция очереди. Я будешь ты использовать готовое решение или самодельное — отдельный вопрос. У того и у другого есть свои плюсы и минусы.

Я бы еще сделал отдельную персистентную структуру данных, которая хранит по одному объекту на каждый входящий извне (но не внутренний) запрос, и содержит:
— время поступления внешнего запроса
— ссылки на все промежуточные запросы во всех внутренних очередях
— коллекцию логов, которые относятся и исполнению именно этого запроса

Короче, весь контекст каждого внешнего запроса.

Тогда у тебя появляется возможность реализовать таймаут на исполнение запроса в целом и инструментарий для отладки всего пути.

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

Pzz>Я думаю, тебе так или иначе нужна абстракция очереди. Я будешь ты использовать готовое решение или самодельное — отдельный вопрос. У того и у другого есть свои плюсы и минусы.

У самодельного нет ни одного плюса. Хуже того, людей способный более менее сносно реализовать очередь — по пальцам одной руки.

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

НС>У самодельного нет ни одного плюса. Хуже того, людей способный более менее сносно реализовать очередь — по пальцам одной руки.

А в чем тут rocket science?

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

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

В HA у stateful сервиса и прочих распределенных вещах.

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

vsb>Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.

Ну, я видел реализацию похожей задачи. Там реализация была не на передаче данных между сервисами, а в их запросе.
Там первый сервис получал данные, записывал в БД, и в специальную таблицу записывал информацию о новом задании. Второй сервис запускаясь по расписанию или вручную искал у первого сервиса в БД невыполненные задания, вытягивал данные, обрабатывал, складывал первому сервису в БД и у задания менял статус на "выполнено". Как вариант, второй сервис может складывать результат у себя, а первый периодически запрашивать обработанные данные у второго. При транзакционном подходе не будет нарушения целостности. Данные или целиком обработаны или совсем нет.

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

НС>>>У самодельного нет ни одного плюса. Хуже того, людей способный более менее сносно реализовать очередь — по пальцам одной руки.
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 при необратимом сбое носителя.
А вот запросы на списание сильно зависят от всех предыдущих запросов. При разделении сети можно легко получить несколько историй, которые локально корректны, но при слиянии нарушают согласованность.
Запросы на списание/пополнение разных счетов в целом коммутативны; но они могут стать некоммутативными, если мы включим в транзакцию перевод с одного счёта на другой.