江苏龙网

  1. 主页 > 生活百科 > >

字节跳动自研线上引流回放系统的架构演进( 四 )

字节跳动引流回放系统


字节跳动自研线上引流回放系统的架构演进

文章插图
 
在一个生产环境下的 (A,B,C) 链路中，通过 ByteCopy 实现了针对每一跳 (request, response) 的采集，在做 A 的 diff 验证的时候，通过 ByteCopy 实现对于 A 服务请求的回放，同时，基于 ByteMock 来实现对于服务 B 的 mock，并支持针对一个 trace 的 response 回放 (依赖 ByteCopy 中流量存储，实现精准的回放) 。因为 B 是 mock 的，即使是一个写的请求，也可以做到对于线上没有任何影响 。
4. 未来展望4.1 更精准的流量采集前面提到，在进行出口流量的采集时，会对下游依赖服务的所有实例的 IP:端口 进行抓包 。而实际的生产环境中，同一台服务器上，可能会部署具有相同下游依赖的多个服务，只依赖四层数据，无法判断抓到的数据到底来自哪一个服务，会造成抓包、处理和转发流程中都会存在资源浪费的问题 。目前来看基于网卡抓包的方案应该没法很好地解决这个问题，我们也在尝试探索一些其他的流量采集的方案，比如探索用 ebpf 进行进程级别的流量采集 。
4.2 引流回放系统的重新定义现阶段我们的引流回放系统只会根据用户的配置被动进行流量采集，而为了及时拿到流量进行测试，用户一般都会选择实时引流进行测试 。而实际上并不是所有的场景都一定需要实时的流量进行测试，我们在规划逐步将引流回放系统从一个按照用户要求进行流量转发回放的工具，转变为一个线上复制流量的取用的平台 。
在流量存储能力的基础上，对于有测试需求的服务，平台主动错峰、定时发起流量录制任务，从而维护一个不断更新的流量池，用户需要流量时直接从流量池中取用，这样一来，既可以尽量避免引流操作对和线上业务抢占计算资源，也可以使得流量的可用性更高 。
4.3 特定场景下的流量存储优化随着基于流量录制回放的上层应用的完善，为了更多的业务方便接入试用，我们正在考虑朝着常态化的引流去演进 。这个势必对我们的流量存储带来新的挑战，无论是的数据规模，存储形态以及查询性能 。我们希望可以基于现有架构的存储系统，构建流量存储的解决方案，支持海量数据吞吐的同时，能够支持点查(基于 TraceId )，和 time-range scan 等多种复杂的高性能查询方式 。另外我们也在积极和安全团队合作，确保相关核心流量数据在存储时候能够实现脱敏，同时不断强化对于流量存储使用的安全审计 。
5. 总结到今天为止，ByteCopy 系统已经支撑了字节绝大部分业务线在不同场景下的各种引流需求， 我们一直在努力丰富 ByteCopy 的功能场景，不断提升系统稳定性和吞吐容量，此外我们也在积极构建 ByteMock 等自研的研发组件，通过和 ByteCopy 形成组合拳，解锁生产流量在研发活动中更多的使用场景，帮助业务团队更好地去构建各种有趣的产品 。
字节跳动基础架构团队字节跳动基础架构团队是支撑字节跳动旗下包括抖音、今日头条、西瓜视频、火山小视频在内的多款亿级规模用户产品平稳运行的重要团队，为字节跳动及旗下业务的快速稳定发展提供了保证和推动力 。
公司内，基础架构团队主要负责字节跳动私有云建设，管理数以万计服务器规模的集群，负责数万台计算/存储混合部署和在线/离线混合部署，支持若干 EB 海量数据的稳定存储 。
文化上，团队积极拥抱开源和创新的软硬件架构 。我们长期招聘基础架构方向的同学，具体可参见 job.bytedance.com （文末“阅读原文”），感兴趣可以联系邮箱 guoxinyu.0372@bytedance.com  。




推荐阅读


上一篇：宇宙的维度 高维宇宙在另一个维度空间

下一篇：常用的页面置换算法