《王建新-转转测试环境流量隔离架构演进.pdf》由会员分享,可在线阅读,更多相关《王建新-转转测试环境流量隔离架构演进.pdf(45页珍藏版)》请在三个皮匠报告上搜索。
1、转转测试环境流量隔离架构演进主讲人:王建新演讲嘉宾介绍王建新转转服务治理负责人 RPC框架、注册中心、网关、分布式调用跟踪系统 自研转转RPC框架、注册中心、分布式调用跟踪系统 主导转转流量路由、全链路压测功能开发CONTENT目录2023K+01为什么需要流量隔离物理隔离Plus基于自动IP为标签的流量路由0203基于手动打标的流量路由04工具链05Part 01为什么需要流量隔离为什么需要流量隔离测试环境不同开发分支之间隔离生产环境全链路灰度隔离生产环境全链路压测隔离Part 02物理隔离Plus 物理隔离 物理隔离Plus物理隔离每套环境包含全量的服务简单可靠隔离非常彻底资源占用非常高优
2、点缺点物理隔离Plus稳定环境:多IP,包含全量的服务动态环境:一台kvm,同一个IP,包含从nginx开始至最后一个要测试的服务稳定环境作为链路的尾巴可以复用物理隔离Plus禁用注册中心每个RPC服务分配唯一域名,默认解析至稳定环境如果某动态环境包含该服务,则将该服务域名解析至127.0.0.1按服务依赖顺序倒序部署动态环境添加服务后,重启调用方MQ通过修改配置文件为topic添加ip前缀,队列隔离隔离较彻底资源占用较高 优点域名管理复杂配置文件易出错搭建环境耗时长 缺点Part 03基于自动IP标签的流量路由 部署方式 RPC路由 MQ路由 难点 收益 优缺点部署方式稳定环境:多IP,包含
3、全量的服务动态环境:一台KVM虚拟机,部署nginx+Entry+修改的服务通过注册中心进行RPC服务的发现流量经过Entry时,用Entry所在的IP为流量打标签MQ在动态环境为group添加IP前缀,在MQ客户端自动完成MQ在稳定环境为group添加test前缀,在MQ客户端自动完成RPC路由服务所在IP即是标签优先调用节点IP和流量标签相同的节点,其次稳定节点MQ路由 稳定环境与动态环境共享队列,不共享offset 消息丢失问题怎么解决动态环境消费者下线时,将与稳定环境offset之间的消息重新投递 批量消息如何解决按标签分组后再消费难点跨进程传递标签自研RPC框架,可传递扩展字段Roc
4、ket MQ二次开发,通过header传递标签进程内传递标签通过方法参数传递,改造成本非常高使用ThreadLocal传递,并提供RunnableWrapper,CallableWrapper,改造成本较高使用阿里开源的TransmittableThreadLocal,通过agent的方式做增强,对应用透明,无改造成本收益左图为服务数量曲线,右图为每环境部署服务数量曲线优缺点优点使用方式完全兼容节省资源,仅部署Entry+X(修改的服务)部署效率高,约30min-1h标签对RD&QA无感知缺点单台KVM内存有限,无法扩容申请虚拟机耗时长只能在测试环境使用链路复杂Part 04基于手动打标的流量
5、路由 部署方式 RPC路由 MQ路由 收益 优缺点部署方式稳定环境:多IP,包含全量的服务动态环境:多台Docker由环境平台自动添加jvm参数-Dtag=$tag通过注册中心进行RPC服务的发现,服务注册时将tag上传至注册中心MQ在动态环境为group添加$tag前缀,在MQ客户端自动完成MQ在稳定环境为group添加test前缀,在MQ客户端自动完成通过Http Header为流量打标RPC路由服务方将节点标签上传至注册中心优先调用节点标签和流量标签相同的节点,其次稳定节点MQ路由 稳定环境与动态环境共享队列,不共享offset 消息丢失问题怎么解决动态环境消费者下线时,将与稳定环境of
6、fset之间的消息重新投递 批量消息如何解决按标签分组后再消费收益05101520每环境部署服务数量700750800850900950服务总量收益05000250030003500测试动态环境内存占用kvmdocker总内存05000沙箱动态环境内存占用kvmdocker总内存收益00测试稳定环境内存占用kvmdocker总内存050002500沙箱稳定环境内存占用kvmdocker总内存优缺点优点:仅部署X(修改的服务),不需要部署nginx+Entry申请环境快,秒级完成部署效率高,约5-10min节
7、省资源无内存限制线上压测场景可实现流量隔离缺点QA有感知,需要在HTTP Header中添加标签Part 05工具链 环境平台 Web shell 泛域名解析 远程debug插件 分布式调用跟踪系统工具链环境平台:管理测试环境的资源分配、服务部署Web shell:基于浏览器的终端泛域名解析:通过域名传递标签参数远程debug插件:idea插件,可以根据项目名+标签连接远程debug分布式调用跟踪系统:调用链路可视化环境平台申请环境环境平台部署Web shelldocker化以后ip地址总是变化,xshell等工具需要重新登录,使用web shell直接在浏览器中登录服务器泛域名解析使用hea
8、der传递标签,仍然需要配置host将域名映射到测试环境的nginx例如,直接使用域名传递标签app-$远程debug插件docker化以后IP地址总是变化,使用ide debug时总需要更换IP,自动获取IP和端口提升开发效率分布式调用跟踪系统流量路由使得链路在不同的机器间穿梭,出现问题难以排查调用链路是否符合预期,是否正确地经过了所有的被测服务,需要验证分布式调用跟踪系统分布式调用跟踪系统分布式调用跟踪系统 “traceId”:“61bb34bf0a88dd060003e81d005a4d12”,“parentId”:“c1955a11739e43c1”,“id”:“2032260de3b
9、8b175”,“kind”:“SERVER”,“name”:“scf.response”,“timestamp”:24763,“duration”:5970,“localEndpoint”:“serviceName”:“categ*”,“ipv4”:“10.*.*.5”,“port”:*,“remoteEndpoint”:“serviceName”:“open*”,“ipv4”:“10.*.*.6,port:*,tags:application.type:SCF,trace:一条链路traceId:时间戳+ip+pid+自增idspan:一个埋点spanId:埋点idpa
10、rentSpanId:父埋点id异步传递:TransmittableThreadLocal测试环境100%采样率线上2%采样率局部异常100%采样网关层以HttpHeader的形式将traceId返回前端分布式调用跟踪系统在路由关键节点,采集流量标签和当前节点标签分布式调用跟踪系统在Entry层将TraceId返回到前端分布式调用跟踪系统利用MDC功能将traceId,spanId打印到日志中Part 06总结 不同架构对比 获奖情况 项目感想不同架构对比物理隔离PlusIP路由标签路由机型类型KVMKVMDocker搭建耗时2h-2d30min-1h5-10min内存无法扩容无法扩容无限制服务数量受内存限制受内存限制无限制部署服务nginx+entry至最后一个测试服务nginx+entry+修改的服务修改的服务使用环境测试测试测试+线上部署时间编译+启动编译+启动编译+构建镜像(top90 40秒)+启动(资源充足更快)打标方式无标签自动化手动获奖情况项目感想合作架构、运维、工程效率、业务难点不在技术,在落地配套工具链很重要没有最好的架构,只有更适合的架构THANKS