Микросервисная структура с использованием шлема и кубернетес - PullRequest
Новая
       4

Микросервисная структура с использованием шлема и кубернетес

1 голос
/ 09 марта 2020

У нас есть несколько микросервисов (приложения на основе NodeJS), которые должны взаимодействовать друг с другом, и два из них используют Redis и PostgreSQL. Ниже приведены названия моих микросервисов. Каждый из них имеет свой собственный репозиторий SCM и Helm Chart.Helm версии 3.0.1. У нас есть две среды, и у нас есть два значения. Yaml для каждой среды. У нас также есть три узла на кластер.

Прежде всего, после действия конечного пользователя служба пользовательского интерфейса запускается, а не отправляется на серверную часть. В соответствии с запросом конечного пользователя сервисы Backend должны взаимодействовать с любыми сервисами, такими как Market, Auth и API. В некоторых случаях API и микросервис Market также должны взаимодействовать с микросервисом Auth.

  1. UI ->
  2. Backend
  3. Market -> использовать postgreSQL
  4. Auth -> использовать Redis
  5. API

Итак мои вопросы:

  • Что мы должны сделать, чтобы взаимодействовать между собой микроуслугами? Этого my-svc-namespace.svc.cluster.local достаточно, чтобы предоставить разработчикам, или мы также должны указывать ENV в каждом модуле?

  • Наши микросервисы - это приложение NodeJS. Как разработчики. будет обрабатывать это в исходном коде приложения? Использовали ли они это имя службы, если ответ на первый вопрос был положительным?

  • Мы хотели бы представить наше приложение через вход с использованием хоста для каждой среды? Я полагаю, вход должен быть включен только для микросервиса пользовательского интерфейса, правильно?

  • Каков наилучший способ проверки того, что каждая служба может общаться друг с другом? 

kubectl get svc --all-namespaces

NAMESPACE     NAME                                         TYPE            

database      my-postgres-postgresql-helm                  ClusterIP                      
dev           my-ui-dev                                    ClusterIP 
dev           my-backend-dev                               ClusterIP 
dev           my-auth-dev                                  ClusterIP                 
dev           my-api-dev                                   ClusterIP 
dev           my-market-dev                                ClusterIP
dev           redis-master                                 ClusterIP                       
ingress       ingress-traefik                              NodePort

1 Ответ

1 голос
/ 09 марта 2020

Два способа выполнить обнаружение служб в K8S

Существует два способа выполнить обмен данными (обнаружение служб) в кластере Kubernetes.

DNS - это самый простой способ обнаружения служб в кластере. И это не требует каких-либо дополнительных настроек переменной ENV для каждого модуля. Проще всего, служба в том же пространстве имен доступна через имя службы. например, http://my-api-dev: ПОРТ доступен для всех модулей в пространстве имен, dev.

Стандартное имя приложения и имя службы K8s

На практике вы можете дать каждому приложению стандартное имя, например. my-ui, my-backend, my-api и др. c. И используйте то же имя для подключения к приложению. Эта практика может быть даже применена для локального тестирования из среды разработчика с записью в /etc/host как 

127.0.0.1 my-ui my-backend my-api

(Выше не имеет ничего общего с k8s, просто практика общения приложений с их именами в локальные среды)

Кроме того, на k8s вы можете назначить имя службы как одно и то же имя приложения (старайтесь избегать суффиксов, подобных -dev для имени службы, которые отражают среды (dev, test, prod, et c), вместо этого используйте пространство имен или отдельный кластер). Таким образом, конечные точки целевого приложения могут быть настроены с использованием их имени службы в файле конфигурации каждого приложения.

Вход для служб с внешним доступом

Вход должен быть включен только для службы, требующие внешнего доступа.

Настраиваемые конечные точки проверки работоспособности

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

...