[serviceMesh]陌陌实践

数据面: 使用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差不多