配置下发通道与配置热加载 #500
Comments
|
Cool. 个人一直期望在layotto runtime 层支持 流量治理规则、支持规则动态下发（像 envoy 那样），这样能帮助所有组件都获得强大的流量治理能力。 不过您的描述比较简单，我有一些疑问，比如：
所以，您能否写个设计proposal，写下“您希望这个功能被设计成什么样”，比如写下您希望 layotto 对控制面开什么样的 api 出来、api 字段有哪些。因为由别人来设计的话，很可能设计出来的字段/功能满足不了您的需求~ |
如果要抽象到xds级别的结构的规则，可能相对困难 redis这种简单的容灾切换应该能满足，但是可能会考虑的更多 通常来说，layotto本地只会有控制面地址配置，其他配置均可以替换，当然也可以从本地配置获取 |
|
方案 v0.1: 需求组件能查询、订阅配置中心的 kv 配置（比如 apollo 中的配置）。 产品设计User story
编程界面允许组件依赖
如果组件有这种需求，需要做以下改动：
"state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"import": {
"config_store": {
"name": "xxx"
}
}
}
},
type Setter interface {
SetConfigStore(store Store)
}方案设计
生命周期为：
其他
|
|
@unionhu 看下这样能否满足需求~以及是否有密钥动态下发的需求？ |
好巧，今天团队内部讨论到，真好我们也有apollo，也希望config组件能在启动过程中最先加载拉取配置，然后提供给其他组件用 有密钥动态下发的需求，而且我们可能希望密钥能动态更换，因为存在弱密码场景，安全要求整改 |
|
建议config和secret都放在 import标签里做，大一统 |
ok "state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"ref": [
{
"type": "component",
"subType": "config_store",
"name": "apollo"
},
{
"type": "secret",
"name": "xxx",
"key": "yyy"
}
]
}
},@unionhu @ZLBer @zhenjunMa @JervyShi 帮忙把把关 |
|
或者用 kind 标识种类， type 标识子类 "state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"ref": [
{
"kind": "component",
"type": "config_store",
"name": "apollo"
},
{
"kind": "secret",
"name": "xxx",
"key": "yyy"
}
]
}
},不过我个人觉得配置结构怎么定都行，上面这种结构可能反序列化代码写起来麻烦点。 "state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"componentRef": [
{
"type": "config_store",
"name": "apollo"
}
],
"secretRef": [
{
"name": "xxx",
"key": "yyy"
}
]
}
} |
|
@unionhu 这个 feature 实现起来应该很简单，你们有开发同学感兴趣认领么~ |
感兴趣，只是我们最近忙着上线mosn以及配套设施，估计要下下周，我周末有空的时候看看应该怎么搞 |
|
默认secret是只获取一次？ config是获取一次+订阅的吗？ |
标记一下，就叫这版是 proposal v0.2:@ZLBer 以这个配置结构为例： "state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"componentRef": [
{
"type": "config_store",
"name": "apollo"
}
],
"secretRef": [
{
"name": "xxx",
"key": "yyy"
}
]
}
},
至于是“获取一次+订阅”，还是“获取一百次、不订阅”，全看 redis 组件的实现，看写redis 组件的人怎么写了~ redis 组件的开发者可以自由使用该 config_store 组件
"state": {
"redis": {
"metadata": {
"redisHost": "localhost:6380",
"redisPassword": ""
},
"componentRef": [
{
"type": "config_store",
"name": "apollo"
},
{
"type": "secret_store",
"name": "foo"
}
],
"secretRef": [
{
"name": "xxx",
"key": "yyy"
}
],
"configurationRef": [
{
"name": "apollo",
"key": "xxxxx"
}
]
}
},
|
|
还有组件启动权重？ 是我们手动调整下代码顺序？ |
是的，就是 spring 那味 👃
澄清一下，我们可以把下发的配置分为两类:
所以这里“注入一个组件”是为了满足“动态配置”的需求； |
是的，调整启动顺序，先启动、初始化 config_store 组件， 再启动别的类型的组件 |
|
@seeflood 动态配置这个，那用户还是需要修改layotto的代码吗 ？ |
|
我们把框架开发好（把依赖注入的逻辑开发好），用户不用修改layotto 代码，但是用户要写自己的组件、自己订阅配置变更、做打开开关之类的功能 这只是我目前想到的方案， 不代表就一定要这样哈，有更好的方案的话都可以讨论 |
|
忽然又意识到了sdk的好处，直接写回调函数 |
|
@ZLBer 感觉你说的是个问题哦，想用这个功能必须写自己的组件，有点不通用？ |
|
干脆就静态配置我们就加载一次，动态配置搞成订阅塞到meta里，但这样缺点就是没法加用户自己的逻辑。 |
这个是啥意思，是说组件配置的metadata 里，配想要订阅的 key，是这样么: |
|
会议结论
|
看了一下mosn加载xDS的逻辑，也是在LDS请求后，拿到了listener进行处理，目前看只支持http的listener，能不能新增一个特别的listener，接受multi runtime的所有配置，专门传递给layotto使用 func HandleListenerResponse(resp *envoy_service_discovery_v3.DiscoveryResponse) []*envoy_config_listener_v3.Listener {
listeners := make([]*envoy_config_listener_v3.Listener, 0, len(resp.Resources))
for _, res := range resp.Resources {
listener := &envoy_config_listener_v3.Listener{}
if err := ptypes.UnmarshalAny(res, listener); err != nil {
log.DefaultLogger.Errorf("ADSClient unmarshal listener fail: %v", err)
continue
}
listeners = append(listeners, listener)
}
return listeners
} |
|
听起来可行？ @ZLBer @wenxuwan @rayowang @zhenjunMa @nejisama 帮忙一起看看哈 |
|
没看懂 不知道说的什么 |
|
@nejisama 我理解核心思想是：
|
|
xds 下发字符串的通道是什么？还是新的一种新的，和listener（lds）、cluster（cds）并列的资源类型？还是用某个资源的字段做特殊的解析？ |
|
上面例子里 就是一个filter配置，那就是转换成一个标准的filter实现，比如是一个flowcontrol 的filter 那就只能转换成一个 对应实现的flowcontrol 的filter 。 如果是这样 那对应实现相关的filter就可以了 |
|
@unionhu 最新进展，不用改控制面的方案:
各位帮忙一起看下哈 |
但是这个并没有告知怎么传递给layotto的grpc filter |
|
@unionhu 我们有两个问题要解决：
|
|
是的，第一个问题好处理 |
|
关于 "2. Layotto 如果做配置热加载"，有俩方案: 方案 A. 通过 XDS 做配置变更后，mosn 下次接受新连接、创建新的 networkfliter 时，会自动用新配置创建 @unionhu 如果先用这种方案呢？ 方案 B. 下发的 XDS 配置里，把 Layotto 相关的配置存到某个全局 map去，然后 Layotto 做个配置监听功能，监听这个全局 map，有变更则热加载 好处：轻量；旧连接也能更新 |
偏向方案B，能否你先设计，如果代码量不多，我看看能不能搞定 |
|
@unionhu 恩，按方案 B 去推演（把 Layotto 相关的配置存到某个全局 map去，然后 Layotto 做个配置监听功能，监听这个全局 map，有变更则热加载），其实就说回到了咱们一开始讨论的两种方案: B1. 组件注入比如支持把 config store 组件注入进 pubsub 组件 B2. Layotto 开一个抽象的 update 接口见上面的讨论 #500 (comment) 两种方案都能满足你的需求，而且目前看来，两种方案将来都要做（现在就有用户想用 B1 方案） |
|
@ZLBer Hi, 要不，继续搞 |
|
@seeflood 可以的，我试图理解下 |
|
LDS更新旧连接的问题，由于layotto是grpc 应该可以考虑用goaway的方式通知旧连接断开，重新建新连接就可以了 |
恩感觉这也是个思路。上次看mosn grpcFilter 的代码，发现其实注册进去的 handler 只会初始化、启动一次（如下图），也就是说每次下发新的 LDS 配置后，即使有新连接，grpcFilter 也不会按新配置重新加载 Layotto；所以按这个思路要新写个 Layotto 自己的 grpcFilter 如果发 goaway、让app 重连，会影响业务么？ |
配置组件注入的方案预计几时能搞定？ |
cc @ZLBer |
|
@unionhu 我在改启动生命周期的时候也遇到了配置下发的问题，见 #744 (comment) |
|
component-ref预计该周末提交pr |
|
action:
|
希望提供一个通用的配置下发的grpc协议通道，用于layotto与控制面的交互（可以参考go-control-plane），
可以随意定义用户可以，随意的定义下发配置的策略内容
用途：
1.redis、kafka客户端流量管理控制，可能需要容灾切换、灰度发布策略切换
2.redis连接参数调整、安全弱密码自动切换
The text was updated successfully, but these errors were encountered: