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

S>А нет проблемы, но как оне будет находится? По статичному конфигу, dns, rp? Я так понял, что все-таки через RP.

Ну, сейчас, обычно, находятся сервисы через DNS. А вот балансировка обычно делается более полноценными методами.

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

_>>Феерично.
_>>Ну вот запустил я тут на hadoop кластере расчёт аналитической (с помощью ML) задачки — покажи, что тут у нас является микросервисами.
S>Феерии не вижу, в случае выше совместная обработка задачи. Это, вестимо, не микросервисы.

Совершенно верно. И соответственно из этого примера видно, что кластер — это совсем не реализация идеи микросервисов.

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

F>>>почему обязательно на одной машине?
_>>В тексте же однозначно написано, что не обязательно на одной. Но это вполне распространённый сценарий.
F>я просто пытаюсь связать "на одной машине" и "убожество"

Убожество — это уже моя субъективная оценка. Да, и кстати она следует совсем не из одной/нескольких машин, а из того насколько неадекватно сложно становится решать простейшие задачи с использованием подобной архитектуры.

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

S>>Этого с чего вдруг? Как я понимаю, если в очереди скопилось куча задач, оркестратор(или кто там) автоматически поднимет кол-во обработчиков(т.е. микросервисов) запросов.
K>Найс. Теперь у нас слабое звено — оркестратор.
Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати.

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

K>>>Как оно реализуется на практике? Чере ещё один микросервис?
C>>Нет, силами самого сервиса.
K>Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать?
Например, на каждом сервере выделяется поток, который в фоновом режиме будет убирать мусор из базы данных. Но можно выделить и полностью отдельный сервер — всё зависит от потребностей.

C>>Сервисная архитектура — это очень непростая вещь. Она требует планирования и большого опыта для правильного дизайна. Потому она оправдана только для уже реально больших и сложных приложений, над которыми работают множество команд.
K>Да если бы так. Сейчас чуть ли не каждый "школьник" пытается своять микросервисную систему и задеплоить её через Kubernetes. Зачем так делать, не ясно.
Ну вот и не надо так делать. Точнее, развёртывание через K8S — это нормально, а вот дизайн из 100500 сервисов — не очень.

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

K>>Найс. Теперь у нас слабое звено — оркестратор.
C>Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати.

Но по факту обычно не делают.

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

S>В чем смысл микросервисов?
S>Ты для каждого компонента ваяешь HTTP-API (как правило), для каждого компонента делаешь свою DB (часто). Зачем?
S>Что мешает тебе просто создать класс AccountService и определить для него интерфейс IAccountService стандартными средствами? Ведь в таком случае тебе не нужно будет трафик гнать для внутреннего взаимодействия.
S>Далее. Как ты решаешь вопрос с транзакциями? Это ж тебе жуткие костыли придется ваять.
S>Зачем все это? Ради чего?

Кстати, видел недавно отличную (и главное аргументированную) статью на тему ненужности микросервисов: https://habr.com/company/flant/blog/424531/.

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

·>Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.

хороший пример.
а как такое решается? с точки зрения бизнеса.
как можно заставить кучу клиентов обновиться, и что делать, если кто-то не хочет или не торопится?
какой запас времени нужно дать клиентам? и поддерживаются ли в это время две версии?

Здравствуйте, Ночной Смотрящий, Вы писали:

K>>>Найс. Теперь у нас слабое звено — оркестратор.
C>>Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати.
НС>Но по факту обычно не делают.
Уже делают, есть linkerd. Если использовать что-то типа AWS/Azure для масштабирования, то там координаторы тоже распределённые.

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

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

_>>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.

S>За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Это-то я знаю, спасибо за поучение.

Микросервисы могут общаться и не через рест, а могут общаться через команды и шину сообщений. В этом случае версионировать труднее, но все равно есть возможность через Nuget пакеты или NPM-пакеты ставить нужную версию команды и соответственно сервера, обрабатывающего эту команду.

Что все равно налагает дополнительные требования. И само версионирование рест АПИ — это тоже дополнительные требование и усилия.

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


_>Кстати, видел недавно отличную (и главное аргументированную) статью на тему ненужности микросервисов: https://habr.com/company/flant/blog/424531/.

Посмотрел я на граф взаимодействия и о том, то один сервис взаимодействует с половиной микросервисов, и понял, что скорее всего ребята неправильно разбили микросервисы, сделали их очень гранулярными и от того слишком общительными.

P.S. Мое мнение и мнение автора статьи совпадает с тем, что многие разрабочики не обладая хорошим опытом (а в создании архитектуры важен опыт), превратно понимают слово "микро".

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

F>·>Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.
F>хороший пример.
F>а как такое решается? с точки зрения бизнеса.
F>как можно заставить кучу клиентов обновиться, и что делать, если кто-то не хочет или не торопится?
F>какой запас времени нужно дать клиентам? и поддерживаются ли в это время две версии?
В данном случае относительно просто — регулятор обычно явно обозначает даты, к какому сроку всё должно быть сделано — и приходится просто отрубать non-compilant клиентов.
А в общем случае — надо сразу продумывать и проговаривать с клиентами полный жизненный цикл сервиса, включая decommission старых версий. И для клиентов, любящих старые версии — устанавливать платный long term support.

Просто надо понимать, что "мы просто оставим старую версию запущенной" это по сути один из способов неявно превратить обязательный параметр в опциональный, и, кстати, не самый лучший по многим критериям.

Обычно лучше работает A/B-feature подход — выкатываем новую версию в B, переключаем постепенно всех клиентов с A на B, выключаем А. А в следующий раз выкатываем очередную новую версию в А и т.д. В таком случае явно ограничивается количество одновременно работающих версий двумя.

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

C>Уже делают, есть linkerd. Если использовать что-то типа AWS/Azure для масштабирования, то там координаторы тоже распределённые.

Координаторы чего? Машина оркестратора в кластере AKS в Ажуре — одна.

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

K>Как это выглядит на практике? Вот есть у меня 10 инстансов сервиса аутентификации, причём физически они могут распологаться на разных серверах. Как оно должно работать?
Ну, например — как Active Directory
У него есть интервал синхронизации, ЕМНИП — 15 минут. Изменения плавно реплицируются.
Есть сложности, когда хочется организовать что-то типа транзакции — например, создать пользователя И добавить его в группу.
Если не приседать, то есть шанс при втором запросе нарваться на user not found.
Для таких штук применяют, например, короткоживущий токен, который возвращает первая операция.
Если у нас есть inter-operation dependency, как в этом примере, то мы отправляем токен при втором запросе, и роутинг связывает нас с тем же инстансом, что и при предыдущем запросе.
Через 15+ минут токен теряет валидность, т.к. мы знаем, что всё уже отреплицировалось, поэтому злоупотребить affinity не выйдет.