HATEOAS и Microservices

Question

У меня возникли серьезные проблемы с тем, как HATEOAS и Microservices могут сосуществовать.

Давайте рассмотрим пример:

Допустим, у нас есть корзина ресурса. И нам нужно положить в него снимки продуктов, например. идентификатор продукта, цена продукта; моментальный снимок текущей цены, когда элемент был добавлен в корзину, и, возможно, некоторые другие значения. Фактический прецедент не имеет значения, но просто для того, чтобы получить представление об этой проблеме.

Когда я раньше делал HATEOAS, я бы поместил ссылку в ресурс корзины покупок, которая ссылается на продукты или URL-адрес шаблона, который ссылается на определенный продукт.

Таким образом, клиент все еще может не знать URL-адреса ресурса.

Но в мире микросервиса служба не должна знать никаких других услуг. НАСКОЛЬКО МНЕ ИЗВЕСТНО.

Итак, как они могли работать вместе?

Моя интерпретация микросервисов заключается в том, что они никогда не могут ссылаться ни на что другое, кроме них, что в значительной степени будет ссылкой Self.

Я нашел тот же вопрос, заданный в этих местах, например. https://groups.google.com/forum/#!topic/api-craft/YRkLFVY_zFc

Где используются решения, такие как «услуги макросов», которые используют все это вместе. Это не похоже на чистый способ решения проблемы.

[Редактировать]

Я нашел более хорошую информацию по теме: https://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress

Это кажется хорошо, когда есть какой-то инструмент augument ресурсы со ссылками, но это заставляет меня думать, где логика решения о том, какие ссылки должен иметь ресурс? В службе, которая предоставляет ресурс? В центральном реестре службы?

Answer 1

Но в мире микросервиса служба не должна знать о других услугах . НАСКОЛЬКО МНЕ ИЗВЕСТНО.

Я думаю, что это корень вашего замешательства. Я понимаю, что служба не должна полагаться на внеполосную информацию для связи с другими службами с целью разработки программного обеспечения. Это означает, что служба не должна знать ничего о внутренностях своих сверстников, но не имеет смысла говорить, что она не должна знать других сервисов. Это не противоречит HATEOAS, по сути, они дополняют друг друга.

Нет проблем с подключением к другим службам. Как еще вы могли бы построить макросервис из микросервисов? Существует проблема с использованием внеполосной информации для этого.

Answer 2

Медиация, аранжировка и Хореография услуг не ограничивается к SOA, но в равной степени относится и к архитектуре Microservices, а также.

Значение микросервисов может связываться с другими микросервисами для передачи или получения информации. Например, микросервис должен также зависеть от хранилища данных с сохранением состояния в стеке контейнеров. Поэтому необходимо знать API/интерфейс для базы данных (RESTFull) ..

HATEOAS в основном обеспечивает взаимодействие и дизайн связи модели, так что вы свободны от сказать, язык определения фиксированного интерфейса как WSDL или Swagger.

Хотя верно, что REST (HTTP) стали наиболее известными, поскольку иногда считается, что микросервис будет служить REST API, но это не так.

Красота микросервисов заключается в том, что они не ограничивают вас одним из двух шаблонов связи, независимо от их. Стандартов нет.

Например, реактивные микросервисы подчеркивают использование шаблона связи с сообщением и становятся прозрачными друг от друга. Но это не означает, что вы не знаете о глаголах & полезных данных других микросервисов для передачи или извлечения.

Аналогично, мы можем использовать шаблоны связи на основе HATEOAS, встроенные в нашу архитектуру микросервисов, чтобы быть полностью гибкими для постоянно меняющихся/модернизирующих интерфейсов микросервисов. Но в целом вам нужно знать местоположение микросервиса для связи. Таким образом, службы обнаружения и шаблоны реестра службы существуют в микросервисах wold; и они одинаково применимы к архитектуре HATEOAS. Где наш контейнер для микросервисов может жить и умирать (масштабировать & вниз) в зависимости от нагрузки; нашим клиентам постоянно нужно знать активное местоположение микросервиса (-ов), которое будет потребляться.