Новое сообщение в форум Архитектура программного обеспечения

Форум	Архитектура программного обеспечения
Тема	Как правильно задавать вопросы

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

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

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

G>>>·>Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров - всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.
G>>>А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
G>>>Я думаю есть единственно верный способ моделирования - отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.
G>·>А откуда возникла такая [i]задача[/i] "транзакционно обновить состояние корзины с резервов на складе"? По-моему, ты путаешь цель и средство.
G>Конкретно это из озона. В целом в любой торговле со склада задача актуальна, если надо не продать больше чем есть на складе.

G>·>Аналогия. Мне это напоминает давнишние споры cvcs vs dvcs. Ну как типа "нам нужно точно пронумеровать каждый changeset, как в svn. А вот git так не умеет, значит отстой". Вот только git точнее описывает реально происходящее при работе с исходниками, а не случайно придуманные "нам нужно". Не бывает в ральном мире точно пронумерованных changesets. Поэтому svn умер.
G>Я даже не возьмусь комментировать по пунктам этот опус. Я работал с SVN и git, и первый умер совсем по другим причинам, а не связанным с нумерованные ченджсетов.

G>>>>>В рамках одного процесса вполне себе бывает.
G>>>·>Ну вот плохо получается, если моделировать одним процессом. 
G>>>Тогда можно атомарность сделать за счет одной бд на одном сервере.
G>>>СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.
G>·>Да не важно. СУБД это просто такой готовый процесс.
G>Угу, процесс который умеет это делать, в отличие от твоего процесса, который по умолчанию не умеет и надо прям поприседать чтобы умел.

G>>>·>Участники бизнес-процессов в реальном мире - независимы, географически распределены, работают параллельно.
G>>>Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.
G>·>Мы можем попытаться их заставить ходить на один сервер, реализуя такую монолитную архитектуру. И это даже как-то будет работать. Пока этот один сервер не ляжет.
G>У OpenAI как-то не лег с их количеством клиентов и обращений.
G>Если ты сделал оптимальные запросы, а сервер бд лег от нагрузки, то у тебя будет только одна проблема - куда потратить миллионы, которые ты заработал.

G>>>>>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
G>>>·>Это разные транзакции в разных частях системы.
G>>>И что? Все равно потеряли.
G>>>В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции
G>·>А как это решит твою проблему "пользователь плюет на это дело и идет в другой магазин"? 
G>Этой проблемы просто не будет, мы никогда не продадим больше чем есть на складе если резервирование сделаем транзакционно.

G>·>Какую вообще проблему решает эта твоя "одна транзакция"?
G>Ту самую, которую ты непонятно как хочешь решить.

G>·>С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой.
G>:))) 
G>нельзя

G>·>Вот только в этом случае транзакция резервирования выполняется в БД склада, а транзакция смены статуса в БД заказов. И эти БД могут быть физически распределены и размещены поближе к местам событий.
G>Ага, и в этом случае статус может стать "зарезервирован", а остаток на складе не уменьшится, и ты будешь разговаривать с недовольными покупателями.

G>>>·>В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.
G>>>И это повод не пользоваться транзакциями?
G>·>Это повод не использовать один процесс. И транзакции, если ими пользоваться, будут распределёнными. Что кошмар и ужас.
G>С распределенными транзакциями у тебя все ляжет сильно раньше, поэтому на практике под нагрузкой их не используют.

G>>>>>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
G>>>·>Именно. А начнёшь переезд - заколебаешься для большого проекта.
G>>>Так у меня большой проект. За 10 лет огого сколько всего написали.
G>·>Так и я о том же. В рамках МСА была бы группка мелких проектов, то можно было бы есть слона по частям. А сейчас ты в тупике.

G>У меня большой проект, который состоит из группы мелких проектов, которые примерно 8 лет усиленно пилили. В 2018 году взяли курс на микросервисность. Сейчас огромное количество проблем с консистентностью данных и быстродействием из-за МСА, что приходится почти целые сервисы переписывать, чтобы обеспечить надежность.
G>Я думаю за годик смогу запинать все это, чтобы модульный монолит получился.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail