cloudwego
feat: 能否通过解析config从而得到 server 或 client 的 `[]Option`
Is your feature request related to a problem? Please describe.
type: feature
设置server或client的配置时，一个配置选项需要使用一个 With...() 方法，
能否有一种方法能够通过配置文件，动态的得到多个 Option，即 []Option
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
感谢反馈！ 你指的是框架支持从配置文件读取option，然后设置/更新吗？配置文件来定义option的方式确实可以提升易用性，我们记一个todo之后看看如何设计。 不过 client/server 级别的 option 其实是在初始化的时候传入的，动态更新的场景可能不太适用。
感谢反馈！ 你指的是框架支持从配置文件读取option，然后设置/更新吗？配置文件来定义option的方式确实可以提升易用性，我们记一个todo之后看看如何设计。 不过 client/server 级别的 option 其实是在初始化的时候传入的，动态更新的场景可能不太适用。
动态更新理解错了😂，我意思是初始化之前的配置的动态更新，这个动态更新是指通过配置文件中的字段删减，从而提供的 []Option 也不同，
比如 原来的配置文件里有 RpcTimeout 这个字段，那么会提供 client.WithRpcTimeout 这个Option，如果没有就不会提供这个Option
ok 理解了
感谢反馈！ 你指的是框架支持从配置文件读取option，然后设置/更新吗？配置文件来定义option的方式确实可以提升易用性，我们记一个todo之后看看如何设计。 不过 client/server 级别的 option 其实是在初始化的时候传入的，动态更新的场景可能不太适用。
动态更新理解错了😂，我意思是初始化之前的配置的动态更新，这个动态更新是指通过配置文件中的字段删减，从而提供的
[]Option也不同， 比如 原来的配置文件里有 RpcTimeout 这个字段，那么会提供client.WithRpcTimeout这个Option，如果没有就不会提供这个Option
ok 理解了
感谢反馈！ 你指的是框架支持从配置文件读取option，然后设置/更新吗？配置文件来定义option的方式确实可以提升易用性，我们记一个todo之后看看如何设计。 不过 client/server 级别的 option 其实是在初始化的时候传入的，动态更新的场景可能不太适用。
动态更新理解错了😂，我意思是初始化之前的配置的动态更新，这个动态更新是指通过配置文件中的字段删减，从而提供的
[]Option也不同， 比如 原来的配置文件里有 RpcTimeout 这个字段，那么会提供client.WithRpcTimeout这个Option，如果没有就不会提供这个Option
这个feature是否可以通过，如果可以的话我提个pr
这个问题本质上是一个配置文件的解析器，当前option的种类很多，且类型差别很大，比如withMiddleware, withResolver。很难实现一个通用的，可扩展的解析方案。建议针对自己的项目去写一个简单的配置解析器。 如果是类似rpctimeout这种配置，之后我们会开源一个配置中心的接口，可以进行扩展。
这个问题本质上是一个配置文件的解析器，当前option的种类很多，且类型差别很大，比如withMiddleware, withResolver。很难实现一个通用的，可扩展的解析方案。建议针对自己的项目去写一个简单的配置解析器。 如果是类似rpctimeout这种配置，之后我们会开源一个配置中心的接口，可以进行扩展。
目前的痛点就是如果项目当中多个rpc服务（服务端，客户端）的设置都不一样，需要写很多 WithOption 这类的代码，导致出现代码冗余，期待配置中心🥰
之后计划开源的是一个 config manager 库，不是完整的「配置中心」（Config Center + Provider + Translator）。
考虑到每个使用者的配置情况差别可能很大，建议自己实现对应的 provider 和 translator。
可参考：https://www.cloudwego.io/zh/docs/kitex/tutorials/framework-exten/suite/ ，在 Options 方法中调用 provider 获得配置信息，再调用 Translator 将其转换成 []Option.
#973 我们在开发一些于开源配置中心集成的模块（已发布 config-nacos），用于支持服务治理配置，是否能满足你的需求？
部分满足
看到配置选项只满足 service governance 相关，
希望能够支持最重要的 service discovery 相关配置，
比如 client 的 WithResolver(r discovery.Resolver) Option, WithTag(key, val string) Option, WithHostPorts(hostports ...string) Option 等选项
了解。
你需要的这些能力，主要是配置项比较特殊，尤其是 Resolver，我们没法发布一个能解析出你自己开发的 Resolver 的模块。
以文件配置为例，比如文件中是
resolver=xxx
假如由 Kitex 发布一个文件配置加载模块，模块内是无法识别 "xxx" 应该对应具体哪个 resolver，还需要注入一个 ResolverFactory （例如实现 NewResolver(resolveName string) Resolver 方法）才行
了解。
你需要的这些能力，主要是配置项比较特殊，尤其是 Resolver，我们没法发布一个能解析出你自己开发的 Resolver 的模块。
以文件配置为例，比如文件中是
resolver=xxx假如由 Kitex 发布一个文件配置加载模块，模块内是无法识别 "xxx" 应该对应具体哪个 resolver，还需要注入一个 ResolverFactory （例如实现
NewResolver(resolveName string) Resolver方法）才行
开发者自行实现的 discovery.Resolver 肯定实现不出来，
但是可以实现社区已经开发好的 Resolver，如 github.com/kitex-contrib/registry-xxx/xxx_resolver.go
由用户指定社区实现开的配置文件中心类型，模块再根据指定类型解析到具体的 resolver
了解，
所以你期望的是一个 ClientSuite ，入参是一组配置（可以从任意配置源读取），转换成对应的 []client.Option。
配置应当支持：
- Resolver（registry-etcd, registry-nacos 等 kitex-contrib 已经支持的模块，以及直接指定 IP端口等）
- Tag
- ...
这个我们先记录下来
了解，
所以你期望的是一个 ClientSuite ，入参是一组配置（可以从任意配置源读取），转换成对应的
[]client.Option。配置应当支持：
- Resolver（registry-etcd, registry-nacos 等 kitex-contrib 已经支持的模块，以及直接指定 IP端口等）
- Tag
- ...
这个我们先记录下来
对的，感谢跟进