本文介绍: 最后,我们会发现,通过zuul请求provider时,流量会被复制到provider–mirror。●假设provider–mirror是provider–demo的灰度应用。需求提了n遍了,好好好,那这个需求就由我测试来做。
思路
补充一下,为什么这里我会想到使用“pre“类型的过滤器实现流量复制/流量镜像。
刚开始的时候,参考了阿里的流量镜像实现方案: 配置流量复制策略,阿里的方案本身是对基于云原生envoy做的,这确实是istio原生能力。istio原生是通过配置spec.-mirror
这个参数,开启流量复制功能,阿里将这个功能白屏化并且对接了自己的监控,不得不承认,阿里对原生istio的很友好。
随后我尝试了sidecar注入、修改envoy配置,但皆以失败告终,一是平台不支持VirtualService,二是平台对Envoy做了一定的优化,配置文件里的各种参数魔改的让我摸不着头脑。
直到上周,突然想到流量复制使用envoy来做的原因之一是因为envoy充当了网关,那可不可以用zuul来实现?有了这个想法后,立即搜索了一遍网上对于zuul的特性描述,只有极少数的博客提到了zuul的复制功能,但均无现成的实现。问题不大,有可行性就行。
实现过程很容易联想到zuul的过滤器,因为pre过滤器可以完整地访问和修改请求信息,可以直接拿到请求并将其复制给镜像服务。有了这个思路一切就顺利多啦~
Spring Cloud代码
在zuul端创建class TrafficCopyFilter:
●假设provider–mirror是provider–demo的灰度应用
配置类
遗留的问题
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。