Микросервисная архитектура Java

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

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

Во-первых, просто сервисов. REST -- это уже деталь имплементации. К тому же, у сервиса вообще может не быть никакого API. Во-вторых, создание множества сервисов -- это, конечно же, способ достижения цели. А суть микросервисной архитектуры заключается в следовании принципу единой обязанности. И уже отсюда вытекает все остальное: способы реализации, плюсы и минусы.

Существует множество различных технологий взаимодействия одного микросервиса с другим. Сервисы могут использовать синхронные механизмы связи на основе запроса/ответа, такие как REST или Thrift на основе HTTP. В качестве альтернативы они могут использовать асинхронные коммуникационные механизмы на основе сообщений, такие как AMQP или STOMP. Существуют также различные форматы сообщений. Сервисы могут использовать удобочитаемые текстовые форматы, такие как JSON или XML. Кроме того, они могут использовать двоичный формат (который более эффективен), такой как Avro или Protocol Buffers.