数据面: 使用java语言自研
控制面:自研
1.选型
1.对接大量的内部系统,如果使用istio需要二次开发很多东西.
2.istio重度依赖k8s,我们看到不管是阿里还是微博等,都是去除依赖了
3.envoy使用c++开发.这个还是有很大成本的.所以基于自研
4.当时istio也是不太稳定的状态. pilot性能.每次请求都要请求mix进程check
2.关键点
1.部署方式
同一个pod,不同的container中
2.流量接入
没有采用iptables方式,而是sdk升级,将流量转发到sidecar
可以加一个开关,选择接入或者不接入
为什么不用iptables
个人觉得1.是性能影响 2.是问题排查难度
3.平滑升级
两种方式
fd迁移,这个也是目前mosn的使用方式.
哨兵集群.将流量打入到一个远程集群,唯品会目前的方式.
4.升级方式
升级方式上.
1.注入一个新的container,这样新的container就会和旧的container进行交互,关闭旧的,fd迁移来实现.
但是k8s不支持.注入一个container这种操作. 需要修改k8s代码.
阿里应该修改了.但是小公司投入产出比太低
2.预留一个container位置
启动pod的时候,会有两个container.一个使用,另一个占位,不启动,在需要升级的时候,去启动.这个很麻烦
3.agent去管理sidecar的生命周期.类似pilot-agent
agent就是容器的1号进程.当需要升级时,运维发送升级命令,agent去文件系统拉取新的sidecar.和我们的差不多.
3.性能
1k qps
1k 报文
两跳 耗时<0.2ms ??? 小于6%
可以看到性能还是不错的.只不过内存占用高一些,这个jvm不能避免的,这也是为什么大家都用golang开发.
耗时的话, 0.2ms,1k qps,1k 数据包,和mosn差不多
QA:
1.为什么自研
1.很多的系统都是自研的,服务框架也是私有协议,如果使用现有的 istio.需要做大量的改造工作.
isito重度依赖于k8s,那么在服务发现上,也要做出修改
2.envoy使用c++开发,成本比较大.
3.当时istio的性能和pilot的性能都要问题.
2.sidecar的升级
刚在分享中,已经说了,有一个管理agent的系统,类似tt吧. 这个agentManager系统,用来向agent发送命令,管理他的声明周期.
3.为什么用转发而不是 iptables
iptables的优点:透明
缺点:运维成本高,iptables的配置复杂,怎么进行监控,问题查找. 本质上iptables是O(n)的链式规则.性能损耗不容小觑.
还有一些生产上没有开方 iptables模块.
4.java的性能影响
耗时的话, 0.2ms,1k qps,1k 数据包,和mosn差不多