linking12
linking12
gateway重写 1：目前是想把oauth2的授权和资源拆分开，目前是耦合在一起的 2：把整个admin的控制台迁移到授权上，而资源只负责转发 3：想办法把zuul替换掉，或者重写zuul的转发
也不会麻烦，目前zuul使用的是servlet来转发请求； 可以自己写http接收的网络请求，手动转发到这个servlet上，这样的做法就是把web容器的http转发给替换掉了
accessToken没获取吧？
请把你的场景说一下
@luzhu123 saluki.grpc.registryAddress 是你的consul地址，grpc服务的注册中心
eureka是针对rest的api进行转发，因为zuul原生是支持rest请求的，所以只要接入spring cloud的注册中心，zuul就能支持rest api的转发； 目前saluki的注册中心是consul，所以为了支持rest和grpc两种不同的方式，接了两个注册中心
@jprante Can this issue have fixed in latest version? when i pull the master branch and run it in my local, the thread can not be finalize,and the number of...
@jprante I think I have found the reason of this issue. the JDBCImporter is a latest Object when program schedule. this will cause the executorService is latest too. may be...
> 1. 目前不支持后端upstream的H3协议，如果有广泛的业务场景需求，可以考虑排期支持。 > 在长连接业务中是有收益的，大量的客户端h3长连接到tengine，tengine到后端维持h3长连接。 > 2. angie这个queue相当于加了一层buffer，但队列满时，依旧是502，这个功能的意义不是很大。可以适当调整$upstream_read_time后端超时时间，并且保证客户端调用侧的超时时长大于后端upstream的超时时长。 @lianglli 多谢回复，关于2的话，我有一个场景困扰很久； 对于nginx来说反向代理走http1.1协议，在突增流量的情况下，如果backend的接口响应变慢了，nginx会大量开启新的TCP连接到backend，这个并不是预期的，所以走h2/h3的连接复用或者通过queue缓存一部分request应该是比较好的选择，或者面对突增流量，下游接口变慢有更好的解决方案吗？
玩过 https://github.com/linking12/pinpoint 就是fork出官方的pinpoint为支持jdk1.8修改的 支持https://github.com/linking12/saluki 这个服务化框架的