C>Для примера, если взять сетевой магазин, то в микросервисной модели будет:
C>1) Отдельный сервис, отвечающий за поддержку корзины покупок.
C>2) Отдельный сервис для обработки карточек.
C>3) Отдельный сервис для валидации адреса доставки.
C>4) Отдельный сервис для расчёта бизнес-статистики для директора магазина.

Ну то есть схема, которая уже не первое десятилетие спокойно и без лишнего шума широко используется там, где она нужна — и не используется там, где она не нужна.

Но юные хипстеры ВНЕЗАПНО

— обозвали эту схему красивым словом
— объявили чем-то принципиально новым
— забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует

Здравствуйте, Аноним931, Вы писали:

А>Ну то есть схема, которая уже не первое десятилетие спокойно и без лишнего шума широко используется там, где она нужна — и не используется там, где она не нужна.

А>Но юные хипстеры ВНЕЗАПНО

Ты про SOA? Это близко, но не совсем то. У SOA фокус на повторное использование сервисов и создание приложений на единой платформе, используя сервисы в качестве кирпичиков. В микросервисной архитектуре плевать на повторное использование сервисов и единую платформу, фокус на изолированность и независимость сервисов друг от друга при максимальной декомпозиции по функционалу и данным. Можно сказать, что микросервисы — это развитие SOA архитектуры, когда из нее убрали ESB, единое хранилище, единую платформу, единые стандарты коммуникаций и перефокусировались от повторного использования к максимальной изоляции сервисов друг от друга

T>Ты про SOA?
Я про схему, описанную Цибераксом, и названную им "микросервисной"

Здравствуйте, Аноним931, Вы писали:

А>Но юные хипстеры ВНЕЗАПНО
А> — обозвали эту схему красивым словом
А> — объявили чем-то принципиально новым
А> — забили все интернеты своими высерами о том, как это круто и какие лохи те, кто это не использует
Юные хипстеры эту схему реально довели до ума. В частности:
1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/
2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/
3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).

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

F>>а где аргументация?
НС>А где аргументация у того, кто утверждение делал? Микросервисы и кластеризация — ортогональные понятия. Кластеры, нацеленные на резервирование и перформанс это не просто набор разрозненных микросервисов. И даже решения типа Service Fabric эту задачу полностью не решат. Ее надо решать целенаправленно, и микросервисы лишь могут облегчить начало пути, не более.

обычно под "микросервисной архитектурой" понимают весь комплекс проблем.

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

_>И есть противоположный этому вроде как современных подход (на мой взгляд никчемное убожество) — это когда ты на одной и той же машине (ну да, их таких может быть множество, но это опять же не суть) запускаешь множество демонов разного назначения, которые совместно решают целевую задачу. Это и есть те самые микросервисы.

почему обязательно на одной машине?

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

scf>- Масштабирование. В целом, монолитные приложения масштабируются хорошо, в отличие от огромной БД монолитного приложения. И наличия внутреннего состояния, которым грешат монолиты.
scf>- Устойчивость к отказам. Отказ от транзакций и необходимость тщательной обработки ошибки позволяет строить системы, адекватно реагирующие на перегрузку и отказ отдельных компонентов.
Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.

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

K>Как организовать совсемтную работу одного микросервиса со своей ДБ (пусть бует монгоДВ) чтобы обеспечить хотья как-то согласованность данных в ней? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токеми доступа в этой БД.
Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.

А кто говорил, что будет легко?

C>Юные хипстеры эту схему реально довели до ума. В частности:
C>1) Начали разбираться с трассировкой и отладкой: https://opentracing.io/
C>2) Управление траффиком, в том числе throttling и load shedding: https://linkerd.io/
C>3) Субстрат, на который легко разворачивать приложения (Docker, Kubernetes).
Я вас с этим, конечно, поздравляю, только вот все это никак не опровергает мои слова

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

C>Ну как обычно — eventual consistency, идемпотентные запросы и фоновые reconciler'ы.
Как оно реализуется на практике? Чере ещё один микросервис?
C>А кто говорил, что будет легко?
Фаулер говорил

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

vsb>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.

А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис? Я так понимаю, что в основе всех
высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?

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

_>которые совместно решают целевую задачу. Это и есть те самые микросервисы.

Ни о какой совместности речи нет, совместность это mapreduce\hadoop, акторы наконец. А это именно однотипные изолированные функции.

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

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

vsb>>account-api.mysite.com на одном компьютере, mysite.com на другом, reports.mysite.com на третьем. aссount-api2.mysite.com это уже другой уровень масштабирования, для такого действительно нужно писать специальный код и никакого преимуществе перед монолитом тут нет, т.к. монолит со специальным кодом тоже можно запускать на нескольких серверах.

S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а) всех хостов, реализущих данный сервис?

Как настроишь, так будет. Можно вернуть все адреса. Приложение должно стучаться во все адреса в указанном порядке, пока не найдёт рабочий. Можно один вернуть.

S> Я так понимаю, что в основе всех
S>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?

Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.

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


S>> Я так понимаю, что в основе всех
S>>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?

vsb>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.

Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и
инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.

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

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


НС>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы.

Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.

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

S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса.
Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.

Настоящий load balancer отличается от вот этого подобия вот чем:
1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута)
2. Умеет отслеживать фактическую нагрузку
3. Умеет поддерживать session и client affinity

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

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

S>>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
S>Это называется "round-robin load balancer", его ещё называют "балансировщиком для бедных". Просто регистрируем N A- (или CNAME) записей для одного и того же хостнейма, которые бы стреляли в разные IP адреса.
S>Теперь у нас при каждом запросе эти IP адреса будут отдаваться более-менее равномерно.

S>Настоящий load balancer отличается от вот этого подобия вот чем:
S>1. Умеет отключать вышедшие из строя сервера (обращение к мёртвому серверу стоит клиенту длительного таймаута)
S>2. Умеет отслеживать фактическую нагрузку
S>3. Умеет поддерживать session и client affinity


С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

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

K>Как организовать совместную работу одного микросервиса со своей ДБ (пусть будет монгоДВ) чтобы обеспечить хоть как-то согласованность данных при маштабировании? Пусть будет какой-нибудь микросервис аутентификации с БД пользователей и токенами доступа в этой БД.

Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД. если n экземпляров микросервиса и n БД (шардинг), то проще всего сделать программный шардинг по ключам (логин пользователя, первый символ токена) — микросервис сам обращается в нужную БД. Джойнов между шардами желательно избегать, вынося их на сторону клиента.

Из минусов — при запросе связанных данных (юзер из токена, юзер-создатель юзера и т.п.) нужно быть готовым и правильно обрабатывать случай, когда их не окажется.

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

S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге.

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


S>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?

F>если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге.

Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.