通过开发DNS负载均衡+nginx实现SpringCloud Gateway 服务本身的动态扩容是否可行?
已解决
SpringCloud Gateway服务动态扩容解决方案
发布于 2021-06-18 14:18 747浏览
SpringCloud Gateway 服务本身无法做到动态伸缩,如果再开发一层dns负载均衡服务,通过nginx先访问dns服务获取到网关的真实ip然后再访问网关。 dns服务实现类似注册中心的功能,网关服务启动后先注册到dns服务。dns服务维护网关服务心跳健康。然后给nginx提供网关真实ip。该方案是否可行? 或者现在是否有更好的网关动态扩容解决方案?  
SpringCloud Gateway 服务本身无法做到动态伸缩,如果再开发一层dns负载均衡服务,通过nginx先访问dns服务获取到网关的真实ip然后再访问网关。 dns服务实现类似注册中心的功能,网关服务启动后先注册到dns服务。dns服务维护网关服务心跳健康。然后给nginx提供网关真实ip。该方案是否可行? 或者现在是否有更好的网关动态扩容解决方案?
SpringCloud Gateway 服务本身无法做到动态伸缩,如果再开发一层dns负载均衡服务,通过nginx先访问dns服务获取到网关的真实ip然后再访问网关。 dns服务实现类似注册中心的功能,网关服务启动后先注册到dns服务。dns服务维护网关服务心跳健康。然后给nginx提供网关真实ip。该方案是否可行? 或者现在是否有更好的网关动态扩容解决方案?
编写答案
回答问题, 请先登录
你好:
个人觉得你这个方案很奇怪,你根据网关去做动态扩缩容这个就不太合理,扩缩容的标准上限下限等等资源参数你在哪里设置?再一个springcloud生态就是每个组件维护各自的功能,网关就是网关,配置中心就是配置中心,你通过ng请求网关然后用配置中心的地址在返回网关给ng去下法,这程序还没开发访问都浪费了太多资源,出现问题不好排查,而且你还要对ng做二次开发,完全没有必要,有这时间你还不如直接部署到容器了通过k8s的helm进行资源文件配置,根据自身业务指标来进行扩缩容,这样才是最合理的
你好:
个人觉得你这个方案很奇怪,你根据网关去做动态扩缩容这个就不太合理,扩缩容的标准上限下限等等资源参数你在哪里设置?再一个springcloud生态就是每个组件维护各自的功能,网关就是网关,配置中心就是配置中心,你通过ng请求网关然后用配置中心的地址在返回网关给ng去下法,这程序还没开发访问都浪费了太多资源,出现问题不好排查,而且你还要对ng做二次开发,完全没有必要,有这时间你还不如直接部署到容器了通过k8s的helm进行资源文件配置,根据自身业务指标来进行扩缩容,这样才是最合理的