Использование Docker в качестве реестра сервисов для микросервисов

Question

Я следовал некоторому руководству, в котором рассказывается, как настроить 3 микросервиса (приложение, продукты и отзывы) и 1 реестр служб.

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

Например, в следующем файле Docker Compose я передаю учетные данные db из микросервиса MySQL в микросервис Node.js и вАналогичным образом, если бы были другие микросервисы Node.js, я мог бы подключить их.

version: '3'

services:

  mysql:
    image: "mysql:5.7"
    container_name: "mysql"
    ports:
      - "6603:3306"
    volumes:
      - ./assets/schema.sql:/docker-entrypoint-initdb.d/init.sql
    environment:
      DATABASE_HOST: mysql
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: database
      MYSQL_USER: mysql
      MYSQL_PASSWORD: password

  products_service:
    build: .
    command: bash -c "/wait && npm start"
    volumes:
      - "./src/:/service/src/"
    image: "node"
    container_name: "products"
    ports:
      - "8080:8080"
    depends_on:
      - mysql
    environment:
      DATABASE_HOST: mysql
      MYSQL_PORT: 3306
      MYSQL_DATABASE: database
      MYSQL_USER: mysql
      MYSQL_PASSWORD: password
      WAIT_HOSTS: mysql:3306
    restart: on-failure

Действительно ли мне нужно кодировать и программировать службу реестра в Node.js?

Answer 1

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

Честно говоря, вы можете начать с запуска некоторых экземпляров своих сервисов и обслуживать своих пользователей. Но вы не сможете реагировать на нагрузки и сбои, а также эффективно использовать ресурсы. Вот где такие инструменты, как k8s, позволяют вам находить сервисы и использовать ресурсы.

Проверьте этот разговор, чтобы понять больше об обнаружении сервиса.

Answer 2

Предполагая, что ваш продукт обслуживает конечные точки отдыха, которые использует внешний мир https://myserver/myservice.

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

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

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

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

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

References-

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

https://auth0.com/blog/an-introduction-to-microservices-part-3-the-service-registry/