doujiang24
doujiang24
嗯，看起来有道理，欢迎 PR~
@huanghuangzym we are working on a new envoy-babassl project, that will support Envoy with tongsuo/babassl.
here is the repo: https://github.com/Tongsuo-Project/envoy-tongsuo you can follow the status there.
这么改的话，会不会有就默认值的问题呢？ 比如现在的逻辑是：用户没有配置，我们也默认有 3 次重试？
这里需要考虑向后兼容呢，可能有些老用户，升级了就不重试了，这个影响就大了呢 需求我觉得是合理的，不过得想个能向后兼容的实现
 有个问题是，这是来自 json 的配置，默认就是 0 呢 最好是，新增一个配置项，来改变这个行为，更加保险一些
> 2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧 这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢 如果直接改就是 0 了呢 如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的
> > > 2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧 > > > > > > 这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢 如果直接改就是 0 了呢 > > 如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的 > > 我觉得这种可能性小，他既然到知道用配置了，肯定是知道重试机制的，不存在不配置次数吧，这个配置一共也没几个配置项 这里不能假设肯定会配置呢，没有强制要求配置的，只能说可能性相对小 但是吧，重试这种东西，可大可小，而且有问题了，也不太好发现，真出了问题，其实是比较坑的 如果觉得加配置比较麻烦的话，可以新增一个全局变量当配置，通过变量来控制行为变化，然后暴露一个全局 API 函数来修改这个配置 可以默认用新的行为，通过调用这个全局 API（一个...
我的理解，这里主要原因是 `putCheckTask` 中的 `workpool.Submit` 默认是阻塞等待，这里就会导致协程数量还是可能很大。 我觉得有两个地方需要限制： 1. 并发健康检查的数量，这个是目前已经限制了的 2. 等待健康检查的数量，这个目前是一个等待任务一个协程 我的想法： 1. 可以搞一个队列（带最大数量限制的）来存等待检查的任务，以减少等待任务的协程数量 2. 或者，干脆简单点，不搞等待检查的队列，worker pool 里没有了，就直接丢弃 1 和 2，不管是那种方案，最终都是可能丢弃的，想要不丢任务，应该是很难的。需要做的是，丢任务的时候，打点日志
`MaxBlockingTasks` 有个问题：还是用一个等待任务一个协程。 从限制协程数量上来说，跟一个工作任务一个协程，并没有太大的区别