B站高性能微服务架构

  1. 云栖社区>
  2. IT大咖说>
  3. 博客>
  4. 正文

B站高性能微服务架构

it大咖说 2017-07-03 16:03:03 浏览3281
展开阅读全文

ca65fc559eb0f8b971383eb285e2000c3e982dae

编辑IT大咖说阅读字数: 2672用时:8分钟

本文内容来源于任伟【沪江技术沙龙】-漫谈微服务架构实践上的主题演讲,IT大咖说为沪江技术沙龙独家视频知识分享平台。

8106ab2bdbdff83720ef52874c9503ccdc63b47c

内容摘要

Bilibili作为一个大型弹幕视频网站,在竞争日益激烈的互联网行业中,开始重视技术生态的演进,探索寻求适合企业本身的一个微服务架构。本次分享主要讲述了B站高性能微服务架构的演进。


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

  • 曾经的价格体系。 

  • 面临的一些痛点问题。 

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


曾经的价格体系


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


41b3bb367d0dd9dd625981ab65fa7281bc1cba80


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


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


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


55a8ef8352db02141b5d04ab0c6d3e8cf2e63c52


面临的一些痛点问题


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


代码和文档问题

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


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

基础架构

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


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

运维复杂

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


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

1a1bdba49747f3fb50e4749dc4d786121f526822


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


高性能微服务如何在B站落地


2e038e82cbe14c58baf18ae3ea620fd24286c07d


通过整个的服务体系我们可以看到,基本上以命名规则可以看到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,全部是缓存。我们都是通过多层缓存机制来保障的。


86231804aea5b45114b1d2162ebd4a99935b6ff2


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


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

go语言的几个基础


数据总线中间件

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

数据库deal

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


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


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


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


fe6192e5c0cd4aecd12b10f6dd90ac2de9a26f34


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


我今天要分享的就这么多,谢谢!


640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

原文地址:http://www.itdks.com/dakashuo/detail/1179

网友评论

登录后评论
0/500
评论
it大咖说
+ 关注
所属团队号: IT大咖说