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

Question

Допустим, я создаю приложение чата с микросервисной архитектурой. У меня есть 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? Мне все еще нужно сохранять собственную версию промежуточного программного обеспечения для динамического обнаружения служб?

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

Answer 1

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

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

Вот примеры файлов манифеста / 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: