Всем привет!
Я работаю бэкенд-разработчиком в компании Tinkoff, где участвую в разработке платформы CRM-системы для обслуживания физических и юридических лиц.
Использование edge proxy и балансировщика в частности — это почти мастхэв при построении современных систем. Сегодня на рынке представлено большое количество разнообразных решений, у каждого из которых есть преимущества и недостатки. Мы остановимся на одном из самых свежих — Envoy.
Envoy — это высокопроизводительный балансировщик, реализованный на C++. Его разработала компания Lyft — сервис заказа такси в Штатах, прямой конкурент Uber — для использования как с отдельными сервисами, так и в качестве связующего звена в сложных микросервисных системах. В том числе для реализации относительно свежего архитектурного явления — service mesh.
Формируя основной фундамент нашей платформы, он реализует cors, access-control, rate limiting, outlier detection, проверку jwt и многое другое.
На Хабре есть отличная статья, которая разбирает его основные отличия от ближайших соседей и проливает свет на внутреннее устройство. Мы же сфокусируемся больше на прикладных моментах, разберемся с запуском и настройкой, попробуем сразу несколько видов балансировки трафика. Поехали!
Для начала нам понадобится upstream-сервис-заглушка, обрабатывающий http-запросы и позволяющий в ответе идентифицировать каждый свой инстанс. Вы можете реализовать этот функционал сами либо, как и я, использовать доступный echo-server на Go. Удобнее всего развернуть несколько инстансов сразу в docker, назначив каждому свой порт. Я поднял три инстанса: на 8081, 8082, 8083 портах, запрос на каждый из которых в том числе возвращает container id.
Например, запрос:
curl -v localhost:8081Возвращает:
Request served by a29f0fba3451
HTTP/1.1 GET /
Host: localhost:8081
User-Agent: curl/7.64.1
Accept: */*Где a29f0fba3451 — идентификатор контейнера.
Теперь перейдем непосредственно к настройке Envoy. Он распространяется так же, как docker — образ с уже готовым примером конфигурации.
admin:
access_log_path: /tmp/admin_access.log
address:
socket_address: { address: 127.0.0.1, port_value: 9901 }
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 10000 }
filter_chains:
- filters:
- name: envoy.http_connection_manager
config:
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { host_rewrite: www.google.com, cluster: service_google }
http_filters:
- name: envoy.router
clusters:
- name: service_google
connect_timeout: 0.25s
type: LOGICAL_DNS
# Comment out the following line to test on v6 networks
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
hosts: [{ socket_address: { address: google.com, port_value: 443 }}]
tls_context: { sni: www.google.com }Здесь несколько основных моментов:
- Порт, на котором запускается listener.
- Virtual host по имени домена.
- Конфигурация фильтров. Главная точка расширения для нас — настройка routes, обработка входных и выходных запросов.
- Cluster — логически объединенные upstream-инстансы с параметрами балансировщика.
- Endpoint — непосредственно upstream-инстанс с адресом и метаданными.
Я выделил основные сущности, настраиваемые с помощью сервисов LDS, VHDS, RDS, CDS и EDS соответственно.
Стоит добавить, что кроме статической конфигурации из yaml-файла существует и динамическая. В этом случае нам необходимо реализовать control-plane-сервис и API для передачи конфигурации envoy по gRPС-протоколу. В репозитории Envoy есть уже готовые реализации на Go и Java. Динамический подход будет крайне полезен в случае сложной конфигурации вашей системы и необходимости реагировать на ее изменения в рантайме.
Вернемся к конфигу и адаптируем под наши нужды.
Для начала добавим новый кластер echo_cluster и настроим список действующих эндпоинтов (апстрим-сервисов), заполнив поле load_assignment.endpoints адресами наших инстансов echo-server.
clusters:
- name: echo_cluster
connect_timeout: 3s
type: STRICT_DNS
dns_lookup_family: V4_ONLY
load_assignment:
cluster_name: echo_cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8081
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8082
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8083Осталось настроить только матчинг входящих запросов. Для этого в фильтре envoy.http_connection_manager необходимо задекларировать роуты наших апстрим-сервисов. Согласно официальной документации, есть несколько способов сделать это. Например, можно отправлять все запросы с префиксом "/echo" на соответствующий кластер.
- filters:
- name: envoy.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
stat_prefix: echo
codec_type: AUTO
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match: { prefix: "/echo" }
route: { cluster: echo_cluster }
http_filters:
- name: envoy.routerТеперь положим dockerfile:
FROM envoyproxy/envoy:v1.13.0
COPY envoy.yaml /etc/envoy/envoy.yamlрядом с этим конфигом, соберем и запустим:
docker build -t envoy:v1 .
docker run -p 8080:8080 --rm envoy:v1И это всё! Теперь все http-запросы на балансировщик с префиксом "/echo" Envoy будет распределять между тремя инстансами echo-server.
curl localhost:8080/echoRequest served by a29f0fba3451
HTTP/1.1 GET /echo
Host: localhost:8080
User-Agent: curl/7.64.1
Accept: */*
X-Forwarded-Proto: http
X-Request-Id: dd4b850c-9b4e-45e5-a411-4b76293b1e33
X-Envoy-Expected-Rq-Timeout-Ms: 15000
Content-Length: 0Все остальные запросы будут возвращать 404.
В качестве алгоритма балансировки по умолчанию используется round robin (перебор по круговому циклу), который закрывает потребности большинства современных систем.
Я написал небольшой скрипт для проверки распределения запросов между апстрим-нодами. Ссылка на исходники с примерами будет в заключении.
Однако Envoy поддерживает и другие виды балансировки трафика, используя которые можно решать множество самых разнообразных задач. Следующие примеры актуальны прежде всего для stateful-систем и других случаев, когда нужно балансировать запрос на конкретный апстрим-инстанс.
Балансировка на основе consistent hashing
Например, мы хотим получать данные пользователя по его идентификатору.
На такой запрос каждый сервис ходит в одну или несколько других систем или СУБД и агрегирует всю необходимую информацию. Это тяжелый вызов, и для того, чтобы не выполнять его каждый раз, можно добавить кэш в каждый из сервисов. Теперь нам остается распределить все такие вызовы между существующими инстансами, чтобы не дублировать кэши и гарантировать попадание одних и тех же пользователей на одни и те же ноды.
clusters:
- name: echo_cluster
lb_policy: RING_HASHВыберем, что использовать в качестве ключа балансировки. Envoy предлагает сразу несколько вариантов. Например, можно поместить идентификатор в хедер запроса.
- match: { prefix: "/echo" }
route: {
cluster: echo_cluster,
hash_policy: {
header: {
header_name: id_key
}
}
}Но что, если нам неудобно передавать ключ балансировки в хедере и мы хотим использовать переменную самого урла. Одна из возможных точек расширения функционала Envoy — использование http фильтров.
Есть неплохая документация по представленным фильтрам и их настройке. С их помощью, например, мы можем реализовать cors, внешнюю авторизацию, проверку jwt-токенов и многое другое. Нам же понадобится фильтр envoy.lua. С его помощью можно встраиваться в обработку как запроса, так и ответа, расширять ее с помощью скрипта на языке Lua.
Просто распарсим путь запроса с помощью регулярного выражения и вручную добавим хедер 'id_key'.
- name: envoy.lua
typed_config:
"@type": type.googleapis.com/envoy.config.filter.http.lua.v2.Lua
inline_code: |
function envoy_on_request(request)
hasIdKey = "/echo/key/(.+)/?.*"
path = request:headers():get(":path")
key = path:match(hasIdKey)
if key ~= nil then
request:headers():add("id_key", key)
end
endТеперь запросы с одним и тем же ключом в урле будут попадать на одну и ту же ноду echo-server:
Стоит учитывать, что при использовании алгоритма RING_HASH могут возникать мисы. Это накладывает ряд ограничений на его применение.
Subset-балансировка
Иногда нам нужно разделять апстрим-инстансы внутри одного кластера. Например, мы хотим выстроить такое флоу, при котором не имеет значения, куда попадет самый первый запрос от клиента, а каждый последующий должен балансировать на тот инстанс, где обслуживался первоначальный.
Envoy представляет готовый механизм для этого, мы можем разделить исходный кластер на основе метаинформации самих инстансов.
- name: echo_cluster
lb_policy: ROUND_ROBIN
lb_subset_config:
fallback_policy: ANY_ENDPOINT
subset_selectors:
- keys:
- instance_idendpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8081
metadata:
filter_metadata: { "envoy.lb" : { "instance_id": "a29f0fba3451"}}
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8082
metadata:
filter_metadata: { "envoy.lb" : { "instance_id": "d6325ed590c0"}}
- endpoint:
address:
socket_address:
address: docker.for.mac.localhost
port_value: 8083
metadata:
filter_metadata: { "envoy.lb" : { "instance_id": "6e2f60a09101"}}Чтобы Envoy матчил переданный в запросе instance_id с конкретным апстримом, нам необходимо заполнять динамическую метадату каждого запроса.
Воспользуемся еще одним http-фильтром envoy.filters.http.header_to_metadata, который будет заполнять необходимую мету при наличии хедера instance-id.
При этом, если мы все-таки хотим передавать это значение в пути запроса, нам придется повторить трюк из предыдущего пункта.
- name: envoy.lua
typed_config:
"@type": type.googleapis.com/envoy.config.filter.http.lua.v2.Lua
inline_code: |
function envoy_on_request(request)
hasInstanceId = "/echo/instance/(.+)/?.*"
path = request:headers():get(":path")
key = path:match(hasInstanceId)
if key ~= nil then
request:headers():add("instance-id", key)
end
endТеперь, выполнив любой запрос, мы получим instance-id (container id), передав который во все следующие вызовы, будем гарантированно попадать на необходимую ноду.
Вместо вывода
Приведенные примеры и полученные результаты, несмотря на простоту реализации, едва ли будут аргументом в пользу Envoy на вашем проде.
За год использования мы в Тинькофф встретили ряд ограничений и неприятных багов. С чем-то мы научились жить самостоятельно, а с чем-то помогли оперативные фиксы. Так или иначе широчайший функционал, высокое качество документации и большое развивающееся комьюнити делает этот продукт очень интересным как минимум для ознакомления.
Ну а в следующий раз мы поговорим о балансировке с весами и зеркалировании трафика.