共计 7590 个字符，预计需要花费 19 分钟才能阅读完成。
写在后面
本文我想写一下，一款游戏上线前须要做哪些事件，以保障我的项目上线后的稳定性。若你们公司之前没有大 DAU 游戏上线和运维教训，当初筹备上线一款新游戏，能够依照这个 RoadMap 去做或者查看一遍本人游戏的上线筹备工作。
本文不会写具体的操作，只是提供一个 RoadMap，具体如何做大家能够自行查找相干文档。
所有的工作，都会存在一个工作量和收益的衡量。一般来说，对于大部分游戏，不须要做到 100w 以上的同时在线，也不须要做到 100% 的可用性。具体工作做到哪一步，我的项目依据本人的状况衡量即可，我在文中会介绍须要重点关注的中央。
这些工作，至多须要提前 6 个月以上的工夫筹备，至多须要一个资深服务端和一个靠谱的执行服务端。
1. 游戏服务器架构
1.1 抉择适宜本人我的项目和团队的服务器架构
游戏行业的服务器架构真的是百花齐放，什么计划都有。传统的 MMO（顺水寒）和近年来常见的开房间游戏（王者光荣）的关注重点和技术计划也不一样了。
设计游戏服务器架构时，所有的技术计划都不是一个选择题，没有说哪种肯定是好的，哪种肯定是不好的（我很厌恶脱离业务背景探讨技术计划优劣的事件。）
若团队业余，人力短缺，能够不思考架构的复杂性，微服务、K8S 等技术用起来，能够做到互联网级别的程度扩大和高并发高可用。这个思路会导致写代码比较复杂，带来很大的工作量和人力需要，做的好下限很高，做的差上限很低。
然而若团队较小，教训也不多，倡议不要选特地简单的架构，尽量让架构优雅、简略。尽量不要用各种互联网的各种新技术，也没必要谋求百万级的同时在线和高级别的可用性。
这里举荐一下 Skynet，很稳。上限够高，下限也够高。
1.2 反对程度扩大的架构
从服务器架构上来看，对于次要逻辑，肯定要反对程度扩大。游戏上线后大量玩家涌入，第一个考验就是，服务器是否承载这么多玩家。
比方一款 MOBA 或者吃鸡这种游戏，它的次要逻辑是大厅和战斗，那么对于大厅和战斗就肯定要反对程度扩大。而对于登录、匹配这种非次要逻辑，是否反对程度扩大是可选项（尽管也不难）。
然而，不反对程度扩大的逻辑单点，往往就是游戏承载下限的瓶颈。找到成为承载瓶颈的单点，并且把它们革新为反对程度扩大，是晋升游戏服务器承载量的次要办法。大家能够依据本人我的项目的人力、游戏预期玩家量、游戏服务器部署形式等方面进行衡量。
程度扩大包含过程级别的，也包含线程级别的。对于一个多线程的服务器过程，也尽量不要呈现某个线程成为瓶颈。这可能会导致这个线程跑满了一个 CPU，而后阻塞住了其它线程。压测的时候能够看一下，是否存在某些机器某一个 CPU 跑满了，其它 CPU 还空着。
2. 容灾
服务器环境是简单的，不免机器、过程、网络等出现异常的状况。尽管这种几率较低，然而对于大集群来说，机器很多，环境简单，概率就不低了。
2.1 服务器机器宕机
首先思考游戏服务器机器宕机的状况，在某些状况下游戏过程被杀死也相似于这种状况。
对于这种状况，咱们要尽量保障大部分过程被杀死，不会影响到集群整体的可用性。比方，游戏中的大厅服和战斗服过程被杀死，若只会影响到此过程的玩家和战斗，并且玩家和战斗能主动地转移到可用的过程上持续游戏，那么，问题的影响范畴就会小很多。
而对于有些要害的过程，比方治理过程，这种过程数量少，且写容灾逻辑的难度更大一些，能够不做容灾。
2.2 业务容灾
为了做到某些业务节点呈现问题时，不会造成整个集群的不可用，须要在业务层面做一些容灾解决。
1）重要模块和高风险模块的解耦
比方，某些单点服务（高风险模块）若出现异常，最好只是这些服务不可用，不要影响到登录（重要模块）。
2）非重要模块能够做到敞开 / 重启
有些边缘服务，比方录像服，即便呈现问题或敞开，也要保障对业务主流程不造成阻塞影响。
3）客户端、服务端综合思考
业务的容灾须要从玩家体验的角度关注，而不只是服务端须要关注的事件。在很多游戏我的项目，客户端服务端是两个人离开写的，而思考业务容灾时须要综合思考（个别由服务端负责）。
在做业务容灾解决的时候，肯定要和客户端一起做，比方，要保障客户端在登录时，不会调用一些没有必要的接口。
4）排队零碎
倡议所有游戏都做一个简单或者简略的排队零碎，当服务端呈现问题时，或者当玩家在线量超过预期时，能够让玩家去排队，而不是登录报错或卡住无反馈。
对于可横向扩大的游戏，排队零碎不必做的太简单，因为比拟容易进步承载量，只有在呈现问题的时候启用即可；对于传统 MMO 这种分区游戏，每个区的承载量是有下限的，这种须要把排队好好做一下。排队零碎也不必搞得太简单，显示信息没必要特地精确实时，尽量不要出 Bug，参考明日之后百万阴兵排队。
2.3 第三方服务异样
游戏服务器个别都会应用一些云厂商提供的 SaaS 服务，比方最常见的数据库。
一般来说，这些服务是有容灾机制的，所以不会呈现齐全不可用。然而，DB 的异样往往会导致网络闪断，那么数据库网络连接的断线重连，以及在这种状况下如何尽量保障信息部失落且保序，就是项目组要做的事件了。
除了网络闪断，也可能有其余异常情况，比方咱们曾遇到数据库分钟级别的不可用。大家能够依据本人游戏应用的服务进行评估。
2.4 容灾测试
容灾做好了，游戏上线前要测试一遍，看看在异常情况下，集群的体现是否合乎预期。
倡议对每类服务、每类过程都测试一下不可用时游戏整个集群的体现，以及对玩家的游戏体验的影响。玩家游戏体验要从客户端的角度评估，能力确认实在环境下的游戏体验影响。
此外，在测试的过程中，对于每类故障，也要给出故障复原伎俩的倡议和演练。比方，是须要重启整个游戏服务器；还是只须要重启该过程；还是不须要做任何解决。
3. 日志
服务器日志肯定要写得尽量具体，包含日志级别、提示信息、运行状态等。
不要因为感觉日志写多了，会节约日志服务的机器老本。只有别输入齐全没有意义和价值的 Debug 日志，以及那种循环外面的海量日志，日志多多益善，不然到了线上，会呈现“日志用时方恨少”的状况。
若日志切实太多，能够在游戏压测时察看一下，个别是因为有太多的有效日志导致的。
倡议应用云厂商提供的日志服务，比方，阿里云日志服务 SLS。AWS 没有相似的服务，咱们用的 OpenSearch。
4. 压测
压测不是万能的，没有压测是万万不能的。上线前压测的目标：
- 验证架构的承载能力。我集体倡议在架构层面要能反对 100w 的 PCU。架构承载和业务承载不是一个货色，某个业务不肯定能撑持这么高的量级，然而当玩家扩散到各个玩法后，你的架构要能撑持这个量级。
- 评估各业务模块的性能体现，关注 CPU、内存、网络带宽，对于超出预期的，针对性优化。
- 依据性能数据和硬件指标，为开服资源评估提供数据撑持。
- 查看玩家在服务器高并发状况下的体现。
4.1 压测框架和压测脚本
游戏服务器不像 WEB 都是用 HTTP，所以一般来说，须要本人写一套本人游戏服务器对应的压测框架或平台，基于这套框架，能够写压测脚本。
开发完了框架，就能够基于框架写脚本了。写脚本是一个工作量比拟大的工作，最好上线测试前三个月到半年的工夫开始写。写压测脚本就是模仿玩家操作，包含登录、购买物品、降级、匹配、加好友、加帮派、进入战斗、战斗内的各种操作等等。
一般来说，大厅里的压测脚本比拟容易写，但战斗外面会麻烦一些。不过一般来说，当初常见的开房间类游戏的玩家下限是无限的，个别不必压力测试，反而是须要性能测试。传统的 MMO 简单很多。
写脚本的时候，尽量模仿玩家的实在操作。比方，测试背包，能够隔三秒取得一个物品，而后隔三秒应用一个物品。不要写成一秒钟执行 100 次获取物品和应用物品的逻辑。
4.2 压测流程
压测脚本写完了，就能够进行压测了。
对于压测承载指标，倡议依照策动 / 发行评估的同时在线乘以 3~5 倍的量级进行压测，或者间接依照 100w 同时在线去压测。一方面因为压测脚本往往和玩家线上操作有肯定的差异，另一方面游戏也可能超出预期嘛。
压测过程倡议四轮：
1. 小规模压测：把压测脚本和流程跑通，确定框架和压测脚本的正确性。
2. 分模块中规模压测：针对某个零碎 / 功能模块进行压测，能够定量地剖析某个模块的承载量。这种形式能够评估某些单点过程 / 服务的最大承载量，避免这些单点成为瓶颈。比方登录，能够剖析每秒钟最多能反对多少玩家登录，若 QPS 太低，能够去找性能瓶颈针对性的优化。
3. 大规模压测：这时候，依照承载指标（100W 同时在线）同时上线这么多玩家，而后随机或者依照法则把所有的脚本都跑起来，模仿玩家的各种操作。此外，在大规模压测期间，也能够用这个集群作为外部体验测试集群，查看玩家在服务器高并发状况下的体现。留神，对于小公司，这个压测工夫倡议管制在 2~3 天，，服务器费用的破费就像烧钱一样。
4. 线上集群压测：上线之前，针对筹备用于线上部署的集群再进行一次整体压测，依照预期的承载量去压测，同时确定线上集群部署的正确性。游戏开服之前，把数据清档。
4.3 定位瓶颈
1）架构瓶颈
压测期间，若没有达到要求，则要去寻找性能瓶颈。比方登录的时候，发现登录速度上不去了，就去找问题出在哪里。是数据库的问题，还是某个逻辑节点曾经跑满了一个 CPU 外围。
2）代码性能瓶颈
压测的时候，也能够通过 Profile 工具，去找到逻辑中的性能热点，针对性的对代码进行性能优化。
4.4 周边服务压测
除了游戏业务自身须要压测，游戏业务应用的周边业务，也要进行压测。比方账号平台、领取平台、或者本人部署的日志服务等。
若应用了第三方 SaaS 服务，有些能够本人压测一下，比方 DB；有些能够跟第三方明确本人游戏可能达到的量级，让他们做好筹备。
5. 热更
要尽量保障绝大部分代码能够反对热更或者滚动更新。
游戏上线后，不可能没有 Bug，也不可能通过重启服务器来修复 Bug。
要做好热更流程的演练和测试，对于各类模块和服务，都要测试一下热更是正确的。
6. 数据库相干
6.1 数据库选型
游戏服务器罕用的数据库包含：Mysql、Mongo、Redis。抉择适合的并且本人团队相熟的数据库。
倡议应用云厂商的 SaaS 服务，都比拟成熟了。而且不必招 DBA 了，当初好的 DBA 都在云厂商那里。
云厂商个别都会提供各种监控工具，能够找到数据库的性能问题。压测时要重点关注一下数据库的性能问题，依据教训，很多时候业务的瓶颈都是因为对数据库的使用不当造成的。
6.2 数据库的分片和扩容
不要应用单点数据库，容易成为零碎瓶颈且不容易扩大。Mongo 能够应用 Sharding 模式，Redis 能够应用集群模式。
有的数据库扩容比拟容易，有的比拟麻烦。要评估一下我的项目应用的数据库扩容的老本，若游戏胜利，数据必定越来越多，若扩容老本很高的话就比拟麻烦了。
对于大规模集群，还要留神数据库连接数的应用状况。
6.3 数据库备份和复原
要对线上环境应用的数据库设置备份策略，以作为最终的托底。常见的数据库都有对应的备份计划和策略，运维同学去配置一下即可。
倡议游戏上线前，把游戏数据库备份和复原的流程跑一遍，以保障这个流程是没有问题的。据说过业内有的游戏线上出了大问题，因无奈回档游戏间接关服下架，这就离了大谱。
7. 服务器部署
游戏上线前，就要把服务器集群部署到实在的线上环境上。这时候，就要思考哪些过程、哪些服务以何种模式调配在线上的机器上。
7.1 业务隔离
一个有游戏的分布式集群往往存在多种类型的过程，每种类型的过程又可能有一个或者 N 个，咱们假如每个过程都是多线程的，能够跑满多个 CPU 外围。
部署时的业务隔离，只有是避免不同业务过程占用了较多资源，影响了其余过程的资源使用率。如果应用 K8S 部署，能够比拟容易地做业务隔离，每个过程应用一个 Pod 即可，Pod 的调配交由 K8S 治理。若应用虚拟机部署，则须要思考哪些过程部署到同一台机器。
若集群很小，每个游戏集群承载的玩家量也不大（这种状况常见于多逻辑服游戏，每个逻辑服一个服务器集群），一个集群部署到一台高配机器上即可。这种计划比较简单。
若集群很大，倡议尽量一台机器只部署一个过程，这样尽量避免过程间的影响。若有些过程资源占用较少，也能够多个过程放到一台机器上。然而尽量保障单点过程或外围逻辑过程与其余过程之间有隔离，不要让他们被非核心逻辑影响到。
7.2 上线前的云资源筹备
游戏上线前，团队会对玩家量有一个大略的预估。基于玩家量预估以及压测时对游戏服务器的性能评估，咱们大略能预计出咱们须要多少物理资源。
在游戏上线前，肯定要依照预估玩家量 2~3 倍的状况去多申请 / 购买资源，游戏玩家数量根本稳固后，再将冗余的机器资源下线。
7.3 环境和配置查看
上线前一周，要做一次线上环境部署和配置相干的查看，这种肯定要做好 Double Check。
重点关注网络拓扑、数据库索引、配置信息、平安等。
8. 客户端相干
不要只关注服务端，肯定要晓得客户端是以什么样的形式和频率调用服务端接口的，即客户端调用服务端接口的必要性、频率和流量。
这个在平时开发模块的时候，就应该去通过合作机制或文档保障客户端调用服务端的接口的合理性。
上线之前，倡议测试和统计次要游戏主流程期间（尤其是登录）客户端对服务端接口的拜访，并且针对拜访的统计后果，进行剖析。
对于没有必要的接口调用，能够勾销。比方，咱们在登录时，尽量保障玩家不会拜访单点服务，以防止单点服务出现异常时对游戏登录的影响。
此外，对于接口的拜访频率和网络流量，也从服务端的角度去评估是否有优化的必要。
9. 运维工具和平台
游戏上线前，要把运维操作基于相干工具和平台跑通，常见的运维操作包含：
- 热更 /Hotfix
- 停服或者不停服保护
- 批改数据库或者配置信息等
对于较小的团队，倡议由公司的服务端开发工程师负责线上的运维工作，不太须要专职运维人员。这样，能够缩小沟通老本，升高事故率。然而，也要把运维工具和线上环境治理好，不要弄混了开发环境和线上环境。
当游戏服务器越来越宏大，线上环境越来越简单，业务场景越来越多，就须要组建专职运维团队了。
咱们应用的是 Ansible 治理的游戏服务器集群，应用 K8S 治理平台（账号、领取等）服务器集群。
小团队没必要搭建运维平台，把运维工具和脚本做好即可，写好执行运维操作的 CheckList，执行操作时依照 List 执行。
10. 监控和报警
部署游戏服务器集群后，要对机器和业务减少对应的监控和报警。
通过监控，咱们要对线上服务器的状况尽量理解，并且能提前发现问题，避免问题扩大化后才晓得。报警和监控相辅相成，监控到异样后，马上报警，咱们就能立即对线上问题进行解决。
无论是机器的监控还是业务的监控，监控项往往有很多，肯定要关注必要的、有价值的监控，避免有效信息和有效报警吞没了无效信息。
11. 平安
网络安全是随时都须要关注的点，倡议游戏上线前关注以下几个点：
网络通信的加密：对网络通信协定尤其是登录流程期间，肯定要做好网络通信的加密。
网络访问控制：确保本人的线上机器是外网不能拜访的，给客户端只裸露须要的 IP 和端口。运维同学倡议通过跳板机 / 堡垒机 /JumpServer 拜访线上机器。
DDoS：国外的 DDoS 攻打比较严重，需提前做好预案和筹备。国内的 DDoS 不太重大，只有某些非凡类型的游戏须要重点关注。
权限管制：做好根本的权限管制，比方开发环境 / 线上环境，游戏数据库的读写权限等。
客户端平安（防外挂）是另一个事件了，参考我的另一篇文章：《游戏开发中防外挂的那些事儿》。
对于大部分游戏类型，不倡议中小型团队过早过多思考防外挂，做一些内存和资源混同差不多就够了，倡议接入网易易盾或者腾讯 ACE。其余性价比太低，而且若游戏火了再去关注也来得及（游戏不火也就不必关注了）。
12. 线上事变的预案和演练
线上游戏出问题甚至事变是个很失常的事件，越火的游戏越容易出问题。线上出了问题当前，咱们能越快地把问题解决好，对玩家的影响就越小。
预案和演练的目标是，让咱们对线上的每个操作，都是可预期的。咱们须要晓得遇到了各种状况须要应用什么操作，以及这个操作对应的结果都是明确的。
常见的预案和演练包含：
回档：无论事变多大，最差能通过回档解决问题。这个保底，最重要的是两点：
- 数据库有定时备份，比方 Mysql 和 Mongo 是能反对按工夫点回档的，Redis 也反对针对某个工夫点定时备份。
- 因为即便基于一个工夫点，也可能会有数据不统一的问题。所以不同的数据库之间要想方法确保一致性，或者相互之间没有强耦合。
基于日志或者行为数据依据玩家某些行为进行扫档，按需获取玩家列表。
- 日志要全。
- 把日志零碎（比方 OpenSearch）用明确。
- 机器、过程异样演练，明确每台机器或者每个过程出问题时，应用什么计划解决。
- 业务异样：比方能够疾速敞开某些零碎。
13. 动静扩（缩）容
若咱们的游戏服务器架构是能反对程度扩大的，那么做动静扩容就不会太简单。
能够反对以下几种状况的动静扩容：
- 手动：当咱们发现机器不够了，能够手动减少一些机器。
- 定时：在游戏流动 / 游戏大推期间，或者其余能够预见性的游戏玩家量较大的工夫，能够主动地减少一些机器。（对于大部分游戏做到这一步就够了。）
- 自适应：依据玩家的在线量或者机器负载，动静地减少或者缩小机器。
对于筹备上线的游戏，动静扩容的游戏机较高，缩容优先级低。缩容要思考优雅退出的机制，所以开发量个别比扩容更大一些。
14. 做好经营工具和平台
业内游戏上线后，经营同学发错处分的例子有很多，大家要关注一下。比方：把人民币货币当成游戏货币发了几万个；把发给某些玩家的礼包发给了所有玩家。（这些案例在行业内都呈现过。）
这种状况不能只怪经营同学，因为人都可能犯错。咱们要把工具、平台以及工作流做的更加好用一些，缩小犯错的概率和影响范畴，常见的伎俩比方：
- 在经营工具和平台中减少二次确认框，并且提醒更加可读和敌对。
- 减少审批流，每次发放礼包或者重要操作时，须要两个人 Check。
- 减少一些保底机制，比方，不容许发 1000 以上的人民币货币。
千万不要让经营同学有能力间接操作线上，比方执行后盾命令，倡议至多做一个简略的经营工具或者平台，并且通过工作流程来管制好。
这些工作其实不是技术问题，然而倡议在游戏上线前，和各团队一起把这些策略定好，防止出现经营事变。
每个游戏、团队的状况都不一样，关注点也有一些区别。若有什么具体的问题，欢送友善交换。
这是侑虎科技第 1359 篇文章，感激作者水风供稿。欢送转发分享，未经作者受权请勿转载。如果您有任何独到的见解或者发现也欢送分割咱们，一起探讨。（QQ 群：465082844）
作者主页：https://www.zhihu.com/people/pengweiyang
再次感激水风的分享，如果您有任何独到的见解或者发现也欢送分割咱们，一起探讨。（QQ 群：465082844）
【USparkle 专栏】如果你深怀绝技，爱“搞点钻研”，乐于分享也博采众长，咱们期待你的退出，让智慧的火花碰撞交错，让常识的传递生生不息！
