Posted by on | Featured

内容来源：DevOps案例深度研究第4期 – B站 DevOps实践研究战队（本文只展示部分PPT及研究成果，全程视频请移步文末）转载请注明出处。

本案例内容贡献者：曹坤良，董沙莎，过佳昱，廖定，李晶晶，李思源，欧美玲，任广印，Ruth，姚丹，张楠

IDCF指导老师：徐磊、姚冬、王立杰、许舟平

原文首发于「老广的印记」

Bilibili简称B站，是中国年轻人聚集的文化社区月活跃用户量 1.28亿人18-35岁用户占总用户数78%(数据来源：2019年Q3财报)

一、文化和历史
B站，被粉丝昵称为“小破站”，为中国年轻一代高度聚集的文化社区和视频平台，深受年轻用户的喜爱。经过十年多的发展，围绕用户、创作者和内容，构建了一个源源不断产生优质内容的生态系统 ，B站已经成长为一个涵盖7000多个兴趣圈层的多元文化社区。

B站原名叫：Mikufans弹幕网。最早的雏形是“初音未来”的粉丝交流社区。于2010年1月改为提供视频资源的网站，并正式改名为Bilibili。哔哩哔哩的名字来源于《某科学的超电磁炮》，创始人徐逸是这部动漫的狂热粉丝，女主角御坂美琴用硬币打出电气系技能超电磁炮发出的声音像Bilibili，徐逸觉得这个名字好听又好记，所以将Mikufans改名为Bilibili。而御坂美琴发射电磁炮的硬币，也成为B站现在的通用货币。

  • 徐逸：创始人，意见领袖，重度动漫迷。曾任执行董事。2019年卸任法人代表和执行董事，目前负责社区运营。
  • 陈睿：董事长兼CEO。曾任中国最早的互联网软件企业之一金山软件联合创始人。2011年，陈睿以天使投资人的身份加入B站；2014年，正式加入B站担任董事长。
  • 李旎：首席运营官。

B站企业文化关键词：社区优先，正直诚信，合作共赢，极致执行

我们可以看到，B站企业文化关键词第一位的是社区优先，董事长陈睿曾经说过，B站在社区文化建设中的两个初心：

  • 为用户构建好的社区。
  • 为创作者搭建施展才华的舞台。

二、社区运营生态B站2019年的跨年晚会非常成功，收获了非常多的赞誉，在豆瓣的评分高达9.2，截止二月底累计播放量9075万次，弹幕总数294万，最高在线人数8000万，被称为最懂年轻人的晚会。
B站跨年晚会成功的背后 – “B站对于不同年龄的用户画像的深刻理解和把握”。

B站的用户群体大部分是年轻人，可以看这张统计图，24岁以下的使用人群超过B站用户的的38%。B站还是中国最大的音乐创作平台之一，中国增长最快的 vlog 社区，中国最大的在线自学平台等等。这背后最大的原因，就在于B站对于不同年龄段用户的用户画像的深刻理解和把握。B站最典型用户画像-Z世代。

报告显示，目前，全球Z世代有24亿人，占全球人口的32%，而在中国，Z世代的用户约占20%。针对这样的一群金主，B站是如何做的呢?

形成了以 ” 原创内容 + 用户 + 弹幕 ” 的交互方式所构筑的强粘性社区生态环境， 以及由 “UP 主 – 内容 – 社区用户”所组成的循环生态。这个生态是一个不断自增长的闭环。随着UP主群体的不断扩大，社区内容也向多元化发展，同时又吸引了更多的用户。B站的这种以内容即社交的“打开方式”，正是B站在年轻人中受到欢迎的主要原因。

三、用户价值为导向的需求管理
下面我们来介绍B站以用户价值为导向的需求管理，前面已经介绍了B站以用户价值为核心的企业文化和运营生态，如何通过产品研发和系统实现呢？首先介绍用户价值为导向的需求管理。
B站的用户价值以业务需求为载体，通过需求分析的筛选，快速地流入到研发并投产上线，并通过上线后的运营和用户来持续优化产品，实现整个业务价值的闭环。遵循DevOps的核心思想，持续快速的迭代反馈，特别是在用户需求的收集分析管理和用户反馈上，凸显出对用户价值的关注。接下来我们重点分析。首先是用户分析，我们看看B站核心用户画像。

  • 二次元用户（核心目标用户）：可以追番剧，了解二次元文化，希望能认识更多同好。
  • UGC创作者（核心目标用户）：希望有一个大平台可以让自己作品被看到，收到大家认同。
  • 直播爱好者：希望有平台能展示自己的才能。
  • 非二次元用户：只是单纯地希望能找到有序的视频，或跟随喜欢的UP主或主播而来。

有了清晰的用户画像，可以分析出B站的需求主要分为视频内容、用户体验、社区文化和氛围环境四类。

  • 视频内容主要包括番剧、原创视频及UP主自制类视频功能，加上以用户为中心的页面布局、交互等用户体验设计，这两类需求针对核心用户占比会比较大，也呼应了前面的注重核心用户价值和体验。
  • 社区文化类主要包括会员管理及支撑圈层的需求；氛围环境类包括弹幕和交流环境以及相关审核的需求，这两块为共同爱好者持续的交流分享营造一个良好的氛围，为核心功能提供支撑，这是B站重点响应的部分。

需求的收集主要从两个方面：

  • 一方面通过全面分析商业价值、用户价值、分解转换为具体实现的需求；
  • 另一方面在快速响应需求上线以后，收集用户反馈来持续完善产品的需求。

对于需求的优先级排序，B站有自己管理方法。

  • 首先它是基于用户及商业价值的分析，基于核心用户的诉求和用户画像，优先考虑需求的迫切程度，通过良好的用户体验既维持老用户的粘度。对于系统运行稳定的一些非功能性的需求，也作为重点的排序考虑。
  • 另外基于商业价值考量，针对付费用户，用付费情况来衡量需求价值，更量化且与商业接轨。
  • 考虑用户与商业价值分析的同时，B站也会使用四象限法来进行需求的筛选和排序，通过需求的用户范围、发生频率和成本、效益，进行综合分析排序，确保用户价值价值较高的需求能够优先、快速地进入迭代循环，快速地上线并得到用户的反馈。

B站采用多种方式来收集用户的反馈，不仅包括了线下渠道的主动收集，而且还通过日志采集、设置埋点等多种手段，线上自动采集运营数据。对于线上的采集，采取了收集用户行为和用户数据的方式，首先与业务方一起绘制需采集业务场景涉及的系统链路，然后系统分布分别在客户端和服务端设置埋点，采集用户行为数据，记录日志。通过新功能灰度上线后目标用户数据采集和分析，形成对需求的快速反馈，持续打磨完善产品。

通过以线上与线下相结合的用户反馈收集机制，从用户画像分析、需求筛选排序到持续迭代反馈，用户的价值在DevOps循环中快速流动持续交付，B站实现了以用户价值为导向的需求管理的闭环。

四、高性能微服务实践

一开始B站的技术以PHP为主，那时的代码大家喜欢称之为“KFC全家桶”，一套代码包含了所有的东西，包括CDN的管理、转码、多媒体视频的处理等等，都是通过PHP来完成的，当时就是这样一套系统支撑着B站的业务运行。这么大的一个系统面临着很多问题：1）代码维护难度大

  • 文档缺失，上手难度大。
  • 理解业务逻辑很耗时。

2）基础架构难以扩展

  • 基于织梦CMS，一个开源的内容管理系统。
  • 系统做了深度定制，底层逻辑没几个人能搞定。
  • 业务聚合在一起，不易被扩展和拆分。
  • 运行环境基本上只能通过创始人来扩展。

3）运维复杂

  • 线上配置很复杂，代码层面没有设计路由系统。
  • 运维已经不堪重负，已经禁止添加重写规则。

B站成立的基础是一个天才型选手，以前在那套系统加入了一些黑科技的东西，但同时也就限制了公司团队的发展，基于这样的一些重点问题，随着业务的发展和团队的不停增长，解决B站目前面临的这些问题势在必行。

4.1 服务化/微服务化

1）优势

  • 各个服务独立开发。
  • 分工明确，各自迭代。
  • 单独模块独立部署。
  • 可独立进行测试。

2）挑战

  • 依赖链条长，测试常常遇阻，影响测试结果。
  • 各服务的一致性难以保证。
  • 运维成本高，错误难定位。
  • 基础设施，网络等要求都比较高。

针对业务逻辑进行垂直划分切割，将一个巨大的服务体系，按业务逻辑切割成单元相对独立的服务，如：评论、硬币、稿件、收藏、feed等，服务间依赖标准采用RPC调用。

（微服务架构）

4.2 RPC框架

B站一开始是以PHP为主流开发语言，后来为了快速支撑业务的发展，Node、Java、Python等开发语言也相继出现，导致B站的核心技术栈无法统一，对于微服务的落地，是兼容所有的语言基于现有架构改造，还是选择统一的技术栈进行重写？B站选择了后者。归根结底，重写后台工程（主要是账号相关的业务）是哔哩哔哩统一技术栈的一次尝试，至于最后为啥选择了用Go来实现RPC，在2017全球架构师峰会上，毛剑解释很简单：“主要就是我比较喜欢Go”，看似简单的一句回答，其实支撑其选择的原因还在于Go的诸多优势：

  • 强大的标准库，解决了B站在视频方面的问题。
  • 和Docker容器化良好的支持。
  • 二进制发布，优秀的执行效率和开发效率。
  • 易学易用上手快。
  • 背靠Google大厂，丰富的开发者生态。
  • 支持几乎所有主流的框架。

又或者说，选择Go非要有个原因么？为什么不能是Go呢？

1）B站的RPC框架

  • 基于Go原生的网络库“net/rpc”。
  • Gob进行struct的序列化，不需要拷贝额外的代码，使用较为方便。
  • 方法级的超时控制。
  • 上下文context的支持。

2）服务注册与发现Discovery

  • 及时同步服务上下线事件。
  • 服务发现节点自我发现。
  • CP模式：依赖ZK的心跳进行广播（ZK心跳遇到抖动时候，容易出现全服务下线 ，所以B站会根据服务节点变化数进行判断是否放弃本次变更，进行容错）。
  • AP模式：polling + ping（优先保证高可用，牺牲部分一致性，但最终达到一致）。

3）配置中心

  • 利用mysql做存储管理相关配置信息。
  • 通过http long polling来检查配置变更确保及时生效。
  • 获取服务ip和版本，记录meta信息，实现服务发现的功能。

4.3 高性能

微服务化以后，曾经的本地调用变成了远程调用，曾经的多节点对等变成了分布式的多节点，部署越来越复杂，调用链条越来越长，跨机房、跨网络、跨机架等都可能造成性能损失。1）链路加速（客户端&服务端）

  • 慢、流量贵（移动端）。
  • HTTP DNS & Server List。
  • 多CDN加速（规避风险）。
  • 协议优化（压缩、聚合、根据网速选择资源等）。

2）网关优化（go自研，灵活可控）

  • 动态配置
  • 协议装载
  • 业务拦截
  • 限流保护
  • 缓存加速
  • 鉴权
  • 反作弊
  • 业务服务
  • 统计&监控

3）优化服务部署架构多个组，小集群方式部署，每个组依赖更少的节点，这样依赖资源有多套，相互之间也达到了隔离的作用。

（一旦某个服务出现问题，全体受影响）

（小集群，多个组，相互隔离，互不影响）

4.4 可用性

1）隔离

  • 服务隔离：压力分流，稳定性高，物理隔离。
  • 轻重隔离：核心稳定，快慢分离，流量迁移。
  • 物理隔离：进程隔离，集群隔离，机房隔离。e.g. 机器隔离，容器隔离

2）超时

  • 设置超时：连接超时，读取超时，写入超时。e.g. 避免挤压，防止雪崩
  • 合理超时：避免过短，避免过长，动态设置。

3）限流

  • 流量限流：accept，connection，thread。
  • 资源限流：连接池，线程池。
  • 请求限流：总数，时间窗口，平滑限流。
  • 分布式限流：redis + lua，nginx + lua。
  • 接入层限流：nginx limit_req，nginx limit_conn

4)容错

  • 重试容错：简单重试，主备重试，成功率重试，快速失败。
  • 熔断容错：动态剔除，异常恢复。

5）降级

  • 调用链路：UI降级，UI异步请求降级，功能降级，读/写降级，接入层降级，应用层降级。
  • 自动降级：超时降级，统计失败降级，服务故障降级，限流降级。
  • 手动降级：功能开关，只读缓存，写异步化降级。

每个服务自身拥有比较健壮的服务能力，基本每个对外服务在代码层都能兼顾到降级、限流、容错、熔断、安全、健康检测。通过链路追踪保证，对错误能快速定位和精准定位，降低感知时间和修复时间。

6）Playbook 运维操作手册

  • 依赖的接口，必须加上熔断。
  • 当接口出现故障，自动熔断，普罗米修斯出熔断数据曲线图，并且报警。
  • 当超过N分钟，服务仍然不恢复，可以使用配置中心的推送功能，打开强制熔断，不再依赖接口。
  • 当依赖方告知服务恢复，重新关闭熔断开关，变成自动熔断状态。

7）运维层面，定期故障演练，确保流程可被正确可靠执行。

4.5 一致性

1）存储一致性

  • MySQL本地事务
  • 本地事务+消息队列
  • Binlog

2）服务一致性

  • 消息队列
  • 幂等
  • 努力送达
  • 事务补偿

4.6 微服务部署发布

1）灰度发布 – 染色

  • 在PaaS平台上选择灰度发布-染色，定义染色标签。
  • 在IaaS平台上开启“环境代理”虚拟机。
  • 镜像选择环境代理hasson-base最小配置即可。
  • 在hasson的虚拟机录入染色标签，按需配置测试接口。
  • DNS指向hasson IP，即可开始测试。

RPC meta info & contextserviceA(Red) -> serviceB -> serviceC(Red)2）灰度发布 – feature flag

  • 尽早的进入主干，可以跟灰度发布结合使用（金丝雀发布），需要使用统一的flag机制。
  • 需要清理不再需要的flags，需要开发者养成良好习惯，正确使用flags，否则容易显得很乱。

4.7 代码管理

  • 随着业务发展，基础库变更频繁，推进困难。
  • 虽然重视代码质量，但流程不够自动化，完全靠自觉。
  • 测试都积压在发版前，质量难保证，发版风险大。
  • 版本管理非常复杂，代码复用率低下，维护成本高。

通过比对分散式管理方式和集中式管理方式，显而易见，大仓库的优势在于统一版本依赖、增强协作、最大化复用代码以及减少版本不一致所引发的各种线上运营风险。1）大仓库管理代码带来的好处：

  • 统一版本控制
  • 广泛的代码共享和重用
  • 简化依赖管理，避免菱形依赖
  • 原子修改
  • 大规模重构
  • 跨团队协作
  • 灵活的团队边界和代码所有权
  • 代码可见性以及清晰的树形结构提供了隐含的团队命名空间

(引自：Google为什么要把数十亿行代码放到一个库中？)

同时，大仓库所带来的的挑战也很明显，如何保证安全性，如何防止误操作，如何减少每次checkout代码的时间和编译的时间，B站进行了如下的应对。1）目录级权限管理2）统一的构建系统Bazel

  • 支持多种开发语言。
  • 依赖分析增量编译。
  • 可按需进行扩展。

3）更高的代码质量要求

  • 统一的代码规范，便于协作。
  • 单元测试覆盖率，高质量传承。

4）注重CodeReview，鼓励沟通

  • 保证业务逻辑代码质量。
  • 信息传递，扩充人员备份。
  • buildup competence，提升集体战斗力。
  • Ownership机制，责任到人。

五、数据运营数据产生价值，该部分内容主要介绍B站日志平台、监控平台和数据平台。

5.1 日志平台

基于go自研日志平台Billions，主要由采集、传输、切分和检索四部分构成。该系统打破各个业务研发日志壁垒、规范日志格式、收敛日志接入方式，并统一传输、解析和存储，整个系统高吞吐、低时延、高可用、高可运维性。

日志采集agent同时支持服务链路日志采集，随着微服务化，一个请求联动多个微服务，当出现问题时，根据日志里记录的traceId，可快速检索出相关服务调用信息、定位故障。

5.2 监控平台

结束多个监控系统并存局面，基于prometheus搭建统一监控平台，覆盖业务层、应用层、中间件、基础设施层全面监控。开源prometheus存在单点、存储本地受限、配置维护难三个问题，B站基于联邦方式部署prometheus，并将采集到的指标远端存储至influxdb中，关联cmdb获取监控对象，界面化配置告警规则，集中处理告警事件，形成高可用、扩展强、易用监控平台。

5.3 数据平台

让监控、日志数据产生更大价值，使用AI技术对用户行为日志分析生成用户画像，实现精准推荐；根据流量数据实时计算结果，及时调整渠道投放以达到最优效果等。B站实时数据平台-saber，解决实时计算开发门槛高、作业管理难、无统一告警及工程开发师和算法工程师之间明确分工问题。saber平台支持BSQL和DAG拖拽式编程，约束输入源schema，规范输出源格式，降低flink开发门槛；同时解决流式Join、维表Join和实时特征等数据处理过程中状态、Timer、sql扩展等难点，让工程无缝对接AI平台。

六、结尾B站十年的风雨路程，是伴随着这一代人一起见证的。B站这十年，也是同这一代人一起成长的。B站的这些用户，既是传播内容的目的地，传播效果的反馈源，更是传播渠道的探寻者，传播动力的新引擎。这类人为B站的内容生态，社区生态乃至产品生态提供了源源不断的动力！
B站坚持的品质导向和价值观优先原则为其平台创造了较高的用户壁垒，以其对用户画像的精准分析，准确把握了用户的诉求，通过以用户及商业价值为导向的需求分析和管理方式，以及日渐完善的监控反馈机制，将用户最关心，最迫切的需求通过最敏捷的技术实现呈现在用户面前，不断迭代不断创新。虽然B站目前还未盈利，但他展现出来的良性生态循环，未来展现的价值还有更大的想象空间，毕竟：“一代人终将老去，但总有人正在年轻。”

本文部分配图来源于网络，内容来源于网络和B站分享内容。

Tags: ,
Comments are closed.