毛剑:Bilibili 的 Go 服务实践(下篇)

本文是 Blibli 技术总监毛剑在GopherChina 2017大会上所做分享的下篇,包含 B 站的中间件、持续集成和交付,以及运维体系搭建。微服务的演进过程和高可用实践见上篇。


中间件


到一定的时间以后,发现我们的服务稍微稳定了,但是业务越来越大,然后业务也越来越发展,我们发现还是需要很多中间件来辅助我们跟各个对接的业务方,或者是其他的一些平台去对接.所以我们就做了一些事情——做了一个队列(这里叫databus),也做一个 canal ,然后做了一些数据刷新、同步,又基于 twitter的 twemproxy 改了一个多线程的版本,然后还做了一个对象存储,此外还做了一个配置中心,最后是基于 Google 的 dapper 做了一个 APM 的链路追踪。

接下来我来讲一下各个中间件都是什么场景使用的。

Databus

如图10所示。Databus基于 Kafka 。当时我们用 Kafka 做了一些简单的业务,但是 SDK 很多 bug,而且各个语言实现也不一样。后来我们想了一个办法,做了一个 redis 的协议,用的时候相当于我先批量存一批过去,用一个长轮询的方式,然后如果它 30 秒没有返回数据,那么下次再来重拉一次。还有就是像 Kafka 不太好做健全,我们又做了一个健全,就是把 Kafka 整个地址网段都屏蔽掉,然后我们的 Databus 再对外。此外会加一些简单的授权,避免一些核心的数据泄露。

我们早期用 Databus 和 Canal 回放数据库的 binlog,然后把 Databus 跟 Canal 打通。我们可以把稿件的核心数据或者一些技术,同步给我们的搜索、大数据,甚至一些微服务的,包括我们有一些业务,db 跟 cache 要保持强一致的话,我们都是通过 binlog 来回放的。所以我们大量使用 Databus 和 Canal 的这么一个组合。


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

图10

图11所示场景就是我们用 Databus 来加上刚刚那两个 rpc 来支持广播,来做我们服务的 logic cache 的清理。我们有一些业务可能有多个副本,L1、L2这种, cache 可能不太好清,而且我们后续上了 docker ,发现这个IP也是变的,server 非常多,cache 清除更加困难,所以就用这样一个 Job 加一个广播再加 da tabus 订阅的方式来清理,保证整个 cache 的一致。


0?wx_fmt=png

图11


配置中心

后来我们又做了配置中心,如图12。早期也是通过配置文件,后来实在太痛苦了。我们参考了很多家,360、淘宝,后来用最了简单的方法,把配置文件存到 mysql 里面,我们认为 mysql 足够可靠而且可以做主从。然后把开发的配置中心,配置中心本身内存有配置文件的缓存,服务所在的机器的磁盘也有一个缓存,所以它整个可用性很高,配置丢失的可能性较小。我们用一个简单的方式来注册,就是请求一个接口带一个版本号。连一个 App ID,如果它没有配置中心就挂起,如果有配置中心就下发。这样是非常方便的,而且写起来也非常简单,因为语言比较多,用http接口是最简单的。

0?wx_fmt=png

图12

后面我们到这个阶段以后发现什么问题呢?定位问题,就是查日志,每次一查问题,比如说看到这个页面炸了。每次客服也好、产品也好,找不到的时候,或者老板看到,就认为你是你炸的,其实后面一查发现是别人炸的。我们也参考谷歌的那个,做了一个链路追踪。其实非常简单,就是一个采集日志,把日志储存到上面,然后提供一个API,再做一个好看的界面就可以了。我们通过服务搜集,通过 Kafka 排队。然后一个可以储存到 HBase 里面,就是完整的链路信息,再用 ES 做一些搜索,然后提供一些 API,最终做了一个 APM 的 UI,如图13,方便查看一些问题和使用。


0?wx_fmt=png

图13

现在是什么定位问题呢?首先我先搜这个服务是什么名字,获取 title ,然后选一个时间段,就能判断这个时间段内的请求数,和我的耗时的图。比如我大部分耗时在100毫秒以上,那就有问题,我需要去定位。下面是一个ID列表,可以来查这个问题。

0?wx_fmt=png

图14

图14中是我点击一个ID以后,这时候我就能看到,这个最长的条就是某一个接口,这个是收藏夹的接口超时了。或者我们发现,它从经过网络传输的时候,包括我们链路设备,应该是交换机上面的一个模块,也用的那种小厂商的,不是买的华为的,因为华为的特别贵。然后发现出问题了,后来我们很老实的全部换成华为的模块了。那通过链路追踪可以找到很多上游和下游链路上的问题,甚至能找到你们通信网络上的问题。我们把所有的核心库常用的网络资源都注入代码里面的方式去打点,然后搜集。其实到这个阶段,我们要优化一个代码非常简单,我只要搜一个API,我看很慢,然后看到底哪里慢,再去推业务方优化。

还有一个好处,我可以看这个服务到底依赖的下游是谁,我的依赖经常梳理的,到最后我们发现,只要有一个依赖就可以把整个总站的所有依赖情况自动划出来,我做到这一步以后,发现通过图15,我们目前做到这个,就是把全站的依赖划出来,是不是有一些不合理的地方,其实再下面是不是把一些流量的密集程度做进去,这个线条是有粗细的,我可以找到我的服务热点,然后去做优化。

0?wx_fmt=png

图15

通过15,我们找到几个问题,第一我发现我们核心热点是帐号服务和稿件服务。发现这个服务之前,我们这个图(图16)没有画全,其实还有很多的微服务。我们当时在想,如果你依赖超过了十个服务,每个服务有50个节点,要建500个。所以我们在微服务之间还会做一些 Gateway。相当于是一个 Gateway,这样可以减少最顶层的人依赖,不是平级的依赖,而是有一些层级以来。


0?wx_fmt=png

图16

然后我们还发现热点怎么解决,回到刚才说的那个 Gateway,我后来发现,当我们的 Gateway 大家都依赖,然后我再扩容它的时候,其实加一个节点带来的性能提升已经非常小了。假设我再扩十个节点,但是它的成本已经非常高了。后来我们参考了 facebook 它当时提出的概念,也包括像微博,像腾讯提的部署方法,我们就会把这种核心的服务做隔离。

我举个例子,比如我们的移动端,是不是把它所有依赖服务打包,然后部署。那么再把其他的一些重要的类似的做一些拆分,这样就避免一个 gateway ,比如我一百个节点,甚至一千个节点,然后去做一个隔离。  

导致每次测出来不知道是环境的问题,还是我们的功能 bug ,我每次看到这个测试,都说这个 bug 应该是环境导致的,一上线就挂了。首先我们是做了这些几件事,首先是版本管理,所有的都是语义化,都是有大的语义。都是带一些功能的增加,但是不破坏功兼容性就用这个版本,那么还有大版本。

那么通过这种方式的话,比如我是一个服务提供者,你是一个消费者,有一个概念,就是让消费者做测试,就是我是提供者,你是消费者,如果你觉得我不可靠,或者不兼容了,你去提供这个测试代码,或者我们测试的同事提供测试代码,然后把这个做到集成环境里面去。我随着这个版本越来越多,肯定要考虑兼容的,我们更多的是共存的方式,就是V1、V2共同存在,当V1流量没有人用了,再把V1下掉,最后大家都用V2。其实我们走的是共存的路线。

再讲一下代码环节,如图17。其实就是功能分支,假设我要提测,我就会发一个,非常方便。它会回复一个 +1 就会有一个点赞的手势,如果超过两三个,大家都觉得OK了就可以定了。其实这有一个好处,就是你的代码发给别人看,别人看了虽然这个业务不是你做的,但是大家都可以熟悉对方做的事情。还有一个好处就是甚至我经常在看我们团队的一些代码,有时候我甚至会想,有一些代码我不一定写的这么好,我可以学到很多东西。也是一个相互学习的过程。

0?wx_fmt=png

图17


持续集成和交付


最后就是维护测试和集成环境。主要做了下面一些事情。

  • 版本管理(语义化)

  • 分支管理(gitlab+mr review)

  • 环境管理(集成环境)

  • 测试(单元测试+服务测试)

  • 发布(冒烟、灰度、蓝绿)

使用语义化的版本管理(Major.minor.patch),如图18所示。

  • MAJOR:改变意味着其中包含不向后兼容的修改;

  • MINOR:改变意味着有新功能的增加,但应该是向后兼容的;

  • PATCH:改变代表对已有功能的 bug 修复

因此是使用对方服务时候,需要明确有微服务或者是 API 的版本管理,基于此我们知道是否是兼容的。

0?wx_fmt=png

图18

这个构建的话,构建一个 docker,那么真正的这个环境是上面的集成测试环境,我们是通过运营,比如 FAT1 ,FAT2 ,然后测试只要把这个服务的运营可以和上面的集成环境同时连上,而不会破坏测试环境,不会破坏兼容性的代码合进去,导致整个测试环境毁掉。一旦服务环境测试稳定以后,再做一个集成环境部署。最终合并到集成环境。所以我们就做了一个平台,如图19所示。就是包括提交分发,到构建,到测试,到集成。后来还做了一些像交付。比如说线上的一些10%、20%的操作。   

0?wx_fmt=png

图19

运维体系


最后提一下运维体系。如果没有一些运维周边的支撑,微服务是没法落地的。图20-1是我们的 PaaS 平台,这个是非常方便我们扩容,只要接入到这个平台,通过这个平台以后我们可以很方便的看这个容器内监控的一些状态,包括CPU,网络等,如图20-2。然后当我们出现一些比较诡异的BAG,我们查不到,但是我这个进程夯住了怎么办?还要接一个外部的,让我可以连进去。

0?wx_fmt=png

图20-1

0?wx_fmt=png

图20-2

最后再讲一下我们日志是怎么搜集的。其实我们提出两个Agent的概念,或者我们还是想做一个类似于系统Agent,来处理所有运维的指令。第二个Agent是采集数据。我们是把它放到同一个里面,我们的业务代码就可以打给它,然后我们的分发系统,也叫一个分捡系统,它分捡就可以把日志一部分给到Nas,一部分给ES,后来是通过 kibana 查看我们的日志。如图21。

0?wx_fmt=png

图21

到这个阶段以后有了电子监控,但是还是差一些监控系统,后来我又想了一下,整个运维监控体系应该怎么做呢?其实我在另外一个会议上分享过,我思考过运维监控怎么做。如图21。首先最底层是 Zabbix ,目前可用的Zabbix 未必是最佳选择。刚刚我们说有链路监控的,还有查看日志的,其实我们还查看一些异常。指标监控,我们开发了一个叫Traceon的一个系统,这个系统目前还在开发阶段,会采集一些重要的指标。包括我们有一次去携程看,他们可能会采集某一个地区订单量,当低于多少的时候会报警,类似一些重要指标的监控。

0?wx_fmt=png

图21

还有一些异常的搜集,比如说我可能有一些超时,有熔断,我不看日志就不知道了。那么它顶层有运维的同事看到这个系统,比如最近的变更是什么,然后它触发了报警,有没有人认领这个报警,如果没有人认领,它会不断的升级报警。

其实还有一块,我们这个层面解决了很多服务端的问题,还有一个端的监控,端的监控指的是我们移动端跟外部端的监控,因为有时候网络连不上,可能有DNS污染,甚至还有流量的劫持等等,这时候通过我们客户端的买点上报来做一些端上的监控。比如说我们发现某一个区域突然大规模的连不上,那么这个上报可以通过客户端想办法报上来的,这时候我们可以做一些处理,可以把我们的CDN,是不是把流量切到别的地方去。

这是一个报警代码,我们在那个墙上放很大的电视,放这种变更等等方便他们及时的处理。其实整个微服务需要各个环节各个部门,包括运维,测试,包括开发也好,集体去构思它到底整体是怎么运作起来的。谢谢大家!


提问精选


Q:非常感谢毛老师的精彩分享,有一个问题,就是你刚才说的Databus,我想问一下,如果我要做消息的重复消费,我应该怎么处理呢?

A:其实我们做完这个东西,跟业务方扯皮了很长时间,我们是这么说的,尽可能的让他,我们都是使用至少一次消费,我们会跟业务方提一些要求。


Q:那么关于你刚才说的gateway这一块,你是不是实现了服务编排?

A:对,比如我一个接口要依赖其中四五个服务,但是目前是比较矬的,现在我们是人工写代码,这个我研究了一段时间,有一个叫什么QL查询语句,把它动态发音成那个依赖的代码自己去执行,但是这个也是比较大的工作量,我们目前还是人工去组装这些服务,并且人工处理应该怎么降级。


Q:然后版本管理这一块,你们已经强制指定了版本了,那么调用方在调用服务的时候是不是强制指定版本的?

A:比如RPC的话,有方面名会带一些版本信息,然后通过HD接口的时候,有会带一些版本信息。  

 

Q:网关会加一些功能吗?比如健全,降级等等,如果你们想把这个东西做完善,是否有考虑用GO重构这个东西?

A:其实我们只是做了简单的限流,我们gateway用GO写的,它实现的是健全,限流都是通过服务治理的管理界面去出发的。这个其实GO写的,包括像一些开关打开等等都是通过GO来实现的。


Q:那因为我们系统里面也有用到一些内部的网关,我们用的方法,微服务也是通过DK去同步它,然后在网关那里有一个插件,可以在那里面动态的改一些规则,包括一些健全,或者是限流的一些东西,就是通过Agents做这个东西也差不多,但是通过GO来做的话,有没有在性能上进行一些比较呢?

A:首先我不太建议在Agents层面做。因为你有没有考虑过假设我的SOB有一天突然,假设我的核心机房全部故障,我想立马切第三方,比如阿里云,腾讯云这种,如果你的Agents这一层非常重,其实不利于你的迁移的。所以我们把gateway的绝大多数功能做在GO的服务里面的。这样我想怎么迁就怎么迁。也就是对于开发来说,他只需要关注最简单的,他的Agents的稳定性,他只要帮助接入层没有问题,对我们业务开发来说,其实就把所有的逻辑闭环在开发层面去解决。在我们自己gateway里面解决所有的事情。其实性能应该是OK的。


Q:你好,毛老师,我想问一下你们现在应用测试环境都是用的多壳的DB这种有容器化吗?

A:DB没有容器化。


Q:那你的建议DB这种要不要在容器化呢,在测试环境里面?

A:其实我们DB是这样做的,确实服务测试环境和集成环境的DB都是同一个。当然也有一些场景是两个,但是因为DB的集成非常困难,比如你改一个字它不兼容了,这个是没办法的。所以我们尽可能的加测的。只增加属性,我们DB其实更多的是兼容性的修改,这样的话会好一些。当然数据避免脏的话,如果你两套DB,那我的集成环境可以用一套DB。

 



展开阅读全文

没有更多推荐了,返回首页