随着持续集成和敏捷开发的不断发展，移动应用的发布变得越来越频繁。以B站应用为例，主站粉版APP每周都会发布一次新的版本，主站HD应用的Android端与ipad端每周交替发布新的版本。在应用快速迭代的同时，QA需要在规定时间内进行大量的回归测试以保证应用的质量。一方面，大量的测试用例需要耗费较多的人力和时间，另一方面，BUG检出时间的不确定性导致给予研发修复的时间并不是很充足。因此急需一种技术来帮助QA快速筛选出高风险用例，将BUG的发现时间提前，从而给研发更多时间去修复BUG。在此背景下，我们经过调研后，选择了使用测试用例排序优化技术(Test Case Prioritization，以下简称TCP)来帮助QA对测试用例进行优先级排序，提高测试效率。
以Flink为基础的实时计算在B站有着广泛而深入的应用。目前B站的Flink作业主要运行在三种集群环境下：纯物理机部署的YARN集群、为了提高Kafka集群资源利用率而和Kafka混部的YARN集群以及为了提高线上服务器而和K8S混部的YARN集群（这部分有计划在不远的将来使用Flink On K8S部署方式代替）。其中纯物理机YARN集群使用纯SSD盘的统一机型的服务器，包含1000+台服务器；和Kafka混部的集群目前为Flink提供了2000+ cores；和线上的K8S混部的集群已经使用了6000+ cores，并且还在持续增加。在业务方向上，B站的Flink已经应用在了包括AI、广告、数仓、数据传输和其它的很多业务上。目前B站Flink作业的最大并行度为2000。下图展示了B站实时应用的整体架构及Flink Runtime的工作范围。
S12决赛尾声，伴随DRX成员们从眼泪到荣耀的升华，技术保障团队的心也松弛下来，逐渐把目光从监控中挪开。一方面分享胜利的喜悦，一方面也为实现了“边喝茶边保障”的目标而高兴。 B站在本次直播为了提升用户体验，开启了送礼特效。以送礼为核心的营收场景是业务主推的方向之一。为此团队的小伙伴们在业务需求繁忙的情况下，同时做了大量的准备和优化。 本文我们聚焦于以写为主的送礼场景，对我们的技术保障思路做个简单的总结。聚焦到一个问题，那就是：高写场景该如何做技术保障？
为了给用户提供更好的视频观看体验，B站已研发出很多先进的视频图像分析与处理算法。在视频转码任务中，这些算法既可以改善视频画质，也可以促进转码效率的提升，从而实现更高清、更流畅的视频效果。研发的算法种类繁多，用途各异，同时B站不同业务对于算法的要求也各不相同。为了能够对各种基本算法进行高效部署和管理，同时向各个业务方提供简单灵活且统一的调用接口，B站研发了一套功能强大的视频图像分析与处理引擎——BANG（Bilibili video/image Analyzing and processiNg enGine）。
观众对画质的追求越来越高，有需求就有市场，主播也使用越来越高的画质进行直播。在这个过程中，直播平台需要负担的带宽成本也迅速攀升。 事实上，网络带宽的支出在技术成本侧是占比最大的部分。为了将成本控制在一个可以接受的范围，各直播平台纷纷使用P2P技术来降低服务器带宽。云服务提供商也提供了成套的解决方案，可以为没有自研能力、无法负担自研成本或短时间内无法完成自研的直播平台提供快速接入。 随着B站内部对HLS协议直播的传输研发完成度不断提高，自研P2P的前提条件具备了。HLS本身是一种切片式的直播传输格式，具体细节可以参考前面的《HLS直播协议在B站的实践》。因为切片是静态文件，所以可以通过HTTP带Range头的请求下载这个文件的指定部分。如果让不同的观众下载同一个切片文件的不同部分，然后这些观众之间再互相交换一下数据，大家就都有完整的数据了，而服务器事实上只传了一份数据出去，带宽成本就大幅度降低了。
数据质量是基于大数据衍生的应用有效与否的重要的前提和保障之一。为了能在大数据上面孵化出更加有深度，更加有竞争力的应用，以及B站高速发展的业务都需要我们数据平台能提供实时的，准确的，可以被信赖的数据。 而另一方面，数据平台要向终端用户提供可以信赖的数据，又依赖于整个数据加工链路环境的稳定迭代和健康发展，这涉及到数据平台模型本身的质量，业务调度的可靠，资源调度的高效，以及各种执行引擎的高效协作等等，最后所有这些大数据基础组件的稳定又离不开PAAS, IAAS等基础服务的稳定。 总之，可信赖的数据质量是大数据平台核心竞争力的体现，是大数据航母战斗群的预警机。数据质量团队的背后是大兵团级别的组织、协作和保障工作。数据质量的高可信度依赖于业务模型团队，数据质量平台，业务调度团队，计算引擎团队，和各种存储和搜索查询引擎等兄弟舰队通力合作和鼎力支持。
1. B站的直播间作为整个APP中交互最为复杂的单页面之一，其承担的业务量已经不亚于一个小型APP。对比APP的结构会发现许多相同处，但与组成APP的各个独立Activity不同，直播间由各个独立的视图组成。 2. 业务逻辑基于MVVM的设计分为三层（Service即M层），理想状态下各个业务间的交互是内聚的，各业务间不会感知到其他业务的存在，View显示需要的数据和状态都由各自对应的ViewModel提供。 3. 现实情况中业务交互并没有那么理想，直播间中的一个View显示的数据会受到其他业务的数据、状态影响，因此一个View除了需要处理自己内聚的逻辑为还需要关心其他View的数据变化。
众所周知，B站在不知不觉间已经成为一家拥有相当体量的互联网公司。拥有自己的IDC的小破站，每年都会对以服务器为代表的硬件设备进行选型迭代。服务器选型评估指标有很多，其中性能是最重要的指标之一。服务器性能涉及服务器硬件、操作系统以及业务应用等多个方向，为准确评估服务器硬件性能，服务器硬件与操作系统层面的性能优化也是B站系统组工作重要的组成部分。这篇文章B站系统组就基于单路AMD Milan CPU服务器，粗浅的介绍一下服务器基础性能调优与评测的工作。希望能抛砖引玉，共同学习，将服务器性能调优与评测这个长线工作不断迭代更新下去。
