Рубрики
Uncategorized

Балансировка нагрузки Сервис GRPC с Nginx

До сих пор мы много узнали о том, как развить Backend Web Services с GRPC. Когда дело доходит до … Tagged с Go, учебником, WebDev, Devops.

Полный курс GRPC (16 частей серии)

До сих пор мы много узнали о том, как развить Backend Web Services с GRPC. Когда дело доходит до развертывания, одна важная вещь, которую мы должны рассмотреть, — это балансировка нагрузки.

Большое развертывание GRPC обычно имеет ряд идентичных бэкэнд-серверов и ряд клиентов. Балансировка нагрузки используется для распределения нагрузки от клиентов оптимально по доступным доступным серверам.

Вот ссылка на Pull GRPC курс плейлист на YouTube Gitlab Repository: PCBook-Go и ПК- Ява

Оглавление

  • Типы балансировки нагрузки
    • Балансировка нагрузки на стороне сервера
    • Балансировка нагрузки на стороне клиента
    • Плюсы и минусы
  • Рефакторинг кода
    • Обновить сервер
    • Обновить клиент
    • Проверьте новый флаг
  • Обновить makefile.
  • Установить nginx.
  • Config nginx для небезопасной GRPC
  • Config nginx для GRPC с TLS
    • Включить TLS на Nginx, но держите серверы GRPC небезопасны
    • Включить TLS на Nginx и GRPC серверы
    • Несколько местоположений маршрутизации

Типы балансировки нагрузки

Существует 2 основных варианта балансировки нагрузки GRPC: серверная сторона и клиентская сторона. Решать, какой из них используется, является основным архитектурным выбором.

Балансировка боковой нагрузки на сервер

В балансировке нагрузки на боковых серверах клиент выдает RPC для балансировщика нагрузки или прокси, например Nginx или Посланник . Балансировщик нагрузки распределяет вызов RPC к одному из доступных бэкэнд-серверов.

Он также отслеживает нагрузку на каждый сервер и реализует алгоритмы для распространения нагрузки справедливо. Сами клиенты не знают о бэкэнд-серверах.

Балансировка боковой нагрузки клиента

В балансировке нагрузки на стороне клиента клиент знает множественные бэкэнд-серверы и выбирает один для использования для каждого RPC. Обычно серверы Backend регистрируют себя с инфраструктурой открытия услуг, такие как Консул или Etcd Отказ Затем клиент связывается с этой инфраструктурой, чтобы узнать адреса серверов.

Толстый клиент реализует саму алгоритмы балансировки нагрузки. Например, в простой конфигурации, где нагрузка на серверу не рассматривается, клиент может просто круглый ромин между доступными серверами.

Другим подходом является использование балансировщика нагрузки на загрузку, где смартты балансировки нагрузки реализуются на специальном сервере балансировки нагрузки. Клиенты запрашивают балансировщик Look-To Load, чтобы получить лучший сервер (ы) для использования. Тяжелая съемка хранения серверного состояния, открытия услуг и внедрение алгоритма балансировки нагрузки консолидируется в балансе оглядывания нагрузки.

Плюсы и минусы

Одним плюсом балансировки нагрузки на серверу является простой реализацией клиента. Все клиенту нужно знать, это адрес прокси, больше не требуется кодирование. Этот подход работает даже для ненадежных клиентов, что означает, что служба GRPC может быть открыта для всех из общественного Интернета.

Тем не менее, его минусы добавляют еще 1 дополнительную прыжку на вызов. Все RPC должны пройти через прокси, прежде чем добраться до сервера Backeng, что вызывает более высокую задержку. Следовательно, эта балансировка нагрузки на серверу подходит для случаев, когда есть много клиентов, возможно, ненавидших от открытого Интернета, который хочет подключиться к нашим серверам GRPC в центре обработки данных.

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

В этой статье мы узнаем, как настроить балансировку нагрузки на серверу для нашего GRPC Услуги с Nginx Отказ

Рефакторинг кода

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

Обновить сервер

На сервере давайте добавим новый логический флаг Enabletls , что скажет нам, хотите ли мы включить TLS на нашем сервере GRPC или нет. Его значение по умолчанию это ложь Отказ

func main() {
    port := flag.Int("port", 0, "the server port")
    enableTLS := flag.Bool("tls", false, "enable SSL/TLS")

    flag.Parse()
    log.Printf("start server on port %d, TLS = %t", *port, *enableTLS)

    ...
}

Затем давайте извлечь перехватчики до отдельной ServerOptions Переменная. Мы проверяем Enabletls флаг. Только в случае, если он включен, то мы загружаем учетные данные TLS и добавьте это учетные данные на ломтик параметров сервера. Наконец, мы просто передаем параметры сервера к GRPC. Газер () Функциональный вызов.

func main() {
    ...

    interceptor := service.NewAuthInterceptor(jwtManager, accessibleRoles())
    serverOptions := []grpc.ServerOption{
        grpc.UnaryInterceptor(interceptor.Unary()),
        grpc.StreamInterceptor(interceptor.Stream()),
    }

    if *enableTLS {
        tlsCredentials, err := loadTLSCredentials()
        if err != nil {
            log.Fatal("cannot load TLS credentials: ", err)
        }

        serverOptions = append(serverOptions, grpc.Creds(tlsCredentials))
    }

    grpcServer := grpc.NewServer(serverOptions...)

    ...
}

И это это для сервера. Давайте сделаем подобное для клиента!

Обновить клиент

Сначала мы добавляем Enabletls Флаг к аргументу командной строки. Тогда мы определяем Транспортировка Переменная с значением по умолчанию GRPC. Isecure () Отказ

func main() {
    serverAddress := flag.String("address", "", "the server address")
    enableTLS := flag.Bool("tls", false, "enable SSL/TLS")

    flag.Parse()
    log.Printf("dial server %s, TLS = %t", *serverAddress, *enableTLS)

    transportOption := grpc.WithInsecure()

    if *enableTLS {
        tlsCredentials, err := loadTLSCredentials()
        if err != nil {
            log.Fatal("cannot load TLS credentials: ", err)
        }

        transportOption = grpc.WithTransportCredentials(tlsCredentials)
    }

    cc1, err := grpc.Dial(*serverAddress, transportOption)
    if err != nil {
        log.Fatal("cannot dial server: ", err)
    }

    authClient := client.NewAuthClient(cc1, username, password)
    interceptor, err := client.NewAuthInterceptor(authClient, authMethods(), refreshDuration)
    if err != nil {
        log.Fatal("cannot create auth interceptor: ", err)
    }

    cc2, err := grpc.Dial(
        *serverAddress,
        transportOption,
        grpc.WithUnaryInterceptor(interceptor.Unary()),
        grpc.WithStreamInterceptor(interceptor.Stream()),
    )
    if err != nil {
        log.Fatal("cannot dial server: ", err)
    }

    laptopClient := client.NewLaptopClient(cc2)
    testRateLaptop(laptopClient)
}

Только когда Enabletls Значение флага — истинный Мы загружаем учетные данные TLS из файлов PEM и измените Транспортировка к GRPC. СотранспортКорденские (TLScredentials) . Наконец мы передаем Транспортировка к соединениям GRPC. И клиент сделан.

Проверьте новый флаг

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

И если мы запустим, сделаем клиента, он также работает без TLS, и все вызовы RPC успешно.

Если мы добавим -Тлс Флаг к Сделайте сервер Команда и перезапустите ее, TLS будет включен.

...

server:
    go run cmd/server/main.go -port 8080 -tls

...

Если мы запустим Сделать клиента Теперь запросы потерпят неудачу:

Мы должны включить TLS на стороне клиента, добавив -Тлс Флаг к Сделать клиента команда.

...

client:
    go run cmd/client/main.go -address 0.0.0.0:8080 -tls

...

И теперь мы можем увидеть, что запросы снова успешны.

Обновить makefile.

Хорошо, теперь флаг TLS работает, как мы хотели. Перед добавлением Nginx. Давайте обновим наше Makefile Немного, чтобы мы могли легко запускать несколько экземпляров сервера и клиента с TL или без него.

Я собираюсь удалить -Тлс флаги, чтобы Сделайте сервер и Сделать клиента Команды будут работать без TLS. И я добавлю еще 2 командам для запуска 2 экземпляров сервера на разных портах. Скажем, 1-й сервер будет работать по порту 50051 и 2-й Север будет работать по порту 50052 Отказ

...

server:
    go run cmd/server/main.go -port 8080

client:
    go run cmd/client/main.go -address 0.0.0.0:8080

server1:
    go run cmd/server/main.go -port 50051

server2:
    go run cmd/server/main.go -port 50052

...

Давайте также добавим еще 3 командам для запуска клиента и серверов с TLS. Клиент-TLS Команда запускает клиент с TLS. сделать сервер1-TLS Команда запустит сервер TLS на порту 50051 и Сделать Server2-TLS Команда начнется другой сервер TLS на порту 50052 Отказ

...

client-tls:
    go run cmd/client/main.go -address 0.0.0.0:8080 -tls

server1-tls:
    go run cmd/server/main.go -port 50051 -tls

server2-tls:
    go run cmd/server/main.go -port 50052 -tls

...

Установить nginx.

Следующее, что нам нужно сделать, это установить Nginx. . Так как я на Mac, я могу просто использовать домеров:

❯ brew install nginx

После установки Nginx мы можем перейти к этому usr/local/etc/nginx Папка для настройки. Давайте откроем nginx.conf Файл с визуальным студийным кодом.

❯ cd /usr/local/etc/nginx
❯ code nginx.conf

Это конфигурация по умолчанию:

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       8080;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }

    include servers/*;
}

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

Config nginx для небезопасной GRPC

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

Одно важное, что нам нужно сделать, это настроить правильное местоположение для хранения журнала ошибок и файлов журнала доступа. В моем случае доморь уже создал папку журнала для Nginx на /usr/local/var/log/nginx Поэтому я просто продолжаю и использую его в настройках журнала ошибок/доступа.

worker_processes  1;

error_log  /usr/local/var/log/nginx/error.log;

events {
    worker_connections  10;
}

http {
    access_log  /usr/local/var/log/nginx/access.log;

    server {
        listen       8080 http2;

        location / {
        }
    }
}

Теперь в блоке сервера у нас есть Слушать Команда для прослушивания входящих запросов от клиента на порту 8080 Отказ Это конфигурация по умолчанию для обычного HTTP-сервера. Поскольку GRPC использует Http/2. мы должны добавить http2. В конце этой команды.

Давайте удалим имя сервера и Charmet, так как мы не нуждаемся в них сейчас. Подобно для журнала доступа, потому что мы уже определили его выше. Давайте также удалим конфиг по умолчанию Root HTML-файл и все после место расположения Блок, поскольку мы не заботимся о них на данный момент.

Хорошо, теперь мы хотим загрузить баланс входящих запросов на наши 2 серверных экземпляра. Таким образом, мы должны определить Upstream для них. Я собираюсь называть это upstream pcbook_services Отказ Внутри этого блока мы используем Сервер Ключевое слово для объявления экземпляра сервера. Первый работает на localhost порт 50051 и второй работает на порту 50052 Отказ

worker_processes  1;

error_log  /usr/local/var/log/nginx/error.log;

events {
    worker_connections  10;
}

http {
    access_log  /usr/local/var/log/nginx/access.log;

    upstream pcbook_services {
        server 0.0.0.0:50051;
        server 0.0.0.0:50052;
    }

    server {
        listen       8080 http2;

        location / {
            grpc_pass grpc://pcbook_services;
        }
    }
}

Затем направить все RPC звонки в выше по течению, в место расположения Блок, мы используем grpc_pass ключевое слово, а затем GRPC:// Схема и имя восходящего, что это PCBook_Services Отказ

И это все! Балансировка нагрузки для нашего небезопасного сервера GRPC сделана.

Давайте запустим Nginx в терминале, чтобы начать его.

❯ nginx
❯ ps aux | grep nginx
quangpham         9013   0.0  0.0  4408572    800 s000  S+    6:13PM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox nginx
quangpham         9007   0.0  0.0  4562704   1124   ??  S     6:12PM   0:00.00 nginx: worker process
quangpham         9006   0.0  0.0  4422416    612   ??  Ss    6:12PM   0:00.00 nginx: master process nginx

Мы можем проверить, работает ли он или не использовать PS. и Греп команда. Давайте проверим папку журнала:

❯ cd /usr/local/var/log/nginx
❯ ls -l
total 0
-rw-r--r--  1 quangpham  admin  0 Oct 11 18:12 access.log
-rw-r--r--  1 quangpham  admin  0 Oct 11 18:12 error.log

Как видите, 2 файлы журнала генерируются: Access.log и Error.log Отказ Они пусты в данный момент, потому что мы еще не отправили никаких запросов.

Теперь давайте запустим сделать сервер1 Чтобы начать первый сервер на порту 50051 с TLS Отказ Тогда на другой вкладке, запустите сделать сервер2 Чтобы начать второй сервер на порту 50052 , также с TLS отключен. Наконец, мы бежим Сделать клиента на другой новой вкладке.

Выглядит неплохо. Все RPC вызовы успешны. Давайте проверим журналы на наших серверах.

Server2 Получает 2 создания запросов ноутбука.

И Server1 Получает 1 запрос входа и 1 создать запрос на ноутбук. Отлично!

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

Я надеюсь, что вы все еще помните коды, которые мы написали в лекции перехватчиков GRPC.

Хорошо, теперь давайте посмотрим на файл журнала Access NGINX.

Сначала вы можете увидеть вызов входа в систему, затем 3 создания вызовов для ноутбука и, наконец, еще один вызов входа в систему. Так что все работает точно так, как мы ожидаем.

Далее я покажу вам, как включить SSL/TLS для Nginx Отказ

Config nginx для GRPC с TLS

В типичном развертывании серверы GRPC уже работают внутри доверенной сети, и только балансировщик нагрузки ( nginx в этом случае) подвергается публичному интернету. Таким образом, мы можем оставить наши серверы GRPC без TLS Как и прежде, и только добавить TLS к Nginx Отказ

Включить TLS на Nginx, но держите серверы GRPC небезопасны

Для этого нам нужно будет скопировать 3 файлов PEM в папку Config Nginx:

  • Сертификат сервера
  • Закрытый ключ сервера
  • И сертификат ЦА, который подписал сертификат клиента, если мы используем взаимные TLS.

Хорошо, так что теперь я собираюсь CD к /usr/local/etc/nginx папка и создать новый Сертирование папка. Тогда я буду скопировать эти 3 файла PEM из нашего ПК Проект к этой папке.

❯ cd /usr/local/etc/nginx
❯ mkdir cert
❯ cp ~/Projects/techschool/pcbook-go/cert/server-cert.pem cert
❯ cp ~/Projects/techschool/pcbook-go/cert/server-key.pem cert
❯ cp ~/Projects/techschool/pcbook-go/cert/ca-cert.pem cert

Хорошо, теперь все файлы сертификата и ключей готовы. Давайте вернемся к нашему файлу конфигурации NGINX.

Чтобы включить TLS, нам сначала нужно добавить SSL к Слушать команда. Тогда мы используем ssl_certificate Команда дать Nginx Расположение файла сертификата сервера. И использовать ssl_certificate_key Команда, чтобы дать ему местоположение файла частного ключа сервера.

...

    server {
        listen       8080 ssl http2;

        ssl_certificate cert/server-cert.pem;
        ssl_certificate_key cert/server-key.pem;

        ssl_client_certificate cert/ca-cert.pem;
        ssl_verify_client on;

        location / {
            grpc_pass grpc://pcbook_services;
        }
    }

...

Как мы используем взаимные TLS, нам также нужно использовать ssl_client_certificate Команда, чтобы сказать Nginx расположение файла сертификата клиента CA. И, наконец, мы устанавливаем ssl_verify_client. к на Чтобы сообщить Nginx проверить подлинность сертификата, который отправит клиент.

И мы закончили. Давайте перезапустим Nginx. Мы бежим NGINX -S STOP чтобы остановить это первым. Затем мы начнем его с nginx команда.

❯ nginx -s stop
❯ nginx

Наш сервер уже работает, так что давайте запустим клиента!

Если мы просто запустим Сделать клиента он будет работать без TLS, поэтому запрос не удастся, потому что Nginx теперь работает с включенным TLS.

Теперь давайте запустим сделать клиент-TLS Отказ

На этот раз клиент работает с TLS, и все запросы успешны.

Имейте в виду, что наши серверы все еще бегают без TLS. Так что в основном то, что происходит: только связь между клиентом и Nginx безопасен, а Nginx подключается к нашим серверам Backend через еще одно небезопасное соединение.

Однажды Nginx Получает зашифрованные данные от клиента, он расшифрует данные, прежде чем пересылать его на серверы Backend. Поэтому вы должны использовать только этот подход, если Nginx и Backend Servers остаются в той же доверенной сети.

ОК, но что, если они не на одной надежной сети? Что ж, в этом случае у нас нет выбора, кроме как для включения TLS на наших серверах BackeND, а также конфигурация Nginx, чтобы работать с ним.

Включить TLS на Nginx и GRPC серверы

Давайте остановимся нынешним сервер1. и Server2 Затем перезапустите их TLS.

❯ make server1-tls
❯ make server2-tls

Теперь, если мы запустим сделать клиент-TLS Сразу же запрос не удастся.

Причина в том, что рукопожатие TLS между клиентом и Nginx успешно, рукопожатие TLS между Nginx И наши бэкэнд-серверы не удалось, поскольку серверы Backend теперь ожидают безопасного подключения TLS, а Nginx все еще использует небезопасное соединение при подключении к серверам Backend.

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

Чтобы включить безопасное соединение TLS между Nginx и Upstream, в nginx.conf Файл, мы должны изменить GRPC. Схема к GRPCS Отказ

...

    server {
        ...

        location / {
            grpc_pass grpcs://pcbook_services;
        }
    }

...

Это должно быть достаточно, если мы просто используем Server Side TLS. Однако в этом случае мы используем взаимные TLS, поэтому, если мы просто перезагрузим Nginx Теперь и Rerun сделать клиент-TLS запрос все равно будет терпеть неудачу потому что Nginx не настроен для отправки его сертификата на вершинные серверы.

У нас есть Плохой сертификат Ошибка, как вы можете видеть в журнале.

Посмотрим, что произойдет, если мы перейдем к серверу Code CMD/Server/Main.go и изменить Клиентурут поле из TLS. Требован EANDverifyClientCert к TLS. Noclientcert , что означает, что мы просто будем использовать Server-Side TLS.

func loadTLSCredentials() (credentials.TransportCredentials, error) {
    ...

    // Create the credentials and return it
    config := &tls.Config{
        Certificates: []tls.Certificate{serverCert},
        ClientAuth:   tls.NoClientCert,
        ClientCAs:    certPool,
    }

    return credentials.NewTLS(config), nil
}

Затем перезапустите Server1-TLS и Server2-TLS и беги сделать клиент-TLS снова.

❯ make server1-tls
❯ make server2-tls
❯ make client-tls

На этот раз все запросы успешны. Это именно то, что мы ожидали!

Хорошо, теперь, что если мы действительно хотим взаимных TLS между Nginx и Upstream?

Давайте изменим Клиентурут поле обратно в TLS. Требован EANDverifyClientCert Перезапустите 2 TLS Backend Servers и вернитесь к нашему nginx.conf файл.

На этот раз мы должны проинструктировать Nginx Чтобы сделать взаимные TLS с серверами Backend, предоставив ему местоположение сертификата и закрытого ключа. Мы используем grpc_ssl_certificate Ключевое слово для сертификата и grpc_ssl_certificate_key . Ключевое слово для закрытого ключа.

Вы можете генерировать другую пару сертификата и закрытый ключ для Nginx. если ты хочешь. Здесь я просто использую тот же сертификат и закрытый ключ серверов.

worker_processes  1;

error_log  /usr/local/var/log/nginx/error.log;

events {
    worker_connections  10;
}

http {
    access_log  /usr/local/var/log/nginx/access.log;

    upstream pcbook_services {
        server 0.0.0.0:50051;
        server 0.0.0.0:50052;
    }

    server {
        listen       8080 ssl http2;

        # Mutual TLS between gRPC client and nginx
        ssl_certificate cert/server-cert.pem;
        ssl_certificate_key cert/server-key.pem;

        ssl_client_certificate cert/ca-cert.pem;
        ssl_verify_client on;

        location / {
            grpc_pass grpcs://pcbook_services;

            # Mutual TLS between nginx and gRPC server
            grpc_ssl_certificate cert/server-cert.pem;
            grpc_ssl_certificate_key cert/server-key.pem;
        }
    }
}

Хорошо, давайте попробуем это.

Сначала остановите текущий процесс Nginx, затем начните новый. И Беги сделать клиент-TLS снова.

❯ nginx -s stop
❯ nginx
❯ make client-tls

На этот раз все запросы успешны. Идеально!

Несколько местоположений маршрутизации

Есть еще одна вещь, которую я хочу показать вам, прежде чем мы закончим.

Как вы уже видели, запросы входа в систему и создании ноутбуков теперь равномерно распределены между нашими двумя двусмысленными серверами. Но иногда мы можем захотеть отделить службу аутентификации и службы бизнес-логики.

Например, скажем, мы хотим, мы хотим, чтобы все запросы входа в систему перейти к серверу 1, и все остальные запросы переходят на сервер 2. В этом случае мы также можем сказать Nginx Чтобы направить запросы на основе его пути.

worker_processes  1;

error_log  /usr/local/var/log/nginx/error.log;

events {
    worker_connections  10;
}

http {
    access_log  /usr/local/var/log/nginx/access.log;

    upstream auth_services {
        server 0.0.0.0:50051;
        server 0.0.0.0:50052;
    }

    upstream laptop_services {
        server 0.0.0.0:50051;
        server 0.0.0.0:50052;
    }

    server {
        listen       8080 ssl http2;

        # Mutual TLS between gRPC client and nginx
        ssl_certificate cert/server-cert.pem;
        ssl_certificate_key cert/server-key.pem;

        ssl_client_certificate cert/ca-cert.pem;
        ssl_verify_client on;

        location /techschool.pcbook.AuthService {
            grpc_pass grpcs://auth_services;

            # Mutual TLS between nginx and gRPC server
            grpc_ssl_certificate cert/server-cert.pem;
            grpc_ssl_certificate_key cert/server-key.pem;
        }

        location /techschool.pcbook.LaptopService {
            grpc_pass grpcs://laptop_services;

            # Mutual TLS between nginx and gRPC server
            grpc_ssl_certificate cert/server-cert.pem;
            grpc_ssl_certificate_key cert/server-key.pem;
        }
    }
}

Здесь я просто копирую путь /techschool.pcbook. AuthService из Authсервис и вставьте его в это место. Затем я измению это восходящее имя в auth_services. . Это должно только подключиться к Server1 в порту 50051 Отказ

Затем я добавляю еще один вверх по течению для laptop_services и заставить его подключиться только к Server2 в порту 50052 Отказ Затем дублируйте блок местоположения, измените имя восходящего расстояния в laptop_services и обновите путь к techschool.pcbook. НоутВервис Отказ

Хорошо, давайте попробуем это! Нам просто нужно перезапустить Nginx и бежать сделать клиент-TLS Отказ

Теперь мы можем увидеть только запрос входа в систему для Server1 Отказ

И все остальные запросы на ноутбук переходят на server2. . Даже если мы запустим это, сделайте клиент-TLS несколько раз.

Так что это работает! И это обвиняет нашу лекцию о балансировке нагрузки GRPC с Nginx Отказ

Я собираюсь нажать этот файл конфигурации nginx на Репозиторий PCBook-Go Так что вы можете скачать и играть с ним, если хотите.

Большое спасибо для чтения и после курса. Счастливое кодирование и увидимся в следующем!

Если вам нравится статью, пожалуйста, Подписаться на наш канал YouTube и Следуйте за нами в Twitter Для получения дополнительных учебников в будущем.

Если вы хотите присоединиться ко мне в моей нынешней удивительной команде в Voodoo, проверьте Наши рабочие открытия здесь . Удаленный или на месте в Париже/Амстердам/Лондон/Берлин/Барселона с визовой спонсорство.

Полный курс GRPC (16 частей серии)

Оригинал: «https://dev.to/techschoolguru/load-balancing-grpc-service-with-nginx-3fio»