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

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

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

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

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

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

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

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

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

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

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

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