Для RPC использовать REST категорически нельзя, так как это принципиально разные подходы к организации API. Для RPC нужно использовать json-over-http, но не REST
Тогда не понятно, а что именно хранили в ES. По каким данным требовался полнотекстовый поиск? И какой именно полнотекстовый поиск (по подстроке или с учетом грамматики или что-то еще)?
Что значит "избыточно"? Как именно избегаем проблемы получения в консьюмере из g4 сообщения из g3? И в кафке не бывает "зависших сообщений", что имеется в виду?
И тоже верно. У меня тоже проблема с пониманием, когда может пригодится ES. Другое дело, что какой-нибудь тактический DDD без ES получается довольно криво, но это скорее проблема DDD.
Хм, что в рамках ES можно заблокировать и на время какой транзакции? Вот конкретный пример для агрегата счет - можешь описать? Именно в рамках реализации ES, с разделением read и write моделей?
Нет, 1С вообще не про ES, да и не про ecom, это уже тут сто раз обсуждалось. Что считает MS - не имеет никакого значения, им нужно продавать облако подороже, а не предлагать оптимальные решения для задач (а ES как раз дает возможность потратить в разы больше ресурсов в облаке, чем другие подходы).
Э, как именно в ES можно сделать на агрегате гарантию положительности баланса всегда? При обработке команды "авторизация счета" нужно в одной serializable транзакции поднять состояние счета, проверить его достаточность, зарезервировать сумму на авторизацию". Но в ES это нереально провести без дополнительных усилий (я, кстати, знаю, каких - но в статье про это ничего не сказано).
Вот когда дело дойдет до, примерно, трех компаний в мире, где прием заказов в черную пятницу реально требует специальных решений - можно будет думать про ES или какие-то другие паттерны. Я не нашел актуальных рекордов на Амазоне, в 2018м в черную пятницу было всего 500 продаж в секунду, это вполне решается и без ES.
Стоит еще заметить, что 1) использование ES почти всегда очень сильно понижает производительность, но, если проектирование сделано правильно, может дать выигрыш в масштабировании. Т.е. решение будет много дороже, но может быть его можно будет залить железом. 2) ES очень сильно зависит от EventStore, при этом на рынке есть только одно решение, которое как-то удовлетворяет требованиям (EventStoreDB), но при этом документации по нему очень мало, архитектурной документации нет вообще, реализуемые гарантии не описаны, знающих решение админов на рынке не найти. 3) Проектов, которым реально нужен ES - крайне мало. И это скорее социальные сети, нежели ecom или финтех.
Хм, я за последние 10 лет принимал участие в создании трех платежных систем с нуля - весьма нагруженных и с большим числом пользователей. Консультировал еще с полдесятка. И нового в обработке платежей как раз много. Но не так, как описано выше.
Кстати, это тоже не верно. Обработка команды с генерацией сопутствующих эвентов - это уже транзакция. И для нее требуется атомарность. Любая зависимость инварианта агрегата от его состояния (например "мы не можем уходить ниже нуля на остатках на счете) уже требует транзакции.
Вообще говоря увод счета клиента в минус (если нет договора по кредитованию и при этом это не банк) - является достаточным поводов для отзыва лицензии у соответствующей платежной системы. Так что вопрос "не ухода в минус" при работе с деньгами - он крайне важный. Для работы в ecom данный подход тоже не работает, так как приводит к куче злобных пользователей, купивших товар, которого нет на складе.
Пока еще не понятно, как именно работает фильтр на kafka-consumer. Вот у меня consumer из активного поколения (g4), из топика пришло сообщение с g3. По идее, должно быть два сценария: 1) если есть где-то еще консьюмер из legacy-поколения g3, то нужно игнорировать это сообщение. 2) если нет консьюмеров из legacy-поколений, то нужно его попробовать обработать.
Но для этого каждый консьюмер должен знать про всех других консьюмеров (и синхронно). Как это реализуется? Или это тема следующей статьи?
А почему не рассматривались какие-то другие инструменты для хранения, кроме ElasticSearch? Тот же CH или хотя бы Influx или иные инструменты? Кажется, что использование полнотекстового движка для мониторинга по метрикам - не самое лучшее решение.
В статье постоянно путают HTTP API и REST, что вызывает серьезные сомнения в компетентности как автора, так и переводчиков. При этом никаких реально важных вещей (документация, версионирование, совместимость с сетевой инфраструктурой) не рассматривают.
Для RPC использовать REST категорически нельзя, так как это принципиально разные подходы к организации API. Для RPC нужно использовать json-over-http, но не REST
Как-то странно гуглили.
1) https://www.baeldung.com/jvm-intrinsics, https://vksegfault.github.io/posts/java-simd/#fn:1
2) Реализуется через Unsafe, есть целые библиотеки реализации примитивов через unsafe, например https://github.com/alexkasko/unsafe-tools
3) https://www.baeldung.com/ahead-of-time-compilation и кроме Graal были и другие решения для AOT для Java.
Все нагуглено за 3 минуты.
Тогда не понятно, а что именно хранили в ES. По каким данным требовался полнотекстовый поиск? И какой именно полнотекстовый поиск (по подстроке или с учетом грамматики или что-то еще)?
Что значит "избыточно"? Как именно избегаем проблемы получения в консьюмере из g4 сообщения из g3?
И в кафке не бывает "зависших сообщений", что имеется в виду?
И тоже верно.
У меня тоже проблема с пониманием, когда может пригодится ES. Другое дело, что какой-нибудь тактический DDD без ES получается довольно криво, но это скорее проблема DDD.
Хм, что в рамках ES можно заблокировать и на время какой транзакции? Вот конкретный пример для агрегата счет - можешь описать? Именно в рамках реализации ES, с разделением read и write моделей?
Это паттерн "Команда", описанный еще в Gang4. К ES не имеет никакого отношения.
Нет, 1С вообще не про ES, да и не про ecom, это уже тут сто раз обсуждалось.
Что считает MS - не имеет никакого значения, им нужно продавать облако подороже, а не предлагать оптимальные решения для задач (а ES как раз дает возможность потратить в разы больше ресурсов в облаке, чем другие подходы).
Э, как именно в ES можно сделать на агрегате гарантию положительности баланса всегда? При обработке команды "авторизация счета" нужно в одной serializable транзакции поднять состояние счета, проверить его достаточность, зарезервировать сумму на авторизацию". Но в ES это нереально провести без дополнительных усилий (я, кстати, знаю, каких - но в статье про это ничего не сказано).
Вот когда дело дойдет до, примерно, трех компаний в мире, где прием заказов в черную пятницу реально требует специальных решений - можно будет думать про ES или какие-то другие паттерны.
Я не нашел актуальных рекордов на Амазоне, в 2018м в черную пятницу было всего 500 продаж в секунду, это вполне решается и без ES.
Стоит еще заметить, что
1) использование ES почти всегда очень сильно понижает производительность, но, если проектирование сделано правильно, может дать выигрыш в масштабировании. Т.е. решение будет много дороже, но может быть его можно будет залить железом.
2) ES очень сильно зависит от EventStore, при этом на рынке есть только одно решение, которое как-то удовлетворяет требованиям (EventStoreDB), но при этом документации по нему очень мало, архитектурной документации нет вообще, реализуемые гарантии не описаны, знающих решение админов на рынке не найти.
3) Проектов, которым реально нужен ES - крайне мало. И это скорее социальные сети, нежели ecom или финтех.
Хм, я за последние 10 лет принимал участие в создании трех платежных систем с нуля - весьма нагруженных и с большим числом пользователей. Консультировал еще с полдесятка. И нового в обработке платежей как раз много. Но не так, как описано выше.
Кстати, это тоже не верно.
Обработка команды с генерацией сопутствующих эвентов - это уже транзакция. И для нее требуется атомарность.
Любая зависимость инварианта агрегата от его состояния (например "мы не можем уходить ниже нуля на остатках на счете) уже требует транзакции.
Вообще говоря увод счета клиента в минус (если нет договора по кредитованию и при этом это не банк) - является достаточным поводов для отзыва лицензии у соответствующей платежной системы. Так что вопрос "не ухода в минус" при работе с деньгами - он крайне важный.
Для работы в ecom данный подход тоже не работает, так как приводит к куче злобных пользователей, купивших товар, которого нет на складе.
Ну, прием заказов - это как раз про "небольшой объем данных", там не нужен ES.
Спасибо за статью!
Пока еще не понятно, как именно работает фильтр на kafka-consumer.
Вот у меня consumer из активного поколения (g4), из топика пришло сообщение с g3. По идее, должно быть два сценария:
1) если есть где-то еще консьюмер из legacy-поколения g3, то нужно игнорировать это сообщение.
2) если нет консьюмеров из legacy-поколений, то нужно его попробовать обработать.
Но для этого каждый консьюмер должен знать про всех других консьюмеров (и синхронно). Как это реализуется?
Или это тема следующей статьи?
А почему не рассматривались какие-то другие инструменты для хранения, кроме ElasticSearch? Тот же CH или хотя бы Influx или иные инструменты?
Кажется, что использование полнотекстового движка для мониторинга по метрикам - не самое лучшее решение.
Да, все это есть в Javа, в том или ином виде.
В статье постоянно путают HTTP API и REST, что вызывает серьезные сомнения в компетентности как автора, так и переводчиков.
При этом никаких реально важных вещей (документация, версионирование, совместимость с сетевой инфраструктурой) не рассматривают.
Люди не идиоты, но обычно принимают решение вне зоны своей компетентности.