B站高性能微服务架构

大家好，我是来自bilibili的任伟。今天的分享分为三个部分内容：

• 曾经的价格体系。

• 面临的一些痛点问题。

• 高性能微服务架构在B站的落地。

B站从成立至今已经有将近八年的时间了，但是从前两年我们才开始重视整个的技术生态的演进。在整个B站的代码体系里面，我们曾经也把B站的老代码称之为全家桶。因为它是一套代码，涵盖了几乎所有bilibili里面的业务体系。我们现在的引进方向以科研为主，整个B站光是网站这一块，就有很多的分支，而整个的分支对应的域名也很多。

B站以前代码的体系从安全体系上来讲，我们进行了一系列的拆分。整个的代码仓库主要分为三个部分，一是主站的业务逻辑，还有一个是分发管理的逻辑，以及配置文件。配置文件整体的发布是一套非常繁杂的流程，它用脚本的方式把整个配置文件慢慢的生成，而这些跟本身主张的代码逻辑是隔离开来的。

我是一个工作很多年的PHP研发。在接触B站之前，我一直认为PHP的业务结构开发速度会非常快。但是了解了B站的代码就会发现，其实用PHP语言体系来做的事情非常多。就目前而言，整个B站的运维体系的工具都是由PHP来完成的。因为我们是一个视频类的网站，最重要的就是视频资源的管理，而这个调度其实一开始也是由PHP来完成的。

下面图片是一个我们的业务集群，主要分三大块，一块是面向移动端的服务集群，一个是面向PC端的服务集群，还有一个就是面向弹幕的。

整个B站曾经的体系是非常庞杂的，这么大的一个系统面临着很多问题。

代码和文档问题

就代码来说，维护的难度非常大。对于研发而言，如果我们只是关注某一块的业务逻辑，就好像管中窥豹。而且最重要的是它文档缺失。虽说一个好的编码习惯就是一个好的文档，但在业务量或整个体系比较庞大的情况下，文档和代码还是有本质区别的。

B站是基于各种网站慢慢成长起来的一个企业，所以当时在做这块的时候没有特别重视，文档一直有比较大的缺失，导致代码维护非常麻烦。

基础架构

整个的基础架构是基于织梦CMS，是一个比较流行的开源的内容管理系统。绝大多数业务逻辑我们做了一些深度的定制，导致一般研发很难搞定前面底层里的一些逻辑。

业务机会聚合在一起，不易被扩展和拆分。B站在发展到前两年的时候，让运维独立去搭一套整个B站的扩展体系并不是那么容易，B站的运行环境基本上只能通过创始人来扩展我们的负载。

运维复杂

运维复杂，因为配置也是相当复杂。后来已经不允许在运维再增加业务上的一些重写逻辑，只有让代码这边自己去处理。所以重构优化，我们已经提上了日程。

我们公司成立的基础是一个天才型选手，以前在那套系统加入了一些黑科技的东西，但同时就限制了公司团队的发展。

基于这样的一些重点问题，我们在去年开始思考怎么来解决B站目前面临的这些问题。因为B站发展速度非常快，业务的发展导致团队也会不停的增长，我们需要考虑各方面的因素。我们需要有一部分的业务要参与进来，然后梳理出来，再进行一系列架构方面的重组。

通过整个的服务体系我们可以看到，基本上以命名规则可以看到service里面的一些内部服务。对于终端和PC端，我们都是以show和interface作为作为项目向外透露接口，他们的区别就在于show是一个单纯的业务，它有紧急预案和service。但是interface会做一些数据的聚合。服务间的依赖标准主要是RPC。

介绍完大体框架之后，我们先看一下为什么当时B站会选择go语言作为技术站。我们选择go主要是因为它的执行和开发效率非常的高效。相比其他语言，优势还是挺明显的。比如我们主站的首页的动态图，每五秒钟需要获取各个分区里面的最新稿件，订单访问量是非常大的。利用go服务可以明显地感觉到移动端的访问量占整个B站的访问量已经达到了60%以上，但是他那边基本上所有的服务接口都不走CDN，直接打到元，他们那边量也是非常大，但是也没有出过什么错。

B站go语言成长非常迅速，因为它的背景是google，生态也比较丰富，支持kafka、canel、hbase这些比较流行的风格式管理框架。鉴于此，我们就选择了go语言作为我们整个公司的在技术上的统一。而且相对而言，它的调用效率要比http比较高，就是我们不走apI接口接收内部的RPC。

为什么说B站微服务在整个经营效率上会这么高呢，除了它本身语言体系上没有其他语言那么臃肿之外，我们还做了一些努力。比如在整个的对外服务的这一层上，基本上没有任何的请求可以直接打到DB，全部是缓存。我们都是通过多层缓存机制来保障的。

我觉得微服务最重要的一点就是服务隔离。在实际项目中我们也遇到很多问题。因为公共资源，导致某一个服务和资源挂钩，会拖垮相应的服务，所以说服务隔离非常重要。

选择go的另外一个重要原因就是它本身跟docker的结合有天然的优势。因为go语言的运行环境非常的精良，它不需要依赖于任何的其他的环境。所以我们动态的管理相对于其他项目来讲的，是整个公司里面最干净的docker。我们的团队也会做服务巡查。某一个服务如果出现问题都能第一时间来反馈到我们的平台里。

数据总线中间件

数据总线中间件，叫Databus。它是一个面向redis协议背靠kafka的消息中间件，它是基于内地市场放上的行为，主要目的就是用来deal。

数据库deal

我们主张直接更新缓存，并把消息推送到数据总线，然后由数据总线来更新数据库。

我们这边本身也有一些稿件的时候，比如说用户提交的一些视频，在我们这边的话会有一个基于canal的go服务，这个服务的主要作用就是在于监听数据库日志，来解析出数据库里面的更新和参数方程，来更新缓存。

我们自己魔改了twproxy，这是一个开源的想法。我们自己做了一些二次的开发。因为以前bilitw是单进程，我们这个是一个多进程的魔改负载均衡的组件。

配置中心disconf也是我们自己研发。基本上我们以自己造文字为主了。也做了一套自己的小文件存储系统BFS。这套系统跟当前比较流行的一些云存储还是很像的，它的吞吐量足够大，扩展性也足够好。

B站发展到现在，微服务还只是一个刚起步的阶段，我们也在微服务这条路上慢慢探索适合我们的一个微服务架构。我认为适合企业本身的微服务就是最好的。

我今天要分享的就这么多，谢谢！

原文地址：t.cn/RSHqFlg