Обнаружение сервисов gRPC и выбор технологии управления сервисами

gRPC
Обнаружение сервисов gRPC и выбор технологии управления сервисами

[Оригинал статьи, пожалуйста, указывайте источник для перепечатки, спасибо!]

Обнаружение службы GRPC и управление службами, в настоящее время существует два типа распространенных решений.

  • Nginx + consul + consul-template
  • Envoy

В этой статье кратко объясняются преимущества и недостатки двух схем.

1. nginx + консул + консул-шаблон

Этапы реализации

  1. Микросервис grpc зарегистрирован в консуле, и консул будет периодически отправлять тактовые импульсы микросервису grcp.
  2. Когда узел консула обновляется, consul-template генерирует файл nginx-consul.conf.
  3. Nginx Reload завершает обновление службы, обновляет при наличии запроса, UPSTREAM перенаправляет на микросервис GRPC.

Nginx-consul.conf примерно выглядит следующим образом

# nginx需要安装grpc模块
upstream User {
    server 127.0.0.1:17000;
    server 127.0.0.1:18000;
}
server {
    listen       19000 http2;
    server_name  _;
    
    location /protobuf.User {
        default_type application/grpc;
        grpc_pass grpc://User;
    }
}

преимущество

  1. Простота использования, богатая документация

недостаток

  1. Сердцебиение консула основано только на пинге порта tcp, и невозможно определить, нормально ли отвечает служба.
  2. Когда узел переходит в онлайн или офлайн, требуется перезагрузка nginx. Существует определенный риск (микросервисы неизбежно будут вызывать скрытые ошибки или паники при работе. Если перезагрузка nginx требуется каждый раз для обеспечения правильной маршрутизации, я думаю, что стоимость слишком высока)

Два .envoy.

Envoy разработан для крупномасштабной современной архитектуры SOA (Service Oriented Architecture) L7 и коммуникационной шины. Является одним из важных компонентов istio

Все обнаружили что на этой картинке отсутствует реестр консула.Значит ли использование Envoy не требует реестра?Ответ зависит от ситуации
Поскольку Envoy поддерживает динамическую настройку, он используется с пилотом в Istio.Pilot может получать онлайн-ноды через центры регистрации, такие как консул и etcd, а затем динамически регистрироваться в Envoy.

envoy.yaml

node:
  id: id_1
  cluster: test_cluster

watchdog:
  miss_timeout: 0.2s
  megamiss_timeout: 1s
  kill_timeout: 0s
  multikill_timeout: 0s

admin:
  access_log_path: /var/log/admin_access.log
  address:
    socket_address: { address: 127.0.0.1, port_value: 10000 }

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 127.0.0.1, port_value: 19000 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          codec_type: HTTP2
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/protobuf.User" }
                route: { cluster: xds_cluster }
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_cluster
    connect_timeout: { seconds: 1 }
    type: STATIC
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    hosts:
    - socket_address: { address: 127.0.0.1, port_value: 18000 }
    - socket_address: { address: 127.0.0.1, port_value: 17000 }
    health_checks:
    - grpc_health_check: {service_name: YourServiceName}
      unhealthy_threshold : 1
      healthy_threshold: 1
      timeout: 0.5s
      interval: 0.5s
      interval_jitter: 0.5s

Это конфигурация статической маршрутизации с проверкой работоспособности grpc, есть четыре ключевых момента.

  1. слушатели: слушайте 127.0.0.1:19000
  2. фильтры: фильтрация запросов grpc и маршрутизация к xds_cluster
  3. кластеры : кластеры хостов
  4. Health_checks: Check Health GRPC

Как реализовать проверку работоспособности grpc

# 引入protobuf包google.golang.org/grpc/health/grpc_health_v1并实现里面的Check和Watch方法
package health
import(
	"log"
	"context"
	pb "google.golang.org/grpc/health/grpc_health_v1"
)
type Health struct{}
func New() *Health {
	return &Health{}
}
func (h *Health) Check(ctx context.Context, in *pb.HealthCheckRequest) (*pb.HealthCheckResponse, error){
	log.Printf("checking............%s", in.Service)
	var s pb.HealthCheckResponse_ServingStatus = 1
	return &pb.HealthCheckResponse{
		Status : s,
	}, nil
}
func (h *Health) Watch(in *pb.HealthCheckRequest, w pb.Health_WatchServer) (error){
	log.Printf("watching............%s", in.Service)
	var s pb.HealthCheckResponse_ServingStatus = 1
	r := &pb.HealthCheckResponse{
		Status : s,
	}
	for {
		w.Send(r)
	}
	return nil
}

# 服务注册
pb.RegisterHealthServer(grpcServer, health.New())

После запуска служб envoy и grpc grpc получит пульс (пульс по умолчанию — 60 секунд, а параметр пульса yaml — 0,5 секунды).
YourServiceName — это параметр service_name для grpc_health_check в yaml, здесь вы можете настроить метод, который хотите отслеживать.

преимущество

  1. Легкий, ненавязчивый. Обнаружение службы активно обнаруживается посланником, grpc не требует специальной настройки,
  2. Поставляется с проверкой работоспособности grpc
  3. Динамическая конфигурация

недостаток

  1. Есть несколько соответствующих китайских документов

Суммировать

По сравнению с nginx я предпочитаю envoy.Во-первых, envoy — это инструмент балансировки нагрузки для микросервисов.Проверка работоспособности grpc — важная часть микросервисов.Однако у nginx есть активное сообщество, и, возможно, в ближайшем будущем их станет больше , Плагин для проверки работоспособности grpc.

Категории