14.8 架构层面的技术支持（上）在线视频

这个就是我们的分布式系统

它在架构层面上

它必须要做到一些技术的

底层的技术支撑才行

就是说

如果它没有这样子的一个能力

那你还是不要拆了

因为拆完以后就收不住了

那我们来看一下它都有哪几个

我认为是比较重要的一些首先呢

它要有一个异步的一个处理框架

然后它还要有一个

很强悍的底层的通讯框架

还有自动化的部署能力

这个部署必须要是能够自动化的

还有一个就是立体化的一个监控能力

我们来分别来看一下这几点都包含些什么

异步处理框架这块

刚才Leeo老师其实也提到了一些

就是

说我们由串行就是变成了一个叫并行

并发的一个

并发一个这样子的过程

我相信大家对这个概念的话应该是

已经有了解了

所以我们现在主要是来看

如果我们要做异步处理的框架

主要是从哪几个方面来入手

首先呢

在我们的一个进程中

一般的来说会包含两大部分

就是网络的处理和ß逻辑的处理

那在网络的处理这一块的话

我们就需要把网络的处理和业务的逻辑

必须要进行解耦了才行

然后我们也知道这个就比较细节了

就是在我们的网络处理

它有很多的这种网络处理的模型

他有我们说的就是同步阻塞的模型

然后还有就是异步

就是多路复用的一个模型

这个具体因为这块的内容就特别细

我这边不会展开讲

但大家的话

课后可以自己去了解一下就说

但很明显的同步的模型不适合吗

因为我们的在

如果你用的是单进程

并且是单线程的模式

如果你用同步的话

那你就需要等那个玩家的请求

或者说其他系统请求过来

那你自己的这个CPU就空闲出来了

所以说它要采用的是一个异步的

然后呢

在逻辑处理这一块

我们怎样能够做到异步呢

目前的话

一般主要是有两个手段

我们去看下后面一个就是用协程吧

刚刚有老师提到了一个协程

这里我就不具体讲了

我这边来讲一下

就是一个状态机的一个框架

因为状态机这一块的话

在我以前做的包括逆战也好

然后包括在我们的CFM就是穿越火线

手游里面也有用到了

我之前在逆战做的这套框架

然后还有我们的CODM里面

也大量地用到了这一块

这一块的话状态机大家都很知道呢

就是那个FSM就是有限状态机

那它在

代码层面上

我想大家如果去网上搜一些代码的话

也可以看到有很多各种各样的一种实现方式了

然后也就是说大家都造了很多的轮子了

这里我呢

在比较早做逆战的时候也很早

但还是在10年的时候

也照样造了一个轮子

但是呢

因为

主要是基于说我们的业务特点

这块的话可以跟大家分享了一个就是了

我们是把状态机在这里

我们要注意的关注

就是要把业务逻辑和我们的代码逻辑

能够拆分出来

什么意思呢

就是我们希望能够做到通过配置化

然后自动的生成状态机的一个框架

而不是通过手动来去写这个代码并且呢

我们要把在状态机的各个节点

进行抽象出来

然后最后能够通过简单的调整配置

然后来实现新的一种需求

而不是纯粹的通过代码的这种方式

因为整体来说

它这种

这种生成代码

它能够降低这个维护的成本

并且它的那个沟通难度也可以大大的降低

大家可以看一下就是

就是我们所用到的

这个是用XML来配的一个状态机的

然后这边可以通过我们自己的

就是

XML来生成状态机的一个

可视化一个图形

这样子的话可以通过跟需求方

游戏的需求方就是策划

但如果是做一个外包的话

那他可能还有来自于就是整体需求方

他们所提了一个需求

所以有这样子的一个工具的话

就可以大大的

提升这个整体需求的一个

理解的一个效率之类

然后这里具体的实现细节

我就不讲了

我不知道大家在这块上有没有什么问题

或者说有希望我能够在讲一些

其他的一些额外的

不过没有的话

我就过了

这个就是我们说的异步处理框架

接下来很值得一提的就是

底层的一个通信框架

我们刚才有提到了一个就是TProxy

在我们CODM里边

底层通讯框架由两部分组成

TProxy是其中的一部分

非常非常重要的一部分

其实它还有一个叫做还有个在每台机器上

还部署了一个codm本身的一个网关系统

它用来做这个通信端TCP端的一个屏蔽

刚才leeo老师也提到一个叫tbus大家还记得吧

Tbus的话

它也是作为一个通信的一个组件

那我们用那个不管TProxy也好

还是我们的TGW也好

它存在的一个问题就是连接本身

它是在系统级的

就是如果这个进程挂掉了

那么这些连接就全部都挂了

那在网络上跑的那些包

以及到了这个进程

但是没处理的这些包那就全都丢了

那这种的话在我们线上来说

如果表现就是说如果一个进程挂了

TProxy进程挂了

就因为一些bug

或者说呢

它所在的机器挂了

那么它对用户的影响

可能就是这段时间里面的请求都丢了

那有TBus这个东西的话

它就可以把消息缓存在我们的共享内存中

只要你不是整个机器完全挂了

就是完全数据恢复不了的话

那么它就消息可以保存在

一定的时间内都很有效

所以说底层框架在里面呢

它要满足几个特性

大家可以看一下

这边就是我们有很多的服务器

服务器之间进行通信

我们这个画出来的就是一个星形的一个结构

但实际情况

我们知道星形的结构有一个大问题

就是中间节点一旦一挂

大家就全部都成了孤岛

所以说

我们刚才提到TProxy一个集群

我们目前像我们目前的CODM

目前线上跑的TProxy有两百多

两百多个进程

来共同来支撑这个两百万的一个PCU

两万PCU的时候是两百多台三百多个进程

那而且我们做过线上的一个

就是我们发现了一个TProxy一些性能的问题

然后呢

我们在用户量相对比较低的时候

我们是把这些某些的Tproxy

disable掉让它下线

然后换上新的版本

然后再把另外一拨disable掉

再换上新的版本

通过这样做到了对用户无感知

对业务无损的一个热更

如果你没有这样子一套能力的话

那么底层通信模块一旦倒塌

就相当于说你把桥拆了

跟所有车说你们都先等我把桥建好了再走

就会有大问题了

我们实际的情况就是我有很多桥

然后我可以对所有的桥进行更新换代

我们的分布式系统就要实现这样功能

所以它是作为系统之间的一个路由

然后呢

它还有作为容灾和扩容它也是一个基础

像我们刚才说的

可能一百多万的PCU

那我可能只要一百多台就够了

两百多万PCU肯定两百多台

因为是进程级别的

但是呢

我们是因为它是一个非常重要的一个组件

所以我们是在一台机器上

去布一个进程的这种方式

避免说其他的进程对他进行一下

然后它要能够做到动态过程

让它做到平行扩容

它必须有一个特点

就是它本身必须是无状态的

他本身如果是有状态的

那也就意味着说它一旦停掉以后

依赖于它上面的这些用户数据

处理流程就都会出问题

然后呢

它本身的话呢

它是可以进行平行扩容的

另外还有一个非常重要的就是

它要能够支持多种的

路由策略

这个是什么意思呢

我们来看一下

这是多层路由策略都会有哪些策略

然后在看为什么要有这些策略

目前在我们的那个

现在我们手游中会用到了几个

就是一个是取模的方式

再比如说像下那个QQ的时候

我们QQ Id都是一串整型嘛

那么它就可以按号段进行取模

那在我们这边现在很多的账号体系

它内部其实已经不再是一个

纯的数字系统了

就不是一串一串数字

但是我们还是可以通过一致性哈希方式

来进行取模

然后这边还有个就是一致性

哈希的方式

还有一个就是随机分配

还有master—slave和backup

这些我们先来看一下取模的方式

和一致性哈希的方式

这块这两块大家有有没有听说过

包括像一致性哈希

大家有没听说过

大家没有听说过是吧

好吧

大概是这样子

那我这里大概做一下

因为本来说还想看下说这个应用场景有什么区别了

那既然大家没有听说过的话

就取模的话

它有个问题就是什么呢

我们知道一个数字

当我把模固定完以后

那么它的取的余数

它就是固定的一个值

在我们的游戏设计系统里面的意思

也就是说

我现在如果是有十个玩家

他的ID分别一到十

然后我有五台机器按5取模

那么必定就是第一台机器

处理两个每台机器都处理两个玩家对吧

然后分别是第0个

然第5个

第五个在0台机器上

类似这样子的

如果我线上系统已经上线了

结果我发现我五台机器处理不过来

我要扩机器了怎么办

那这时候

不管我以什么方式来重新加机器

必定会导致用户数据的迁移

对线上系统来说

它的迁移的难度其实是非常大的

而且对有一些有状态的

处理业务来说

这种可能有时候

还会造成一些信息的丢失

所以说目前在我目前系统里面取模的系统

我们是尽量少用

只有用在什么呢

一些带强cache

我们为了减轻DB的压力

就是如果所有的请求都往DB去写的话

那么他除了对DB的IO会有压力

还有网络通信的压力

那这种情况我们很有可能

就会在本机就去做cache

或者说是额外再拉一个进程做cache

减轻DB的一个压力

那这样子的一些模块

因为它是强数据cache

我们才会取模

就说我们现在的话

它会尽量少做取模

就取模的场景一个下

然后一致性哈希

一致性哈希这个本身

它是比较复杂的了

我就说一下它的一个特性

它具体是怎么实现

实现方式也有很多种

包括虚拟环之类的

大家到时候可以课后去看一下

它的一个特性在于什么呢

也可以认为

按取模来说

但它的处理机器增加的时候

它不会导致所有的那个就是

不会导致大量用户数据的迁移

举个例子

我们刚才说取模

如果是五台

我翻倍翻成十台

那么近一半的用户数据要迁移零还是到零号

但是呢

五就要到第五号对就一半的用户迁移

那如果我不是翻倍

我是由五变成六

那就很要命了

搞不好就所有用户数据都迁移了

也就意味着如果我在cache来说

我的cache系统瞬间全部失效

对DB立马就会造成一个很大的冲击

然后呢

如果我的cache数据还没有回写DB

那么就有大量的回写操作可能

这时候系统就不可用了

然后它一致性哈希就在于说

它在不得不扩容的时候

它只有部分用户数据

要进行迁移

它的好处就在这里

当然有好处一样是有代价的

因为它数据迁移的话

还会有一些这种各种管理方式

这里我们就不展开讲了

然后接下来的话对我们分布系统来说

我们的容灾备份

然后扩容最友好的就是下面的几种

能用随机尽量用随机啥意思呢

像我们的刚才说的TProxy系统

它就是一种随机的方式

也就是说我的我们来看看上面这个

我的任何一台设备之间的通信都要经过proxy

因为它是无状态的

所以proxy是一个集群

我有一百台proxy

我随便找一台服务器就可以

它就会帮我送到指定的设备上去

那也就意味着我随便一台proxy倒了

最多也就是之前分配到上面的请求倒了

如果我的管理的好

我们升级之前

我们先做一个disable操作

告诉所有server

我已经下线了

不要给我发信息了

然后我再等一等

让它把上面的信息处理完

那这种对用户完全没有损失的

所以说随机的模块对我们的分布系统来说

它是最友好

然后呢

还有一些叫做主备的方式

也就是说

由于某些原因

我可能这套系统进程可以有多个

但是我的同时只能有一个进程在服务

这时候就叫主备

也就是说

这个进程

举个例子

比如说我要进行

我们所有的房间的机器管理

那我要知道所有机器上面的负载情况

那所有机器负载情况的话

那如果我有多个人进行做负载的这种分配

很有可能就会出现冲突

因为大家可能看到的数据是不一致的

那这种情况的话我就要求

主备至少有两台吗

但也可以一主多备

主备我可以有两台

然后呢

我会告诉你说你现在是处于主

那么我消息如果发给你

你就要进行处理

然后呢

如果你是备机

那么我消息发给你

你只更新自己的数据

但你不处理这条请求

所以说

就是反映到系统上来说它就是呢

对于更新的请求

我进行处理

但是呢

对于用户的一些申请的请求

我是不进行处理了

那备份方式呢

它就更特别了

备份的方式是什么呢

备份的方式是这样子的

就是

至少有两台机器

那由于它是备份的

所以说我每次请求只会发到主

连备我都不发

因为发到备是没有意义的

那这样子的一种它呢

跟主备相比而言

它对流量的消耗的更小

因为备机的话

在主备模式下

它备机的话也会消耗一些流量

那

什么时候我们会用主备

什么时候我们会用备份的方式呢

主备的方式主要是在于说

我主失效以后备机马上生效

并且我是要有数据的

所以备机上的数据马上就可以用

它可能会有点不一致性

但是它最终能达到一致

分布系统里面我们一般

它会有几种特性

里面我们一般会寻求它的最终一致性吗

对于备份来说

可能它并没有数据

它只有逻辑上的一个处理

所以这种情况下它就不需要

不需要说是对于那个备份

进行发送请求

这个是这里也有一个这个顺便

大家分享一下就是呢

我们在

我们的系统里面有三个模块

我们分别采用了主备和备份的模式

然后呢

我们当时预估到我们采用

就是单个进程这几个系统

我们认为撑到四百万在线是没有问题的

同时在线是没有问题的

但是呢

人算不如天算我们漏考虑的一个问题

因为我们我们认为三个都可以支撑

然后每一个进程我们都布了两套

我们都把它塞到一台机器上去了

结果发现每个进程的CPU可以处理过来

但是呢

因为三个模块都放在一台机器上

这台机在包量就爆增了

那导致的结果就是这台机器的

包量太多

然后处理包的那个进程

它扛不住了

所以我们后来得想办法

要解决这个问题

否则到时候在线冲上去了

冲不上去了怎么办