yang

准备做之前仔细看了下，有几个问题想要确认下。 1. -F 影响的 Router 里的 Chainer 好像才是转发的关键。通过这个 Chainer 构建出的 net.Conn。相关接口: https://github.com/go-gost/core/blob/50d443049f3bb083c949c2fc2821d2bc037340d4/chain/chain.go#L10 3. -L=tcp://:8080/192.168.1.1:80 这种方式是通过上面构建出来的左右一层的 connector去 connet 真正的目标然后数据透传数据。 4. 如果上面是正确的那么我们有两种方案: 每次都会经过 chainer.Route() 构造的一个全新的 router 来做 Dial() 到真正的落地目标。 [ route =...

gost 作为转发为核心的项目用 Router 做为核心好像确实更符合抽象。 Forwarder 的功能也确实挺像是 Hop 的子集。 这样重构之后，就不会我之前的问题。是在 Forwarder 扩展，还是在Router 中做更改。 至于数据源相关的配置。我先把最新代理拉下来，学习一下。 另外两个问题: 1. 有大约的计划啥时候发布吗。 2. 有进展或者想法可以在这个 issue 同步下。让我慢慢了解一些设计思路。比死看代码方便多了。[呲牙]

是的。通过动态配置的方式应该是可以满足当前的场景。

你好在实践动态配置的过程中的一些思考。 ### 方案1：动态配置: 我觉得通过动态配置的方式思路上感觉也蛮像 service mesh 的数据层。但遇到了一个问题。如果有多个 gost 节点，是需要一个注册中心的组件。每个gost 启动的时候去注册。配置更新之后，才能够知道需要通知到哪 gost 在什么位置。这种方式的缺点就是另外的程序实现发现和通知机制。 ### 方案2: 实现 chain.Hop 接口的RedisHop 为了避免上面增加注册中心的负担。增加 RedisHop方式实现了 chain.Hop 接口。Select() 时候调用自己的 Nodes()方法实现从 redis 里取当前可用的 node 信息返回。这种方式缺点是只能实现指定为 RedisHop 的 hop...

方案4，感觉应该主要是扩展。各个需要热更新模块增加一个 listener 来获取最新的配置。至于观察者纯新增代码了，不会影响到原逻辑。前期完全可以兼容当前 api 热更新和配置文件热更。而且很多代码可以参考 traefix 的实现。 如果你觉得方案4可以最终 merage 到主分支。我这边可以来做实现。

同问