关于《三国志·战略版》的若干设计和取舍
记录此文是2019年10月20日，正好是《三国志·战略版》（以下简称《三》）上线一个月，《三》稳定在国内IOS畅销榜前三（前两位是农药与和平精英），可以说是一个现象级产品。有幸作为这个项目运维方面工作的主要负责人和推进者，流水账记录一下该项目在设计、架构、所用到的产品、风险控制等方面做的工作（蹭蹭热点~），想到什么写什么，请忽略格式与前后逻辑。
- 100%使用阿里云的基础设施，基本上你常听到的阿里云产品都用上了，毕竟阿里自家产品，稳定性和支持力度也是大大的给力，点赞。使用的操作系统是Ubuntu LTS 16.04 & kernel 4.15+。
- 大量使用docker，因组件类型不一（开发的部门不一样），有些模块使用裸docker，有些子系统使用了docker+swarm，某些性能监控系统使用了k8s做容器编排，等等。并非一定要统一容器架构，灵活而且适配即可，在这方面运维层面不需要有任何的偏执。
- 大量使用均衡负载（SLB），外部和内部接口皆是，举个栗子，game server的入口，横向配置N个均衡负载入口，使用域名A记录做robin balance到这N个均衡负载上，使用多个IP做包底策略；除了上阿里云高规格抗DDOS产品外，还考虑了几个预案，不一一描述。
- 服务器端口序列规划（port list），有一个需要特别说明的地方，一定要预先进行全国各地市的存活性健康检查，有某些地市的运营商会执行某些端口段的封闭策略，会导致一定案例的玩家访问失败，提前做好全国性的各地市出发访问目标IP和端口的存活性健康检查，是非常有必要的工作。经验值是最好选用>10000的端口。
- 大量使用mongoDB、redis、rabbitMQ，底层基石。mongoDB是研发团队最熟悉也是经验最丰富的一款数据库产品，不仅用在账户、支付系统，也用在所有报表、日志、经分等层面；维护方便，搭建副本集的成本可控，其性能和稳定性也已经经过一次次的检验（特别在游戏行业），整个项目没有任何mysql+postgresql实例。
- 总数据规模>100T，每天新增数据量保守估计>5T，包括所有数据库+日志增长，随着项目在线玩家的增长，这个数字会呈线性增长。
- 使用Tengine作为统一API GATEWAY，使用goscon（ https://github.com/ejoy/goscon ）作为game server的统一接入层（加密+断线重连），game server服务器架构跑在skynet下（ https://github.com/cloudwu/skynet ）。关于游戏服务器设计上所遇到的挑战，请参考云风的blog： https://blog.codingnow.com/2019/10/sanguo.html
- 由于资源类型的不同，我们采取了资源自发（Tengine）+CDN+OSS结合的方案，用在不同的场合，避开不同的梗，满足不同的客户端特性和研发团队不同的设计理念。还是那句话，资源发布最后也一定要加IP做包底策略。
- 游戏在开张第二周突破了300W存量玩家的目标（官方公告信息），整个项目所使用的设备和硬件数量属于机密信息，整个项目我们有2个业务运维+2个DBA同学参与，满足所有日常资源增长、部署更新、监控排错、数据备份等等日常性工作，当然背后有整个运维团队的支持。
- 整体来说，东北三省玩家的网络质量相比于全国其他地区有一定的差异性，网络优化策略上可以针对这个区域做一定的调整。
- 运维和网络架构设计上，一定要知道自己要什么，不要什么，这么选择是为了解决什么问题、避免什么问题，质量永远摆在第一位，效率第二，吹牛最后。
- 你想到的混乱猴子越多，你的系统就越健壮。做好每一个预知风险的预案，到执行层面的预案。面刚是最有效的推进你的规划的方法，不妥协。
- 玩家的行为，项目运作的进展和特征，永远在你预料之外；有些你觉得很难成为故障风险点的地方，由于用户群体行为的难易预知，或者研发同学设计上的忽略，就恰恰成为了风险点；关注每一个点位、关卡的运作情况，立刻拿出响应和修正策略，快速决策，不要等。
- 日志是运维最好的朋友，在你误以为整个系统很稳定的时候，多去看看日志，你总能发现点什么新鲜奇怪的事情。
- 阿里云ECS有一种本地SSD实例，可跑到的磁盘IO峰值极高，是做数据备份的利器，先把数据落地，再慢慢upload到OSS上，可节省大量的时间。
- 一套测试环境不够，就来两套，甚至更多，多验证多踩坑。
- 除了关心系统自身所有接口的健康，还需要关心所有需要交互的第三方接口的健康，特别是登录接口和支付接口，对于玩家而言体感最重要的就是这两类接口，没有什么比登录不了游戏和充不了值更糟糕的了。
- 省流量靠压缩和调度，提升系统抗压能力靠无处不在的缓存设计。
- 在10个实例下能跑的通跑得快的方案，在1000下实例下就未必了。
- 除了自建的监控系统，我们强烈依赖阿里云监控+钉钉的机器人告警，可以适量使用回调让系统跑自愈策略，但是不宜过多。
- 统一更方便制定标准，异构可以让你从不同的角度思考问题，各有利弊。
- 软tunnel在我们整套架构设计中无处不在，它让我们在灵活与安全中寻找到了最合适的平衡点。
- 我们有一套全球多节点的openldap集群用于登录认证与权限控制，执行严格的来源认证与权限认证。一套设计严密的权限控制系统是必需品，执行高级别的安全策略不是为了给业务和研发同学找麻烦或者是找存在感，是为了促进所有方案的进化。
- 运维要用一只眼去看运维，用另外一只眼去看研发和运营，并服务他们。
- 墨菲定律，有一天早上提出了对某个业务模块的现状和担忧，到了晚上它就真的出了问题，就好像预谋好的一样。
- 《checklist》、《应对预案》、《交付文档》这种东西看起来很传统，但其实是放之四海而皆准的好东西。
- 子系统之间数据交换大量使用SRPC协议，见云风2015年的文章：https://blog.codingnow.com/2015/04/sproto_rpc.html
to be continue…
