4月22日, B站部分后台源代码因为某愤怒的员工, 被上传至Github. 本文我们不讨论安全, 法律 (根据代码漏洞, 去恶意攻击或者获利是违法的! 我们工作时也要注意代码安全), 我仅从开发者的角度谈谈, 这份代码我们能学到什么? B站Golang生态建设, 代码规范, 工具建设, 技术栈选择, 对于Go在部门或公司的推广又有哪些值得借鉴?
首先必须得说, B站这份代码整体还是不错的, 不是说组件或者基础库多么的厉害, 而是从整体目录分布, 业务代码分布, API易用性, 业务代码风格, 工具的统一, 上手难度上来评价.
这里是一个小小的总结.
可以看出B站有一定的技术建设能力, 能够基于开源技术栈做封装和改进, 所选技术栈适合中小型公司业务. 技术总监毛剑水平的确挺不错, 下面会给出两篇B站在Gopher China上的分享.
详细请看下文
[TOC]
哔哩哔哩的Go微服务实战
文章上: https://mp.weixin.qq.com/s/bPFUGQDZCnt2aeIf7JI2cQ (主要讲B站从PHP, Java转为Go微服务之路)
文章下: https://mp.weixin.qq.com/s/4uA6iE7HC_SAfdIATAdrrA (主要讲B站中间件建设情况)
视频: https://www.bilibili.com/video/av29079011
以上两篇(上面后两篇)是B站公开分享的Go微服务实战, 上文讲B站的微服务演进, 下文讲B站的中间件建设.
本文中很多情况的确和本文中一致. 详细可参考这两篇文章.
通过main.go启动文件统计, 整体约329个Go服务. 有170人左右贡献过Go代码.
admin是管理后台的服务, service是提供RPC内部服务, job是处理消息队列的服务, interface目录是对外http的服务.
其中admin目录下54个, infra目录下5个基础组件服务, interface下77个, job目录下80个, service目录下113个.
整理目录结构
可以看出来B站Go后台代码管理使用的是一个大仓库的方式(从源码目录整齐度以及大仓库的README来看, 应该是这样的, 当然还有个东西叫git submodule). 这种方式有好处也有坏处.
我在前公司也有这种情况, 前人把大概某20个服务放在一个仓库中, 后续的git log简直没法看. 幸好后面大家没这么做了.
服务目录结构
cmd: 放main.go和配置文件, 作为启动入口 conf: 放配置文件对应的golang struct, 使用的是toml model: 放结构体, 比如Http参数转换用的struct, DB存储对应的struct, 各层之间传递用的struct dao: data access object, 数据库访问方法, redis, memcache访问方法, 还有一些RPC调用也放在这里面 http: 提供http服务, 主要是提供协议转换, 聚合. 逻辑还是再service层做. service: 对于后端服务来说, 该目录提供服务的实现, 对于http服务, 该目录提供http服务的实现.
所有的服务均遵守该目录结构. model层放VO, DO等, dao层用于数据层封装, 隔离本服务的领域逻辑与外部数据. http层提供协议转换. service实现具体逻辑.
比较像Java开发的模式, 可能在公司很多人不是很喜欢这样复杂的目录, 喜欢什么都放在一个目录下.
不过这样的分目录是一种比较好的实践. 各层分的清清楚楚, 一个服务从1个接口到10个接口, 都比较清晰. 对于服务改动来说,也比较好聚焦于某一层.
目录做到规范性, 服务维护, 其他人接手也容易多了. 然而大家都是有各自习惯, 每个人都喜欢偷懒, 靠规范, 靠说教来使得程序员保持目录规范, 实践证明是不可能的. 所以得靠生成工具.你给程序员生成好的代码目录和模式, 99%的人是不会去改的...能把业务逻辑实现了, 还管其他的干啥?
此份代码的300多个服务, 目录都是一致的, 不管是http服务, 还是接收消息队列的服务, 还是后台service. 同时service包下, http包下的代码流程都基本一致, rpc调用方式一致, 都是靠生成工具来实现.
技术栈 | 技术选型 | 参考链接 |
---|---|---|
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简单分析了下B站的代码风格和后台架构, 目录规范性, 工具建设均做的不错, 其中代码生成工具做的很好, http服务, 后台grpc服务,均可通过proto生成(目前now也是这样做的), 也有使用go ast进行生成的工具(大家可以参考一下).
中间件方面, 技术选型大部分为一些目前业界比较实用和流行的开源组件, 进行了一些封装, 比较适合员工上手. 同时像配置中心, 小文件存储, 为自研. 全套解决方案比较关键路径均开源.
可以看出B站有一定的技术建设能力. 技术选型比较符合中小型公司的实际情况.
对于我们而言, 可以借鉴一下, 完善生成工具, 提高API的易用性, 降低入门门槛, 根据业务选用适合组件.