goc
goc copied to clipboard
qiniu
v2 是否会支持cover watch message 携带具体service id及extra
还有 https://github.com/qiniu/goc/blob/ee63433ca4e361e5e1f209e62757c5f402659edf/pkg/build/inject.go#L267-L283 这里如果mode是set 可以只有0 -> 1的时候才发通知到通道 可以提供个选项？选项的主旨是仅当第一次触发才通知 当然适用于其他mode 比如count > 0就不通知了 只有0 -> 1会通知
场景: 比如mode是set时 通过watch想实际变化后生成总覆盖率 但是现在的watch只要触发倒桩代码就会通知 假如有很多相同代码版本的service就会merge消耗cpu很多 这边暂时用了rate来限制
支持watch message 携带具体service id及extra也是为了变化时只去获取某一个service的profile 不然无法分辨哪个service的覆盖率变动了 只能全部profile get, merge也会很耗用cpu
还有
https://github.com/qiniu/goc/blob/ee63433ca4e361e5e1f209e62757c5f402659edf/pkg/build/inject.go#L267-L283
这里如果mode是set 可以只有0 -> 1的时候才发通知到通道 可以提供个选项？选项的主旨是仅当第一次触发才通知 当然适用于其他mode 比如count > 0就不通知了 只有0 -> 1会通知 场景: 比如mode是set时 通过watch想实际变化后生成总覆盖率 但是现在的watch只要触发倒桩代码就会通知 假如有很多相同代码版本的service就会merge消耗cpu很多 这边暂时用了rate来限制
支持watch message 携带具体service id及extra也是为了变化时只去获取某一个service的profile 不然无法分辨哪个service的覆盖率变动了 只能全部profile get, merge也会很耗用cpu
听起来是个挺合理的需求，非常感谢 @maxiloEmmmm
另外，你这边怎么会要用到这个watch的能力呢？具体场景是怎样的呢？
因为service不确定什么时候停止 也就是disconnect 比如版本的切换 服务自身的crash, 可能出现service停了然后去获取profile获取不到的情况 想着既然我不知道你什么时候停 那就只要变化了我就落地一次 同时采用rate和dirty机制(也就是落地过程中watch变化了1次就再也没有变化了)保证尽可能的获取最新的覆盖率
这边大概实现： extra会是 服务名_commitID 一个服务会跑多个版本去测试
再跑一个listener服务去watch goc server 拉取所有service 然后通过extra聚合落地
