Как взаимодействуют микросервисы?

Question

[Евгений Ромашкан]

В интернете полно докладов какие они хорошие/плохие или как их внедряли в компанию, но почти нет про реализацию.
Нашел такую статью на хабре - https://habr.com/post/302844/ , да ещё и в докладах говорят что "все проблемы решает" docker.
Как в итоге взаимодействуют микросервисы в боевых условиях?
Это разные серверы которые шлют друг другу запросы через интернет? Или это несколько процессов php запущенных в Докере на одной машине?
Приму и ссылки на статьи/доклады где говориться об этом без тонн воды о плюсах, минусах, сравнениях и т.п.

Comments

[Максим Федоров]

Очереди -- RabbitMQ/Apache Kafka
Через HTTP

[Евгений Ромашкан]

Максим Федоров, Про это слышал. И всё же, где физически расположены эти сервисы и их базы данных? На одной машине? Т.е. микросервисы это всегда Докер?

Через HTTP

То есть на каждый запрос пользователя на сервере происходит ещё 10 http запросов? И это может не накладно по времени?

[Максим Федоров]

вот еще нашел
Как организовать внутренне общение микросервисов друг с другом?
Как взаимодействовать при микросервисной архитектуре?

[Maksim B]

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

Answer 1

[Doc44]

Нашел такую статью на хабре - https://habr.com/post/302844/ , да ещё и в докладах говорят что "все проблемы решает" docker.

Да?
Смерть микросервисного безумия в 2018 году
Вам не нужна микросервисная архитектура
И это только легкий гуглежь.

Основной плюс микросервисов - горизонтальная масштабируемость.

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

Более того - их может быть несколько экземпляров одинаковых.
И вы не будете заранее знать к какому именно экземпляру вы обращаетесь.

Рассматривайте сервис как отдельное изолированное самодостаточное приложение.
Как правило со своей личной базой данных (разве что между экземплярами одного и того же сервиса используется одна и та же БД; реже - одна БД на несколько различного вида сервисов).
Чаще всего взаимодействующее с внешним миром и/или другими сервисами по HTTP/HTTPS.
Иногда взаимодействие дополняют MQ-сервером.

да ещё и в докладах говорят что "все проблемы решает" docker.

Как решает так и создает проблем.

Про решает - имеют ввиду вот что: Докер позволяет прогарантировать что окружение при разработке и окружение при эксплуатации будет максимально сходным.

А нередко это большая проблема - когда у разработчика все запускается, но в реальной системе глючит. Из-за какого нибудь ерундового отличия в конфигурации, которое сделано в той же системе но под другой уже имеющийся в системе софт и/или в установленных библиотеках (а другую версию поставить нельзя, так как другой софт требует именно той версии) и пр.
Докер же позволяет изолировать приложение вместе с настройками, которые под него сделал разработчик.

Comments

[Евгений Ромашкан]

Я не говорил что нашёл только одну статью. Я просто не могу понять куда, по какому адресу обращается один сервис чтобы получить ответ от второго.

[Doc44]

Евгений Ромашкан,
в простейшем случае - захардкожено.
например, все нужно для работы передается в сервис при его запуске в переменных окружения.

Однако в реально больших системах это немыслимо, состояние таких систем постоянно меняется - поэтому используются специальные service discovery.
очень мощный и при этом довольно простой для понимания Hashicorp Consul.
https://www.consul.io/discovery.html

то есть каждый раз когда сервису нужно получить что то от другого сервиса он сначала спрашивает у Consul а где этот другой искать.

Consul при этом установлен на каждом узле кластера, то есть доступен любому сервису по локальному адресу.
Consul опрашивает сервисы и знает - когда какой сервис стартует, когда останавливается (по возможности, разумеется, ибо если сбой то не до этого) или когда перегружен.
Экземпляры Consul общаются между собой, синхронизируясь. Таким образом, обратившись к Consul локально мы можем получить актуальную информацию о любом сервисе в кластере.

Другие альтернативы
https://www.consul.io/intro/vs/zookeeper.html

[Евгений Ромашкан]

Doc44, Понял. Спасибо за ответ, и за ссылки!

Answer 2

[Losted]

Обычно - HTTP/REST для синхронных вызовов и разного рода очереди - для асинхронных. Возможно взаимодействие и через интернет, конечно, но чаще это внутряк. С точки зрения деплоймента - это может быть любая комбинация в зависимости от конкретных условий (отдельные железки\виртуалки\контейнеры и отдельные\шаренные БД). При шаренных ресурсах важное условие - изоляция, то есть данные одного сервиса или наличие сервиса на той же железке никогда не подразумевается в другом (например прямой доступ в чужую базу), а всегда запрашиваются через API.

Comments

[Евгений Ромашкан]

Спасибо за ответ. Правильно я понимаю, что когда разные сервисы взаимодействуют на одной физической машине - в Докере создаётся несколько процессов(например php) которые друг с другом общаются?

[Losted]

Евгений Ромашкан, да, но тут важно, что общаются они не, грубо говоря, процесс->процесс, а процесс->api->процесс. Таким образом, если в какой-то момент топология изменится и один из процессов переедет в отдельную железку на взаимодействие это никак не повлияет.

Пример: сервис 1 хочет список пользователей, который хранится в сервисе 2. Сервис 1 делает http запрос, например, http://service2/users и обрабатывает ответ или ошибку