Консул: архитектура SD. Каков правильный способ доступа к микросервисам с лицевой стороны?

Question

У меня есть несколько внутренних микросервисов, которыми управляет консул, и для получения некоторых данных из одной службы для другой, я использую функцию обнаружения сервисов консула - например, получить все полезные серверы, а затем получить адрес и порт сервера из извлеченного запись и т. д. Но как мне это сделать с лицевой стороны? Просто вызовите необходимый микросервер, используя его фактический ip или позвоните ему, используя пространство имен контейнера докера. Будет очень полезно получить ответ от кого-то, кто знает, как это сделать или даже лучше, кто это сделал раньше, потому что я немного застрял с ним.

Answer 1

В ходе расследования, я обнаружил, что существует несколько подходов:

1. стороне клиента Service Discovery - Предположим, у вас есть консулом и он знает все о доступных серверах и их статусов, у клиента вы должны написать сервисный уровень, который может вызывать API консула, извлекать полезные серверы и затем делать еще один HTTP-запрос на нужный сервер. (Конечно, это может быть немного умнее и имеет возможность, например, кеш здоровых серверов и т. Д.).

2. стороне сервера Service Discovery (балансировки нагрузки) - дополнительный слой над консулом - это может быть HAProxy или Nginx, и она будет пересылать запросы на необходимого сервера. (С лицевой стороны вы можете использовать имена консулов ​​ или имена доменов docker container dns).

3. Серверный Service Discovery (API шлюза) - и последний один, вы можете написать еще один microservice, который будет обрабатывать все запросы и прокси их на необходимые серверы после проверки их состояния в консулом.

Но теперь есть еще один вопрос - какой подход следует использовать? - Я думаю, что это очень зависит от сложности проекта, загрузки сервера и количества микросервисов.

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

Answer 2

Под «frontend» вы имеете в виду Javascript, работающий в веб-браузере или программном обеспечении, которое вы используете в одном и том же центре данных? Я предполагаю, что здесь речь не идет о сценарии веб-браузера.

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

2-й вариант является очень стандартным и хорошо понятным, а Nginx и Haproxy предназначены для этой рабочей нагрузки. Обратите внимание, что у вас должно быть несколько из них, чтобы не иметь ни одной точки отказа, а обновление их двоичных файлов (особенно, если вы запускаете их на Docker) приведет к кратковременному простоям. Клиенты должны каким-то образом обнаружить эти балансировки нагрузки, DNS является наиболее распространенным вариантом. DNS работает хорошо, когда ситуация довольно статична, и все работает на портах по умолчанию, поэтому вам не нужно слишком много работать с TTL и SRV-записями.

3-й вариант упрощает клиентскую логику, поскольку API-шлюз может выступать в качестве «представления» к услугам, которые вы получили внутри страны.Но вам все еще нужно найти сервис для клиентов, чтобы найти их, чтобы они не решали первоначальную проблему.

Любая обратная связь приветствуется, это очень широкая тема, и ваш пробег может отличаться.

Обновление: Также, если вы используете протокол HTTP, вы можете защитить его HTTPS. С балансировщиком нагрузки у вас есть возможность завершить HTTPS там и иметь более простой нешифрованный трафик в вашем VPC или что-то еще за брандмауэром.