Java-апплет — прикладная программа, чаще всего написанная на языке программирования Java в форме байт-кода. Java-апплеты выполняются в веб-обозревателе с использованием виртуальной Java машины (JVM)
Что-то я совсем запутался. Сначала вы пишете, что: "Конечно, можно сохранять события и в БД, но тогда нам придется самим переизобретать то, что уже умеет RabbitMQ."
Затем, отвечая на мои возражения вы пишете про: "идиома transactional outbox - информация о событии создаётся и сохраняется в локальную БД" ... "Далее отдельный поток извлекает такие события из БД и кладёт в RabbitMQ".
Разве это не то самое переизобретение из комента выше?
Т.е было:
producer ➡ rabbitmq ➡ consumer
стало
producer ➡ DB ➡ inter-producer ➡ rabbitmq ➡ consumer
Точка отказа сместилась, но осталась, система усложнилась. Непонимаю где профит? Мы можем добавлять промежуточные звенья в систему, но это не сделает её лучше.
С RabbitMQ: MQ сервер не получит сообщения, оно не встанет в очередь и не дойдет до получателя.
Без RabbitMQ: сообщение так же не дойдет.
Давайте представим, что упал consumer.
С RabbitMQ: RabbitMQ сохранит сообщение в очереди и доставит его, когда consumer будет готов.
Без RabbitMQ: оно всё равно дойдет при следующем "try", ведь контекст сохранен в producer'е. Но есть одно НО, если во время retry producer упадет, мы потеряем сообщение. (гол в пользу Rabbit)
Давайте представим, что упал сам RabbitMQ.
С RabbitMQ: consumer не получит сообщения
Без RabbitMQ: ситуация невозможна (гол против Rabbit)
Когда бдительность усыплена, вам сообщяют, что "You have reached the maximum amount of 90-day certificates allowed on the Free Plan" и требуют 10$ в месяц.
Фейк?
Гербалайф?
Искусственное раздувание стоимости группой заинтересованных лиц?
Или революция?!!!
Наши эксперты всё выяснили: <здесь могла быть ваша реклама, которая выглядит совсем как не реклама>
Смотрю на картинку "synchronous / asynchronous" и складывается впечатление, что вы путаете синхронный и асинхронный ввод/вывод с последовательным/параллельным выполнением
Подход микросервисов позволяет постепенно деградировать функциональность приложения.
Всё, что вы можете сделать с микросервисами, включая постепенную деградацию, вы можете сделать с монолитом (кроме масштабирования по частям).
Касательно вашего примера, вот примерный кусочек псевдокода
Здесь не видно, что именно делает ф-ия Authorize: вызывает микросервис или авторизирует с помощью подключенного модуля/библиотеки/пакета внутри процесса.
Но, на самом деле, какая разница? Приложение будет вести себя одинакового.
Если вы про retry pattern, то звучит резонно, хотя монолит с балансировщиком могут делать тоже самое.
Если про очереди типа RabbitMQ, то монолит тоже может работать через них.
Просто возводя сетевые барьеры между кусками кода, вы не делаете его лучше.
Если вам нужен High availability, вы так же можете добавить его в монолит, это не эксклюзивная для микросервисов фича.
Говнокод внутри процесса валит процесс.
Говнокод внутри микросервиса валит микросервис и все микросервисы, которые с ним работают.
Так или иначе, но приложение перестает работать.
Разве нет?
Вам, на самом деле не нужны эти костыли, ReSharper или что-то еще.
Все гораздо проще
enum MyEnum { A, B, C }
var e = (MyEnum)new Random().Next(0, 2);
Console.WriteLine(e switch
{
MyEnum.A => "A",
MyEnum.B => "B"
});
Здесь появляется warning
CS8509 The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern 'ConsoleApp1.Program.MyEnum.C' is not covered
В .editorconfig'е переводите этот warning в ошибку.
Профит!
Хорошая новость, давно пора
С 1995 года
Шутка для настоящего специалиста, если что :)
JSON экранировать надо.
Вместо
делайте
Не пробовали PostgreSQL заменять на SQLite in-memory?
Тесты получаются не совсем "честными", зато быстро, просто и контейнеров не надо.
>> если вам в ваших проектах профита нет, то не знаю, зачем вам доказывать профит :)
А если профит есть, то и доказывать ничего не надо :)
Но если серьезно, используем его уже давно, а профита всё не вижу, поэтому нахожусь в постоянном поиске оного.
Спасибо, что поделились со мной :)
Что-то я совсем запутался. Сначала вы пишете, что: "Конечно, можно сохранять события и в БД, но тогда нам придется самим переизобретать то, что уже умеет RabbitMQ."
Затем, отвечая на мои возражения вы пишете про: "идиома transactional outbox - информация о событии создаётся и сохраняется в локальную БД" ... "Далее отдельный поток извлекает такие события из БД и кладёт в RabbitMQ".
Разве это не то самое переизобретение из комента выше?
Т.е было:
producer ➡ rabbitmq ➡ consumer
стало
producer ➡ DB ➡ inter-producer ➡ rabbitmq ➡ consumer
Точка отказа сместилась, но осталась, система усложнилась. Непонимаю где профит? Мы можем добавлять промежуточные звенья в систему, но это не сделает её лучше.
>> Если упал процесс
Какой именно процесс? producer или consumer?
Давайте представим, что успал producer.
С RabbitMQ: MQ сервер не получит сообщения, оно не встанет в очередь и не дойдет до получателя.
Без RabbitMQ: сообщение так же не дойдет.
Давайте представим, что упал consumer.
С RabbitMQ: RabbitMQ сохранит сообщение в очереди и доставит его, когда consumer будет готов.
Без RabbitMQ: оно всё равно дойдет при следующем "try", ведь контекст сохранен в producer'е. Но есть одно НО, если во время retry producer упадет, мы потеряем сообщение. (гол в пользу Rabbit)
Давайте представим, что упал сам RabbitMQ.
С RabbitMQ: consumer не получит сообщения
Без RabbitMQ: ситуация невозможна (гол против Rabbit)
Итого счёт 1:1.
Но "если брюки выглядят одинаково, зачем платить больше?" ©
Я не вижу реальной выгоды от Рэббита, хотя может я что-то упустил в своем анализе?
>> если сервис упал и не успел сделать ACK, то произойдёт retry
Retry можно делать и без посредников в виде RabbitMQ обычным циклом, которму передается делегат или использовать Polly
Скорее всего вам пришло письмо с просьбой активации, которое вы открыли.
Активируется кликом по ссылке.
Ваш email клиент отправил на нее GET запрос, пытаясь посмотреть, что ж там такое и, таким образом, активировал :)
ZeroSSL лишь притворяется бесплатным.
Когда бдительность усыплена, вам сообщяют, что "You have reached the maximum amount of 90-day certificates allowed on the Free Plan" и требуют 10$ в месяц.
Музыка, это вам не IT. Тут учиться надо ;)
Фейк?
Гербалайф?
Искусственное раздувание стоимости группой заинтересованных лиц?
Или революция?!!!
Наши эксперты всё выяснили: <здесь могла быть ваша реклама, которая выглядит совсем как не реклама>
Смотрю на картинку "synchronous / asynchronous" и складывается впечатление, что вы путаете синхронный и асинхронный ввод/вывод с последовательным/параллельным выполнением
Всё, что вы можете сделать с микросервисами, включая постепенную деградацию, вы можете сделать с монолитом (кроме масштабирования по частям).
Касательно вашего примера, вот примерный кусочек псевдокода
Здесь не видно, что именно делает ф-ия Authorize: вызывает микросервис или авторизирует с помощью подключенного модуля/библиотеки/пакета внутри процесса.
Но, на самом деле, какая разница? Приложение будет вести себя одинакового.
Если вы про retry pattern, то звучит резонно, хотя монолит с балансировщиком могут делать тоже самое.
Если про очереди типа RabbitMQ, то монолит тоже может работать через них.
Просто возводя сетевые барьеры между кусками кода, вы не делаете его лучше.
Если вам нужен High availability, вы так же можете добавить его в монолит, это не эксклюзивная для микросервисов фича.
Говнокод внутри процесса валит процесс.
Говнокод внутри микросервиса валит микросервис и все микросервисы, которые с ним работают.
Так или иначе, но приложение перестает работать.
Разве нет?
Вам, на самом деле не нужны эти костыли, ReSharper или что-то еще.
Все гораздо проще
Здесь появляется warning
В .editorconfig'е переводите этот warning в ошибку.
Профит!
тогда ≈ 2.99 должно умирать/поглощаться, иначе случится StartupOverflow
Сильное заявление ©
Принцип YAGNI говорит нам о том, что задачу надо решать наиболее простым способом, удовлетворяющим критерии.
Если константы достаточно, используйте её.
Вынося её в конфиг, вы
Скорее "плагин", а не обертка. Под оберткой обычно имеют ввиду агрегирование одного класса другим