阿里游戏高可用架构设计实践

Posted 2022-01-19 qilin20

 

 

    今天读了李云华老师写的《阿里游戏高可用架构设计实践 》，有一些感受想分享一下。

    印象很深的一句话那就是他最开始说的“把韵味的锅让研发去背！”也就是说，高可用的系统是设计出来的，不是靠运维保障出来的！ 他提到出现问题人们的思考顺序为：首先想到的是不是运维太LOW了，比如说硬件质量太差，为什么这个月机柜也坏、交换机也坏，是不是到电脑城买个二手货放里面了？第二想到的是不是运气不好，之前一个月、两个月才遇到一次，这个月遇到了4次，是不是你们没有在机房烧香？第三个是不是测试不足，为什么这些Bug测试阶段不能发现，线上才发现？还有运维经验不足，比如交换机出现故障，有的人以为很简单，倒换一下就行了。甚至有的同学提到了流程不完善，说整个流程中有很多可以改进的地方。比如说故障发生之后，响应机制是不是不够顺畅，故障发生之后一堆人，包括研发、测试、运维手忙脚乱，是不是要定一个全流程的处理方案，指定一堆的责任人？然而最主要的问题还是系统设计方案的问题。解决方案有下面就几个方式：高可用目标-传统方法：确定这个方向之后我们就需要定一个目标，首先确定一个目标。高可用其实都是指几个9，5个9的话可能就是电信级或者金融级的，互联网大部分是3个9到4个9。 但是有一个缺点，除了技术人员，其他同学不是很好理解，他们没有办法将4个9或者5个9转换成直观的理解。所以，我们当时在定项目目标的时候并没有这样去定。 高可用目标-面向业务：我们最终确定的目标跟几个9的目标有一个比较大的区别，几个9的目标主要是从系统的角度去考虑的，就是说这个系统的可靠性是几个9。 这个目标的优点：1、聚焦业务。2、容易分解。目标本身就是我们的工作方向，首先要定位问题，怎么定位问题？我们就可以想一个办法，其次是恢复业务，第三是故障的频率不能太高；3、容易衡量。我们后来再做方案的时候，很多方案只要拿这个标准一套，基本上就能够判断这个方案是否可行。整个目标最后折算下来，对应的差不多是4个9左右，比4个9高一点点。 高可用整体架构整体架构一共分为四层：用户层、网络层、服务层、运维层。整个架构其实跟目标是一样的，我们是面向整个业务的，没有说哪个系统应该具备几个9的高可用，而是站在整个业务的全流程来看假设要达到目标，每一个应该怎么去做。每一层都需要做一些应对的方案，才能达到目标。接下来我就详细给大家介绍一下，每一个方案的基本思路和做法。 

        接下来就是架构解耦了：业务分离下图是原来的架构，这个系统把所有的功能都包含了，比如说登录、注册、参数下发、消息、日志、更新。其实对于玩家来玩游戏来说，真正强相关的只有登录注册和参数下发，消息和日志、更新其实并不是玩家玩游戏必须具备或者强相关的。所以，业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把两个系统之间通过接口调用，互相访问。这样做的好处，假设非核心业务系统出现故障，它并不影响核心业务系统，因为它们之间是通过接口调用的，并不共享相同的资源。

 服务中心服务中心类似于DNS，是实现整个内部系统之间服务调用时候的调度功能，服务中心是一个类似于服务的名字系统。业务降级整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。这个时候，接口是可以访问的，但是响应时间特别慢，核心系统就有点被拖慢。那么，在这种比较极端的情况下，我们可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，这个停掉并不是把程序停掉，而是说把其中的一个接口或者url停掉，核心系统去访问的时候就得到一个500或者503错误。

服务中心

服务中心类似于DNS，是实现整个内部系统之间服务调用时候的调度功能，服务中心是一个类似于服务的名字系统。业务降级

整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。这个时候，接口是可以访问的，但是响应时间特别慢，核心系统就有点被拖慢。那么，在这种比较极端的情况下，我们可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，这个停掉并不是把程序停掉，而是说把其中的一个接口或者url停掉，核心系统去访问的时候就得到一个500或者503错误。

360度监控：立体化、自动化以及可视化。

 

总结：研发、测试、运维，大家一起来设计高可用性。