B站技术选型与架构

前言

了解了一下B站的技术发展历程：最开始是用PHP语言开发的，后来B站的中台逐步被Node占领，而后台技术为了更高的并发、更稳健，以及为了大数据分析，逐步向JAVA靠拢，这便导致了哔哩哔哩的技术整体较为混乱。B站早期几乎天天故障，随着团队和业务扩大，各方面的压力都增加，处处冒火。代码混乱，框架结构混乱，已经到了难以维护的地步，需要理清脉络，在这样的情况下统一技术栈是毫无疑问该做的事。最后发现重写反而是最优的解决方案。为什么是Go？归根到底，重写后台工程是哔哩哔哩统一技术栈的一次尝试，至于最后为啥选择了Go，很重要的一点在于Go能够满足哔哩哔哩平台重构优化的需求；另一点是其研发总监毛剑本身是一位Go语言的忠实布道者。

B站前端之路

B站，一开始做前后端分离的时候，也确实按照第一种方式去做的,现在还有一些页面仍然是这种模式,例如:www.bilibili.com/account/his… (可查看网页源代码)。对于不需要seo的页面来说，是一个不错的方式。前端开发完成之后，通过webpack打包出对应的js和css 上传到cdn上面，然后将webpack打包出来的 引用了对应的资源的html文件 上传到一台专门的静态机上面，然后运维配置路由 将页面流量导过去就好了。后端的同学只需要提供对应的api接口就可以。前后端分开维护，自己按照自己的节奏走，降低了页面与服务的耦合度
这种方式确实是一种很快能够进行前后端分离的方法。我们花了一段时间，在pc端使用vue 进行重构，移动端H5端 用react进行了重构。 进度很快，但是也慢慢展现出了弊端。
首屏的时候，因为他要等待资源加载完成，然后再进行渲染，会导致了首屏有白屏，如果是单个页面还好，如果是spa应用 那么 他的加载时间就会变得很长，白屏时间会很影响用户体验，再有就是由于国内的搜索公司 对于spa 应用没有很好的兼容，导致了客户端渲染会对seo非常的不友好，有seo 需求的页面就很迫切的需要服务端渲染。

（B站的首页，右边模块做了服务端渲染，左边模块没有做服务端渲染）
那么，依赖node 进行服务端渲染就被提上了日程。
选型
首先进行node 框架的选型，市面上主流框架有三种，hapi express koa ,还有一些是经过一些封装和定制的框架，例如 eggjs等
一开始我就把eggjs 排除在外了，第一因为eggjs,的功能很强大，有很多功能，多到有些根本用不着，从而导致了他会重 不轻量级，第二，eggjs对于我来说是个黑盒，如果有什么问题，我解决起来将会花费很长的时间。（但是有很多地方 我还是借鉴了eggjs的，毕竟 很强大）
然后剩下的三种框架，express的使用相对简单，文档也比较多
比较全面，所以我就选择了express(后来还是重构掉了 = =!)
然后是前端框架的选型 因为前端框架主流的有很多，ng r v 等等，我站在用的是react和vue, 他们有个优势就是可以进行前后端同构，一样的逻辑不用写两份，很棒

（同构逻辑大概如此吧）
由于之前前后端分离的时候，pc上面已经再用vue 进行了重构，所以自然，这次服务端渲染也建立在vue上面 用的是vue ssr (这也为我后面的一个想法埋下了伏笔)
首先 我们选择一个简单的页面来做打样，就用tag页吧（被神选中的孩子：www.bilibili.com/tag/3503159 ）

B站Golang技术栈分析

技术栈	技术选型	参考链接
RPC	基于grpc封装的warden框架, 已开源 https://github.com/bilibili/kratos
HTTP框架	基于gin封装的blade master框架, 已开源 同上
服务注册与发现	初期为zk, 后面逐步改为参考Spring Cloud体系Eureka自研的discovery 已开源 https://github.com/bilibili/discovery
存储	DB, redis, memcache, hbase存储一些用户kv信息和历史流水, 已封装好库 library/database/ client库已开源 https://github.com/bilibili/kratos
搜索	B站视频, 用户, 历史记录等使用es搜索, 客户端已封装在基础库中 library/database/elastic
小文件存储	毛剑个人研发的bfs, 已开源. https://www.toutiao.com/i6272104949560115714/ https://github.com/Terry-Mao/bfs
消息队列	基于kafka封装的databus
log	基于uber的zap封装的日志框架
配置及配置中心	支持从环境变量读取配置, 从toml中解析配置, 支持远程配置中心(自研, mysql存储, 本地落地,http协议, long poll, 客户端有更新事件, 类似于携程开源的Apollo)
监控	使用开源的prometheus, 框架和库(sql, redis, hbase等)中已预埋计数点和时间统计点, 同时也可以在业务逻辑中打点. library/stat/stat.go
trace	trace似乎是基于agent的方式, 使用unix domain socket进行传送, 框架和库已预埋点. library/net/trace.go
研发流程管理	TAPD, 哈哈, 有相关的tapd struct信息

其中RPC, HTTP框架, 数据访问的一些库封装, 包括生成工具, 均以kratos项目在github开源了(https://github.com/bilibili/kratos Kratos是bilibili开源的一套Go微服务框架，包含大量微服务相关框架及工具)

B站目前使用及封装的中间件的详细介绍在Gopher China 2017 B站的分享有提到原理和使用情况.
https://mp.weixin.qq.com/s/4uA6iE7HC_SAfdIATAdrrA
bfs介绍
https://www.jianshu.com/p/923917220d23
B站运维体系发展
https://myslide.cn/slides/3840

bilibili技术总监毛剑简介

毛剑，bilibili技术总监，2015年起，在 bilibili（B站）负责 UGC平台和基础架构，开发了直播弹幕开源推送服务 goim ，B站分布式存储 BFS ，引导开发了B站 cache proxy，bili twemproxy 等，对历史主站架构进行迭代和重构，之前六年在猎豹移动工作，当过MySQL DBA，做过C开发，其中开发了gopush-cluster用于猎豹移动的推送体系。喜欢应用服务性能诊断，内核研究，稳定的服务端架构演变。腾讯云最具价值专家（TVP）。负责bilibili数据平台部，拥有近十年的服务端研发经验。擅长高性能、高可用的服务端研发，熟悉Go、Java、C等语言。在B站参与了，从巨石架构到微服务的完整转型，包含微服务治理、微服务可用性设计，微服务数据一致性设计，微服务中间件，微服务监控，微服务日志收集，微服务负载均衡，和微服务RPC框架开发等。
开源业内比较有影响力的项目：

• goim https://github.com/Terry-Mao/goim 分布式IM长连接广播服务；
• bfs https://github.com/Terry-Mao/bfs 分布式小文件存储；