Это шестая статья в серии статей Micro in Action, посвященных Micro. Мы начнем с основных понятий и тем, а затем перейдем к расширенным функциям.

Сегодняшняя тема - Service Discovery.

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

Но в производственной среде нам нужны более надежные продукты. Существует довольно много высоконадежных реестров, таких как etcd / consul / zookeeper / eureka и так далее. Для этих продуктов Micro предоставляет соответствующие плагины. Он даже предоставляет плагин для Kubernetes, чтобы использовать Kubernetes в качестве центра регистрации.

Из всех этих продуктов наиболее популярным в настоящее время является etcd. Это также официально рекомендованное решение со встроенной поддержкой Micro. Поэтому, если вы хотите использовать etcd в Micro, например mDNS, вы можете использовать его без каких-либо плагинов.

Подключиться к etcd

А теперь давайте попробуем подключить etcd в примере проекта.

Установка и настройка etcd не является предметом этой статьи (дополнительную информацию можно найти на официальном сайте etcd), чтобы не предположить, что у вас уже есть трехузловой кластер etcd, адреса:

  • etcd1.foo.com:2379
  • etcd2.foo.com:2379
  • etcd3.foo.com:2379

Поскольку Micro имеет встроенную поддержку etcd, нам не нужно вносить какие-либо изменения в исходный код проекта hello-service, просто укажите два дополнительных аргумента при запуске проекта:

  1. реестр ， укажите имя реестра. Переменная среды $ MICRO_REGISTRY имеет тот же эффект, что и этот аргумент.
  2. registry_address ， укажите адрес реестра, несколько адресов через запятую. Переменная среды $ MICRO_REGISTRY_ADDRESS имеет тот же эффект, что и этот аргумент.

Результаты приведены ниже:

$ go run main.go plugin.go --registry=etcd --registry_address=etcd1.foo.com:2379,etcd2.foo.com:2379,etcd3.foo.com:2379
2020-04-03 17:52:04  level=info Starting [service] com.foo.service.hello
2020-04-03 17:52:04  level=info Server [grpc] Listening on [::]:55300
2020-04-03 17:52:04  level=info Broker [eats] Connected to [::]:55303
2020-04-03 17:52:04  level=info Registry [etcd] Registering node: com.foo.service.hello-4bf682c8-2114-4f9c-88e0-91f870a17c72
2020-04-03 17:52:04  level=info Subscribing to topic: com.foo.service.hello

Обратите внимание на слова «Реестр [etcd]», которые указывают на то, что в данный момент установлено соединение с кластером etcd!

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

$ go run main.go plugin.go --registry=etcd --registry_address=etcd1.foo.com:2379,etcd2.foo.com:2379,etcd3.foo.com:2379
Hello Bill 4
$

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

$ MICRO_REGISTRY=etcd MICRO_REGISTRY_ADDRESS=etcd1.foo.com:2379,etcd2.foo.com:2379,etcd3.foo.com:2379 go run main.go plugin.go
Hello Bill 4
$

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

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

$ micro web --registry=etcd --registry_address=etcd1.foo.com:2379,etcd2.foo.com:2379,etcd3.foo.com:2379
...
$ micro get service com.foo.service.hello --registry=etcd --registry_address=etcd1.foo.com:2379,etcd2.foo.com:2379,etcd3.foo.com:2379
...

Но это ограничено только встроенным реестром etcd и mdns. Если вы хотите использовать другие плагины, вам необходимо перекомпилировать инструмент командной строки, что, очевидно, не является хорошим решением. Кажется, что мы можем загружать плагины во время выполнения с micro. Если это возможно, это был бы идеальный способ. Подробности, связанные с этой темой, будут рассмотрены отдельно в последующих статьях.

Подключиться к консулу

Хотя Micro рекомендует использовать etcd, вы всегда можете выбрать другие варианты. Ниже мы используем примеры, чтобы проиллюстрировать использование consul в Micro.

Предположим, у нас есть кластер консула с тремя узлами, его адреса:

  • consul1.foo.com:8300
  • consul2.foo.com:8300
  • consul3.foo.com:8300

запустите hello-service с соответствующими аргументами:

$ go run main.go plugin.go --registry=consul --registry_address=consul1.foo.com:8300,consul2.foo.com:8300,consul3.f
oo.com:8300
Registry consul not found
NAME:
    com.foo.service.hello - a go-micro service
USAGE:
    main [global options] command [command options] [arguments...]
COMMANDS:
    help, h  Shows a list of commands or help for one command
GLOBAL OPTIONS:
    --client value Client for go-micro; rpc [$MICRO_CLIENT]
    ...

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

Как упоминалось в предыдущих статьях, каждый созданный нами проект имеет пустой файл с именем plugin.go, который является местом для импорта подключаемых модулей в соответствии с соглашением Micro. Мы модифицируем этот файл, чтобы решить указанную выше проблему:

package main
import (
   _ "github.com/micro/go-plugins/registry/consul/v2"
)

Конечно, нам также необходимо изменить файл go.mod:

module hello
go 1.13
require (
   github.com/golang/protobuf v1.3.2
   github.com/micro/go-micro/v2 v2.4.0
   github.com/micro/go-plugins/registry/consul/v2 v2.3.0 // indirect
)

Обратите внимание, что v2.3.0 очень важен. Потому что это версия подключаемого модуля, соответствующая micro v2.4.0. Если не указано иное, будут внесены другие ошибки.

Измените исходный код и снова запустите его:

$ go run main.go plugin.go --registry=consul --registry_address=consul1.foo.com:8300,consul2.foo.com:8300,consul3.foo.com:8300
2020-04-03 17:45:46  level=info Starting [service] com.foo.service.hello
2020-04-03 17:45:46  level=info Server [grpc] Listening on [::]:54553
2020-04-03 17:45:46  level=info Broker [eats] Connected to [::]:54556
2020-04-03 17:45:46  level=info Registry [consul] Registering node: com.foo.service.hello-6a2605ad-33bb-42e2-bed3-acf370bcee14
2020-04-03 17:45:46  level=info Subscribing to topic: com.foo.service.hello
2020-04-03 17:45:47  level=info Handler Received message: 2020-04-03 17:45:47.376995 +0800 CST m=+23888.008850100
2020-04-03 17:45:48  level=info Handler Received message: 2020-04-03 17:45:48.379199 +0800 CST m=+23889.011087322

На данный момент наша программа успешно подключилась к консул-кластеру. Тоже выглядит очень просто.

Но вам может быть интересно, почему значение параметра —-registry - consul, а не cnsl или что-то еще? Где я могу найти название реестра?

Это восходит к тому, что Micro всегда плохо получалось: отсутствие документации. Единственный способ ответить на поставленные выше вопросы: покопаться в исходном коде.

Но я дам вам несколько подсказок, надеясь немного вам помочь. Возьмем, к примеру, плагин consul. Основной исходный код находится в github.com/micro/go-plugins/registry/consul/v2/consul.go:

func init() { 
    cmd.DefaultRegistries["consul"] = NewRegistry
}

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

Два приведенных выше примера демонстрируют превосходство архитектуры подключаемых модулей Micro. Независимо от того, используете ли вы etcd или consul, у нас почти нет изменений кода. Фреймворк полностью скрывает сложность различных продуктов от бизнес-логики. Поскольку нет вторжения в бизнес-код, мы можем легко интегрировать и / или переключаться между разными реестрами.

Конечно, преимуществ плагина Micro больше, чем это, мы увидим больше примеров в следующих статьях.

Заключение

Micro поддерживает практически все продукты реестра, представленные на рынке. В этой статье используются etcd и consul в качестве примеров для конкретных объяснений.

Хотя есть некоторые детали, которые не идеальны, функция Micro для обнаружения сервисов полная и элегантная.

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

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

Продолжение следует.

Смотрите также: