Как стать автором
Обновить
21
0
Капля Олег Витальевич @smileonl

Пользователь

Отправить сообщение
Эмм, для таких статей вроде как мегамозг создавался?
Parser-3 — на этом убожестве ещё кто-то что-то делает?
Как же меня раздражают подобные жёлтые заголовки для статей.
Я читал эту статью пару недель назад и даже там до последнего думал что автор шутит ) Но нет — всё серъёзно.
Прям нечего стыдиться? Как же скучно вы живете )
Добрый день, если можно smile8979@ya.ru
Ок, а почему она не соответсвует моей интерпритации?
В примере выше было предложено 2микросервиса для одного и того же процесса просто с разными провайдерами отправки сообщений.
Я написал что в контексте микросервисов это не самое верное решение иначем можно было бы создавать по одному микросервису для каждого типа загружаемых фотографий (jpg,png и т.п.), надеюсь понятно донес мысль.
Вы это мне написали? Я провайдеров кодов не упоминал в этом сообщении.
Про 2 минуты не забыл, и привел пример где такой вариант при выборе разных СХД — сомнителен.
Троллингом не в коем случае. Я вроде по существу пишу, в любом случае не принимайте на свой счет, мы здесь обсуждаем сугубо техническую сторону решения.

Три сервера: основное приложение, +2 микросервиса.

Я надеюсь вы тут пошутили :) Вы предлагаете 3 виртуалки, докера-контейнера, поддерживать, деплоить только на этапе регистрации нового пользователя?
Я ознакомился и на основе вашей публикаци и задаю вопросы.
Мы говорим о микросервисах. У вашего микросервиса какая задача? Отправка кода на этапе регистрации не больше не меньше.
Или я не прав?
Ещё вопрос. При формировании ответов REST вы предлогаете использовать такие варианты:

Успех:

{ 'result' => 0, 'message' => 'success' }

Неудача:

{ 'result' => 1, 'message' => 'fail', 'errors' => ['string_1', 'string_2'] }


Собственно почему вы не используете HTTP status codes www.restapitutorial.com/httpstatuscodes.html в ответах.
«мы» — я использовал в контексте вашей публикации )
Это решение в определенной доле мне нравится, правда всеравно мне непонятно зачем тут 2 микросервиса.

В общем контексте микросервис (если мы отталкиваемся от SOA) выполняет одну задачу отправка кода подтверждения, я не уверен что в зависимости от типа подтверждения верно плодить отдельные микросервисы.
А в чем тут разница с тем что у нас находится на этом сервере, набор микросервисов или обычное полнофункциональное приложение?
Ближе к телу, но тогда есть вероятность возникновения ситуации когда пользователь сформировал смс посредством перовго инстанса а проверить уже пытается по средствам второго.

Естественно это можно решить посредством реплики(в случае инстансов одинаковых СХД) в случае разных — непонятна правильность такого решения.

+ напоминаю мы решали проблемму отправки смсок при регистрации :)
Вы не ответили как второй микросервис закрывает риск :)

Мы сейчас не говорим о репликации редиса и вариантах размещения приложения.

Выше вы сказали о том что второй микросервис при падении перового закрывает риск, я спросил про то каким образом вы себе это представляете при падении редиса, вы мне рассказываете про репликацию.
Так при репликации именно она снимает риск а не второй микросервис.
Ок, причина того что первый сервис ушел в офф — упал редис, как второй такой же микросервис закроет этот риск.
Так вот я и спрашиваю как тот факт что у вас 2 одинаковых микросервиса — при этом один обрабатывает запросы а второй просто висит и ждет, минимизирует наши риски?
Провайдер микросервиса — что вы под этим имеете ввиду?

Информация

В рейтинге
Не участвует
Откуда
Минск, Минская обл., Беларусь
Зарегистрирован
Активность