Как определить контракт на обслуживание REST для совместного использования несколькими похожими сервисами? - PullRequest
0 голосов
/ 18 февраля 2019

Я реализую серию микро-сервисов REST на Java - назовем их «адаптерами».

Каждый сервис читает данные из определенного типа источника и предоставляет результат тем же способом.Основная идея состоит в том, чтобы иметь одинаковый интерфейс (сервисный контракт) для всех них, чтобы получить взаимозаменяемость.Я хотел бы избежать дублирования кода и повторно использовать сервисный контракт на услуги.

И, похоже, я заново изобретаю колесо.Существует ли стандартный подход для этого?

Я попытался извлечь контракт на обслуживание в виде интерфейса Java для класса Spring MVC Controller и сопровождающего его класса DAO CustomObject:

public interface AdapterController {

    @RequestMapping(method = RequestMethod.GET, value = "/objects/{name}")
    CustomObject getObject(@PathVariable final String name);

}

Затем поместитеих в отдельный проект Maven, установите его как зависимость в исходном проекте и переписали класс контроллера REST следующим образом:

@RestController
public class DdAdapterController implements AdapterController {

    @Override
    public CustomObject getObject(String name) {
        return model.getByName(name);
    }

Я также могу повторно использовать объект DAO в клиентском коде, но класс интерфейсабесполезен на стороне клиента.

1) Подводя итоги: можно ли повторно использовать / разделять сервисный контракт между различными реализациями сервисов?Какова стоимость этого?Есть ли лучшая практика, как делиться контрактом на обслуживание?

2) Следующий вопрос о контракте на обслуживание и потреблении клиента.Можно ли разделить договор между сервисом и клиентом?Есть ли в Java какие-нибудь инструменты / подходы для этого?

Ответы [ 2 ]

0 голосов
/ 19 февраля 2019

Это идет вразрез с менталитетом микросервиса, и в долгосрочной перспективе плохая идея делиться кодом.

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

Многие говорили об этом ранее:

microservices-dont-create-shared-library

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

Микро сервисы: совместно используемая библиотека против дублирования кода

Ключ к созданию микросервисов:

  • Один сервис должен быть очень хорош в одном
  • Держать их маленькими
  • Иметь чрезвычайно хорошо документированные API
  • Когда вам нужно удалить микросервисэто должно быть сделано с минимальными потребностями в обновлении других служб
  • Избегайте совместного использования кода и рассматривайте все библиотеки как сторонние библиотеки , даже свои собственные
0 голосов
/ 18 февраля 2019
  1. Микросервисы должны быть слабо связаны = минимальные зависимости.

    Микросервисы - это архитектурный стиль, который структурирует приложение как набор сервисов, которые

    • Легко обслуживаемые и тестируемые
    • Слабосвязанные
    • Независиморазвертываемый
    • Организован вокруг бизнес-возможностей.

https://microservices.io/

Контракт может быть определен с WADL

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