Как работает динамическое обнаружение служб при использовании Docker Compose или Kubernetes?

Допустим, я создаю приложение для чата с микросервисной архитектурой. У меня есть 2 услуги:

  1. Служба шлюза: отвечает за аутентификацию пользователя (конечная точка API /api/v1/users) и маршрутизацию запросов к соответствующей службе.

  2. Служба обмена сообщениями: отвечает за создание, получение, обновление и удаление сообщений (конечная точка API /api/v1/messages).

Если я использую Docker Compose или Kubernetes, как моя служба шлюза узнает, на какую службу она должна перенаправляться, если есть запрос, отправляемый на конечную точку /api/v1/messages API?

Раньше я писал собственное промежуточное ПО для динамического обнаружения служб (https://github.com/zicodeng/tahc-z/blob/master/servers/gateway/handlers/dsd.go). Идея заключается в том, что я предварительно регистрирую службы с конечными точками API, за которые они отвечают. И моя служба шлюза полагается на путь ресурса запроса, чтобы решить, в какую службу этот запрос следует перенаправить. Но как это сделать с помощью Docker Compose или Kubernetes? Нужно ли мне по-прежнему сохранять собственную версию ПО промежуточного слоя для динамического обнаружения служб?

Заранее спасибо!


kubernetes docker microservices docker-compose service-discovery
person Zico Deng    schedule 10.09.2018    source источник
comment
Вы ищете обратный прокси? Входной контроллер Nginx или Traefik для обратного прокси-сервера kubernetes   -  person onuryartasi    schedule 10.09.2018
comment
@OnurYartaşıСпасибо, посмотрю!   -  person Zico Deng    schedule 10.09.2018

Ответы (1)


arrow_upward
2
arrow_downward

Если вы используете Kubernetes, вот основные шаги:

  1. Создавайте развертывания/рабочие нагрузки микросервисов, используя образы докеров.
  2. Создайте службы, указывающие на эти развертывания
  3. Создайте Ingress, используя правила на основе пути, указывающие на службы

Вот примеры файлов манифеста/yaml: (при необходимости измените образы докеров, порты и т. д.)

apiVersion: v1
kind: Service
metadata:
  name: svc-gateway
spec:
  ports:
    - port: 80
  selector:
    app: gateway
---
apiVersion: v1
kind: Service
metadata:
  name: svc-messaging
spec:
  ports:
    - port: 80
  selector:
    app: messaging
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deployment-gateway
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: gateway
    spec:
      containers:
      - name: gateway
        image: gateway/image:v1.0
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deployment-messaging
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: messaging
    spec:
      containers:
      - name: messaging
        image: messaging/image:v1.0
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-for-chat-application
spec:
  rules:
  - host: chat.example.com
    http:
      paths:
      - backend:
          serviceName: svc-gateway
          servicePort: 80
        path: /api/v1/users
      - backend:
          serviceName: svc-messaging
          servicePort: 80
        path: /api/v1/messages

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

Например: curl http://svc-messaging или curl http://svc-gateway

Вам не нужно запускать собственное обнаружение сервисов, об этом позаботится Kubernetes!

Некоторые визуальные эффекты:

Шаг 1: развертывания

Шаг 2: услуги

Шаг 3: вход

person leodotcloud    schedule 11.09.2018
comment
Большое спасибо. Это очень полезно! - person Zico Deng; 11.09.2018