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

Посредством чего или с помощью чего взаимодействует один микросервис с другим?
    

Ответы

Ответ 1

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




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


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


Ответ 2

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