Интеграция внешних сервисов в микросервисную архитектуру

Question

Я занимаюсь разработкой приложения для книжного магазина на основе архитектуры микросервисов с использованием Spring и Netflix OSS.

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

Одна услуга - это служба доставки, это внутренняя служба. Подключено через клиент Feign.

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

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

Но теперь я думаю, что это немного неловкое решение.

Знаете ли вы, какая архитектура лучше всего подходит для подключения к внешним или внутренним службам?

Answer 1

Во-первых, правильно ли это, что я понимаю?

Комплексное обслуживание - (использование) -> служба доставки

---------------------------- (использовать) -> служба инвентаризации (этот проект использует внешний библиотека)

Если это правильно, я думаю, что это не сложно издеваться.

Создание проекта микросервиса инвентаризации для упаковки внешней библиотеки.

Потому что сложному сервису не нужно заботиться о том, что нам нужно, чтобы использовать определенную библиотеку для инвентаря. Ваш проект микросервиса Inventory просто предоставляет конечную точку для использования сервиса инвентаризации.

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

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

@Configuration
class MessageHandlerTestConfiguration {

  @Bean
  public InventoryClient inventoryClient() {
    return Mockito.mock(InventoryClient.class);
  }

Answer 2

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

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

Вы можете найти более подробную информацию об антикоррупционном слое здесь https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used