在本次双十一之前，我们上线了新版的批处理框架，完整支撑了大促的招商。通过SDK接入，可以直接在业务应用中实现任务逻辑，接入便捷；通过中心化调度与任务分发，处理过程提效明显。
测试左移这个测试方法已经出现很久了，但收益如何，收益如何体现，在不同的团队如何实施起来，现阶段在质量平台还暂未标准化和统一化。测试人员来实施测试左移，则需要测试人员具备业务分析能力，能做一定的业务分析，能看懂业务架构和技术架构，甚至具备代码查看和编码能力，能分析代码逻辑等。 在QA方面，测试自动化是一种行之有效的方法，可以让业务测试更加便捷，减少任何形式重复劳作和返工测试，提高轮次测试执行效率。目前自动化已在迭代应用中进入收益阶段，不仅在回归阶段代替手工回归测试，将自动化作用价值体现最大，也让自动化提前介入需求测试分析中，做到“测试左移”。 今年第一季度团队已提前试点“测试左移”，将自动化提前纳入需求测试分析阶段，在研发提测节点按需完成自动化左移。但是光从口头上说“测试左移”，也不能印证自动化左移的数据，以及左移带来的实际收益和价值，现阶段平台侧将 RDC(Research and Development Collaboration / 研发协同平台，得物技术部自研的一套项目管理工具）、协同面板、流水线、用例平台、自动化平台五方联合，共同搭建出测试左移的全链路操作。
B站的 CDN 下行边缘节点过去是非集群化架构。这种架构下有几个弊端： 增加调度逻辑复杂性； 同机房流量/负载难以均衡； 暴露过多的公网IP，增加安全隐患 (盗链等)； 灰度流量比例分配粒度大； 针对以上问题，我们调研了常见的四层负载均衡器， 传统的 SLB，LVS，DPVS 这类四层负载均衡器，在功能上也能满足我们现有的需求。但是以上几个负载均衡器均需要独占机器，进而造成成本升高，资源浪费。 有没有一种既不增加成本，又能解决边缘节点四层负载需求的方案呢？由 Cloudflare 提出的基于 Express Data Path (XDP) 的高性能四层负载均衡器 Unimog[1]性能优异，并且可以和后端服务同机部署，在性能上也完全满足我们边缘场景的要求。所以我们参考 Cloudflare Unimog 的思想，在其基础上自研了适用于B站的边缘四层负载均衡器 Nickel (以下简称 Ni) 。
为优化淘宝带宽成本，我们在网关 SDK（Java）统一使用 ZSTD 替代 GZIP 压缩以获取更高的压缩比，从而得到更小的响应包。具体实现采用官方推荐的 zstd-jni 库。zstd-jni 会调用 zstd 的 c++ 库。
在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。在不同的书籍上, 不同的作者, 对于架构的定义也不统一、角度不同、定义不同。此君说的架构和彼君理解的架构未必是一回事。 因此我们在讨论架构之前，先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 今天的系列图就跟大家分享鹅厂工程师关于架构设计的理解与总结。
