unionhu

> > ## 1.如果使用layotto，是不是指定的layotto的一个版本即可 > > 是的。 Layotto和mosn是一个进程，可以理解成 layotto=mosn+一个特殊的grpcfilter 打包到一起, 升级 layotto == 升级mosn layotto和mosn 的版本是一一对应的关系，之前发布的v0.3.0的layotto对应的mosn版本为 v0.24.1 所以：如果使用了 layotto，sidecar镜像里指定layotto的一个版本即可，不用另外再指定 mosn 版本 > > ## layotto和mosn的版本的升级怎么搞？ > > 用k8s部署、升级，升级sidecar镜像里的 layotto版本即可 >...

> Cool. 个人一直期望在layotto runtime 层支持 流量治理规则、支持规则动态下发（像 envoy 那样），这样能帮助所有组件都获得强大的流量治理能力。 > > 不过您的描述比较简单，我有一些疑问，比如： > > * 是希望下发 key-value 结构的“配置”，还是类似于 xds 那样、有一定结构的“规则”呢？ > * redis 的组件现在有一些failover之类的配置，这些配置项能否满足您的需求，见 https://docs.dapr.io/reference/components-reference/supported-state-stores/setup-redis/ > * 启动配置文件里，现在有一些key/value配置项（见下图），layotto 会用这些配置项去初始化组件。如果加入动态规则下发后，您希望layotto 启动后，用哪里的配置做初始化，是启动后立刻读控制面的配置、用控制面的配置覆盖掉配置文件里的配置、然后再初始化么？ >...

> @unionhu 看下这样能否满足需求~以及是否有密钥动态下发的需求？ 好巧，今天团队内部讨论到，真好我们也有apollo，也希望config组件能在启动过程中最先加载拉取配置，然后提供给其他组件用 这个特性对我们十分重要，你们优先安排吗？ 有密钥动态下发的需求，而且我们可能希望密钥能动态更换，因为存在弱密码场景，安全要求整改

> @unionhu 这个 feature 实现起来应该很简单，你们有开发同学感兴趣认领么~ 感兴趣，只是我们最近忙着上线mosn以及配套设施，估计要下下周，我周末有空的时候看看应该怎么搞

> * 在 我反而倾向思路B，在spring boot的设计思想是类似B方案， 这样有个好处，redis等组件只关注自建的配置数据结构模型，类似微服务设计的反腐层，不会跟Apollo强绑定，后续layotto需要对接其他配置中心会变得非常方便 能否评估方案B的工作量？若耗时比较久，可以先走A方案，后续支持B方案

> 5.13 社区会议讨论action: > > * 需要“默认订阅”功能（某个租户/组 下面会默认订阅一批 kv）， @unionhu 可以详细描述下场景、建议的设计; 这个功能应该有现成的，apollo 组件可以配 namespace 等参数，按参数取默认订阅的配置 > * 先按当前方案做个 alpha版，后续 @unionhu 可以基于生产需求来改 alpha 版 目前看应该是没有问题的，我们生产的时间点是希望尽量六月底，先这么走吧，我也刚刚开始介入这块的事项

> 思路B 的缺点除了上面说的之外，还有: > > * 改一个配置项就要重新初始化组件，比如只是动态下发一个开关，就重新初始化、重新建连，太浪费资源 > > 解决“改个开关就要重新初始化”问题，一个优化方案是: 组件可以实现增量更新接口 `updateConfig( configmap map[string]string) (success bool, err error)` 每次配置变更时，runtime 先尝试让组件增量更新，如果失败再重新初始化组件。 > > 其他需要考虑的设计点有: > > * runtime 开放给控制面的动态下发配置接口是啥，怎么和控制面交互？ > >...