有什么轻量级的微服务网关可以替换掉 springcloudgateway？

traefik

traefik+1

nacos 也可以考虑换成轻量级 r-nacos (用 rust 重写的 nacos ，协议完成兼容)，这样就可以和 apisix 配套使用。

traefik 确实轻量，容器下动态配置也方便

Apinto
还没试过

apisix

apisix 配合 nacos

apisix + 1 ，当然如果觉得 low 可以用 kong ，我个人倒是觉得 apisix 还行

apisix

上了 k8s ，nacos 都可以省了。

为什么你们还在用网关, 网关这种东西, 自 k8s 诞生的那一天起就被淘汰了.

apisix 不推荐
/t/1033395

nacos 目前发现有个 rust 重写的 rnacos 可以替换，但生产环境没试过。
同样起了八个服务，资源消耗差不多是十几二十倍的差距：
nacos：698.6MB
rnacos：29.2MB

@bthulu 没网关跨 vpc 怎么调用? 金丝雀发布怎么精确控制流量到 pod? 失败逻辑怎么精确到接口?

@BQsummer
Q:没网关跨 vpc 怎么调用?
A:先在路由策略上实现 service 网段跨 VPC 访问，然后通过 k8s 的 RBAC 精确控制各个项目之间访问权限即可。

Q:金丝雀发布怎么精确控制流量到 pod
A: 个人只用过基于 Nginx 的 ingress ，但即使是这种传统的 ingress 也支持特定规则 header 流量，特定规则 cookie 流量，或者按照比例的控制流量到多个 service 。 此外 APISIX Ingress 、Kong Ingress 与 Istio 都支持金丝雀发布，个人没在生产环境里用过。 至于精确到 pod ，service 可以包含多个 pod 也可以只包含一个 pod ，这非常简单。

Q:失败逻辑怎么精确到接口?
A: 分析 Ingress 层的 log 就行了，比如用 Nginx-ingress 的话就找个能分析 nginx 日志的系统监听 Nginx-ingress 的日志。

个人非常同意 @pming1 的看法。
nacos 的配置中心功能完全能用 k8s 的 configmap 、secret 甚至 workload 的环境变量替代。
nacos 的注册服务则是完全能被 k8s 的 service 替代。
至于很多人喜欢的 java 网关，ingress 要强大得多。

在 k8s 里搭建 nacos 的行为，纯粹是在浪费性能套娃。

@pckillers k8s 就不需要网关了吗，你考虑过多集群吗？

@pckillers
k8s 的 configmap 很难完全替代配置中心。

部分场景有依赖配置中心的运行时动态变更配置能力，k8s 通过重启方式重新加载配置是不太能接受的。

比如我们新写一个新的处理流程，支持出问题时通过配置控制是回切到老逻辑。
如果通过配置中心，可以在 1 秒内把几十个实例秒级回退到老逻辑。
如果走 k8s 的分批重启加载新配置，回切时长达不到这效果。

类似的场景还有临时动态调整处理线程池数量等。

https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/jwt.html

// Spring Security OAuth 2.0 Resource Server JWT
implementation 'org.springframework.security:spring-security-oauth2-jose'
implementation 'org.springframework.security:spring-security-oauth2-resource-server'

维护一个 jwks 获取地址就行啦，网关都不需要

@heqingpan
configmap 通过文件夹形式挂载不设置 subpath ，就能自动更新配置文件。不过确实达不到秒级。

通过改配置文件就能改逻辑。这功能高级，我遇到的 springboot 项目逻辑都是写死在 jar 里的😂

至于动态调整处理线程池数量，k8s 规范上 pod 都是要加性能限制的，我寻思针对单 POD 调好最佳性能的参数后，改这些参数但不提升 CPU 与内存并不能真正应对大量负载吧？ 除非一开始的参数就设置为无法发挥出硬件能力的偏低参数，但这样又是纯粹的浪费资源。目前我这里的 k8s 服务就是单纯的测好单 pod 的最佳性能参数后，再根据流量、CPU 、内存指标自动扩充 POD 数量。