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

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

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