Как работает динамическое обнаружение сервисов при использовании docker compose или kubernetes?

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

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

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

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

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

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

Вы ищите обратный прокси? Контроллер входящего трафика Nginx или Traefik для обратного прокси Kubernetes

onuryartasi 10.09.2018 10:18

@ OnurYartaşıСпасибо, посмотрю!

Zico Deng 10.09.2018 20:53
0
2
156
1

Ответы 1

Если вы используете 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: deployments

Шаг 2: services

Шаг 3: ingress

Большое спасибо. Это очень полезно!

Zico Deng 11.09.2018 21:50

Другие вопросы по теме