Здравствуйте, 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>Зачем все это? Ради чего?
Здравствуйте, ·, Вы писали:
·>Скажем, есть сервис сбора статистики о заказах. И вдруг понадобилось помимо содержимого заказа иметь информацию о стране доставки заказа. Никакой полной отвязки быть не может, ибо нам надо всё ещё собирать статистику по всем заказам, а не только по тем, которые присылаются новыми клиентами. Значит мы так или иначе должны проапрейдить всех клиентов, ну или делать изменение неломающим и "страна доставки" будет опциональной. А опциональность не всегда возможна. Например, требование страны может быть наложено регулятором для отслеживания выполнения требований санкций — и тут выбор, либо ты нафиг ломаешь всех клиентов, либо ты прикрываешь свой бизнес.
хороший пример.
а как такое решается? с точки зрения бизнеса.
как можно заставить кучу клиентов обновиться, и что делать, если кто-то не хочет или не торопится?
какой запас времени нужно дать клиентам? и поддерживаются ли в это время две версии?
Здравствуйте, Ночной Смотрящий, Вы писали:
K>>>Найс. Теперь у нас слабое звено — оркестратор. C>>Он не пропускает через себя запросы, а просто следит за размерами очередей. Никто не мешает его сделать распределённым, кстати. НС>Но по факту обычно не делают.
Уже делают, есть linkerd. Если использовать что-то типа AWS/Azure для масштабирования, то там координаторы тоже распределённые.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, white_znake, Вы писали:
_>>- Команды, пилящие микросервисы, должны иметь чуть-более высокую культуру разработки. Нельзя просто так взять и грохнуть поле команды или сделать вновь добавленное поле команды обязательным. И еще возникает необходимость в интеграционных тестах.
S>За счет версионирования api, это сделать как раз просто. Меняем нужные поля, инкрементируем версию api. При этом желательно, чтобы старая версия работала.
Это-то я знаю, спасибо за поучение.
Микросервисы могут общаться и не через рест, а могут общаться через команды и шину сообщений. В этом случае версионировать труднее, но все равно есть возможность через Nuget пакеты или NPM-пакеты ставить нужную версию команды и соответственно сервера, обрабатывающего эту команду.
Что все равно налагает дополнительные требования. И само версионирование рест АПИ — это тоже дополнительные требование и усилия.
Посмотрел я на граф взаимодействия и о том, то один сервис взаимодействует с половиной микросервисов, и понял, что скорее всего ребята неправильно разбили микросервисы, сделали их очень гранулярными и от того слишком общительными.
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 не выйдет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.