页游运维“摸爬滚打”那些年~

《页游运维“摸爬滚打”那些年~》要点：
本文介绍了页游运维“摸爬滚打”那些年~，希望对您有用。如果有疑问，可以联系我们。

1 概述

业界运维圈子的童鞋都有这么个共识,运维真是一种苦逼的生活了,不仅繁杂多样变幻多端,整个生态链涉及网络、系统、安全、数据库等战线极长极长,关键在其中某些环节,还有Ta在不断的搞事,搞事,(神马骨干波动、神马机房被攻击、神马开发误操作删库了)实在是苦的一逼,看惯了高大上的技术,今天我们转换下眼球,唠一唠基层大众农民工曾经苦涩的那些年—运维前一代的些许无奈及改进优化之路.

2 问题及优化

相信各位盆友在搬砖的过程中,肯定也遇到让你很蓝瘦香菇而又无能为力的事吧,比如咱们即将要阐述的主题,曾经一度让小学毕业的俺很受伤,也很懵逼,甚至痛苦到怀疑人生.下面我们正经的来瞅瞅,到底是啥玩意这么犀利.

2.1 流量攻击

2.1.1 DDos攻击

ddos攻击是最让人头痛的问题,大流量的DDOS攻击,会导致机房出口被堵,严重影响游戏业务正常访问,下面是被撸的一些情形：

在两三年前,针对ddos攻击,我们只能依靠机房本身的综合实力,除此之外,没有其它好的办法,只有干瞪眼的份,好一点的机房会有一些措施,如：

• 机房本身的硬件防火墙,可以清洗一定规模的异常流量；
• 针对被经常攻击的项目,迁移至高防区域,通过一定的策略进行防护.

而现在,如果攻击者攻击的是自有项目服务器,咱们可以通过以下的方式进行尝试防护

• 更改游戏架构,把前端入口统一单独出来,然后将统一入口架到含有攻防平台的cdn厂商,利用cdn的特征隐藏
• 掉前端统一入口ip,同时前端在连接后端时进行加密处理,从而隐藏后端ip.
  通过中转,利用商业的防护平台第三方云盾,把异常流量进行清洗,如阿里云盾等.

当然,还有其它的方式,比如之前公众号提到的,安装轻量型DDos防护工具-Dshield,可能也可以起到一定的作用,但如果攻击流量规模达几十G,还是得架构、CDN分流、第三方云盾来着手.

2.2 海量开服带来运维挑战

2.2.1 更新/合服断线问题

更新合服操作方式老套,很low的在机器上面跑ssh并发脚本进行更新维护,若出现网络抖动,则更新合服操作等都会因此而中断,特别是如果刚好是进行数据库的处理时,那就比较尴尬了,将需要重新恢复数据然后再进行处理.

优化改进

使用salt替代原始的上机器跑并发脚本的方式,防止网络中断所引起的更新问题,当因网络抖动而重新连接机器时,可使用salt-run jobs 来查看任务执行情况,如：

当然salt博大精深,这边介绍的只是其中的一个点,想进一步了解的盆友,可参加官网或者本公众号文章“saltstack的取经之路”,反正俺的感觉是自从用上了salt,发现腰不酸了,腿不疼了,搬砖也更有劲了,心情瞬间舒畅了许多,幸福感飙升呀,salt你值得拥有的.

2.2.2 批量装服

经历过页游时代的小伙伴应该有同感,当页游开服量逐渐增大时,会给运维效率带来了极大的挑战,传统的一个一个服部署的方式已经不能满足日常的运维要求,如下面此款游戏的日开服量达到70+,按传统的方式部署的话,莫非这是要通宵部署的节奏,什么,要通宵?感觉整个人都不好了,反正咱内心是拒绝的.

优化改进

为满足日益严峻的运维需求,我们优化了部署方式,总体思路为：通过采集数据,达到自动推荐服务器群集的功能,从而实现批量部署.

自动推荐群组的两个基本阀值是群组字段中的“最低内存”和“最低CPU”
自动推荐群组的功能：蓝海后台系统每天凌晨零点到客户端进行一次服务器性能数据采集,而客户端数据采集核心参考如下：

通过上面信息采集与分析,从而实现如下图样的批量部署界面图,部署完几十上百个区服也只是分分钟的事,动动鼠标就可以,So easy .

2.2.3 域名重新解析

页游开服量逐渐增大,带来的必然是合服量也日常增大,如下图某游戏的日合服量将近80,如果是用A记录解析的域名,则在合服时将面临着大量域名重新解析的问题

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!