mosn
mosn copied to clipboard
mosn
The Cloud-Native Network Proxy Platform
## 方案概述 + 删除MOSN扩展的context框架，原来使用扩展contextkey的地方，使用变量机制代替。 + 将MOSN 中的变量机制 （variable）和 内存复用框架 （buffer）迁移到 mosn.io/pkg 中 + 变量机制和内存复用框架用到了 context扩展框架，修改为 mosn.io/pkg/internal的内容，不再对外暴露 + 相关改动 https://github.com/mosn/pkg/pull/62 ## 变量框架改动 + 为了保证连接级别的数据（原部分ContextKey数据）与Stream级别的数据不互相干扰，同时Stream级别的Context又需要保持连接级别的数据，在NewVariableContext的时候，对数据进行了继承，同时通过Clone的方式确保新的ctx 不会对原来的ctx （parent）造成影响 + protocol resource部分，原来从contextkey获取协议的方式，改成了通过协议变量进行获取 + 新增了GetVariable/SetVariable接口，与原来的Get/Set接口相比，入参由name替换成了variable本身。这样做的好处是，可以提前保存变量（如全局），避免基于map进行索引，提高性能；不把Get/Set做成variable的方法，是因为variable是一个interface可能有不同的实现，但是Get/Set...
Support configure status codes in retry policy: ``` "retry_policy": { "num_retries": 3, "retry_on": true, "retry_timeout": "1s", "status_codes": [ 404, 502, 504 ] } ``` depends on https://github.com/mosn/api/pull/48
In some tracing strategies, infos in response headers will be needed. depend on https://github.com/mosn/api/pull/49
ref: https://github.com/mosn/mosn/pull/2024#issuecomment-1122099009
### Describe the bug A clear and concise description of what the bug is. 某客户私有协议tcp扩展，并且采用短连接场景(ping-pong)，服务方在响应完后会主动close链接，mosn侧会导致请求丢失 mosn xprotocol pingpong connpool 拿到服务用tcp发送报文，等待Notify  服务方在处理掉response请求后，发送fin close链接，导致mosn的请求丢失  背景已同步给 永鹏 ### Expected behavior 1....
### The New Feature Logs are rotated according to time rules, and supports limiting the maximum number of logs and whether to compress them ### Your scenes Common O&M Requirements...
### Your question MOSN不支持pilot-agent的prometheus合并请求 /stats/prometheus ### Environment - MOSN 1.0.0 ### Logs 
https://github.com/mosn/mosn/blob/857883d30d979cd5249b96bd857c38cc0b4b3e40/pkg/istio/xds.go#L99
比如Auto协议识别`proxy.go:OnData` 在报错的时候，额外输出一下对应proxy的连接信息，这样可以更快速的定位到是哪个客户端发送了错误的数据