-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
配置下发通道与配置热加载 #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的方式通知旧连接断开,重新建新连接就可以了 |
配置组件注入的方案预计几时能搞定? |
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: