Каковы недостатки использования службы балансировки нагрузки в качестве точки входа в приложение микрослужбы? [закрыто]
В простой микросервисной архитектуре у меня есть несколько сервисов, которые должны находиться за шлюзом API.
Шлюз предоставит единую конечную точку, а также централизованную аутентификацию и авторизацию с использованием сервера идентификации (одного из микросервисов в кластере).
Поскольку NGIX или HAProxy совершенно чужие, я исследовал решения этой проблемы на С# и наткнулся на два основных варианта в этой области, предлагающих множество настроек на С#:
Оба выглядят великолепно, но имеют сложную настройку при развертывании в среде Kubernetes.
В случае YARP требуется развернуть контроллер увеличения, как описано в следующем руководстве: https://github.com/microsoft/reverse-proxy/blob/main/docs/docfx/articles/kubernetes-ingress.md .
При чтении этого примера кажется, что контроллер входа YARP использует форматированные правила kubernetes, определенные в ingress.yaml, для направления трафика на внутренние службы, созданные как IP-адреса кластера.
Это подводит меня к моему вопросу: каковы недостатки использования службы балансировки нагрузки в качестве точки входа в приложение микросервиса, учитывая, что модуль, доступный через балансировщик нагрузки, может по мере необходимости перенаправлять трафик на внутренние службы, определенные с помощью службы Cluster IP?