Консул: SD архитектура. Как правильно получить доступ к микросервисам с внешней стороны?
У меня есть несколько внутренних микросервисов, управляемых консулом, и чтобы получить некоторые данные из одного сервиса для другого, я использую функцию обнаружения сервисов консула - например, получить все исправные серверы, затем получить адрес и порт сервера из найденной записи и т. Д. Но как мне это сделать с внешней стороны? Просто позвоните нужному микросерверу, используя его фактический ip, или вызовите его, используя пространство имен контейнера docker? Будет очень полезно получить ответ от кого-то, кто знает, как это сделать или даже лучше, кто делал это раньше, потому что я немного придерживался этого.
2 ответа
Под "внешним интерфейсом" вы подразумеваете Javascript, работающий в веб-браузере, или часть программного обеспечения, которую вы используете в том же центре обработки данных? Я предполагаю, что мы не говорим о сценарии веб-браузера здесь.
Я считаю, что обнаружение на стороне клиента с интеллектуальным кэшированием и циклической балансировкой нагрузки лучше всего масштабируется, поскольку нет единой точки отказа и она очень быстро реагирует на любые сбои в кластере. Но это продвигает больше логики на сторону клиента и делает ведение журнала более сложным, чем простой журнал доступа Nginx.
Второй вариант очень стандартный и хорошо понятный, и Nginx и Haproxy были разработаны для этой рабочей нагрузки. Обратите внимание, что у вас должно быть несколько из них, чтобы не иметь единой точки отказа, и обновление их двоичных файлов (особенно если вы запускаете их в Docker) приведет к короткому периоду простоя. В любом случае клиенты должны как-то обнаружить эти балансировщики нагрузки, DNS является наиболее распространенным вариантом. DNS работает хорошо, когда ситуация довольно статична и все работает на портах по умолчанию, поэтому вам не нужно слишком много возиться с TTL и записями SRV.
Третий вариант упрощает клиентскую логику, поскольку шлюз API может выступать в качестве "представления" к службам, которые у вас есть внутри. Но клиентам по-прежнему нужно обнаруживать службы, чтобы найти их, чтобы они действительно не решили исходную проблему.
Любые отзывы приветствуются, это очень широкая тема, и ваш пробег может варьироваться.
Обновление: также, если вы используете протокол HTTP, вы можете захотеть защитить его с помощью HTTPS. С помощью балансировщика нагрузки у вас есть возможность завершить HTTPS и получить более простой незашифрованный трафик внутри вашего VPC или любого другого устройства за брандмауэром.
В ходе расследования я обнаружил, что существует несколько подходов:
Обнаружение службы на стороне клиента - предположим, что у вас есть консул, и он знает все о доступных серверах и их статусах, на клиенте вы должны написать сервисный уровень, который может вызвать API консула, получить работоспособные серверы, а затем сделать еще один http-запрос к нужному. сервер. (Конечно, это может быть немного умнее и имеет возможность, например, кешировать работоспособные серверы и т. Д.).
Обнаружение службы на стороне сервера (балансировщик нагрузки) - дополнительный уровень над консулом - это может быть haproxy или nginx, и оно будет пересылать запросы на нужный сервер. (Со стороны внешнего интерфейса вы можете использовать имена DNS-консула или DNS-адреса Docker-контейнера).
Обнаружение службы на стороне сервера (API Gateway) - и последнее, вы можете написать еще один микросервис, который будет обрабатывать все запросы и передавать их на необходимые серверы после проверки их статусов в консуле.
Но теперь возникает еще один вопрос - какой подход использовать? - Я думаю, что это очень зависит от сложности проекта, загрузки сервера и количества микросервисов.
ИМХО, если у вас есть несколько микросервисов и низкая нагрузка на сервер, вы можете использовать любой из них, но в любых других случаях я думаю, что лучше выбрать 2-й подход.