&>&&>&&>&&>&游戏架构设计与策划基础.pdf
游戏架构设计与策划基础.pdf
上传大小：27.25MB
游戏架构设计与策划基础.pdf
嵌到我的页面
<input type="text" value="">
综合评分：4.4（152位用户评分）
收藏（(11)）
所需积分：0
下载次数：2129
审核通过送C币
创建者：qq_
创建者：tangxiaoyin
创建者：huangyueranbbc
课程推荐相关知识库
上传者其他资源上传者专辑
课程资源热门标签
VIP会员动态
android服务器底层网络模块的设计方法
所需积分：0
剩余积分：720
您当前C币：0
可兑换下载积分：0
兑换下载分：
兑换失败，您当前C币不够，请先充值C币
消耗C币：0
你当前的下载分为234。
游戏架构设计与策划基础.pdf
会员到期时间：
剩余下载次数：
你还不是VIP会员
开通VIP会员权限，免积分下载
你下载资源过于频繁，请输入验证码
你下载资源过于频繁，请输入验证码
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
若举报审核通过，可奖励20下载分
被举报人：
woshixiaogutou3
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：顶尖游戏设计师陈星汉：虚拟世界的架构观
顶尖游戏设计师陈星汉：虚拟世界的架构观
17173 新闻导语
陈星汉，1981年生人，出生于上海，是知名华人游戏设计师。代表作包括《云》、《流》、《花》、《旅途》，获全球多项大奖。目前他是游戏公司thatgamecompany的联合创始人。
陈星汉，1981年生人，出生于上海，是知名华人游戏设计师。1999年，陈星汉考入上海交通大学计算机系试点班，并获得了学士学位。2003年，陈星汉申请并进入到南加州大学电影艺术学院的互动媒体专业，并获得了硕士学位。他的代表作包括《云》、《流》、《花》、《旅途》，获全球多项大奖。目前他是游戏公司thatgamecompany的联合创始人。
因其在游戏营造出的“恬静舒适”意境，一些媒体称他为“禅派”（Zen genre）游戏的倡导者。
最近，陈星汉在国内一次分享交流会上，回顾了他的游戏“旅途”、创作心得。非常值得内容产业从事者一读。
以下是陈星汉口述整理：
最大的梦想：让游戏设计师成为全社会尊重的职业
我从1990年开始打游戏，一直打到2006年研究生毕业。我小时候的朋友都是通过打游戏认识的，游戏陪伴我一起长大，是我生命中非常重要的部分。游戏这个行业从1990年到现在变化非常大，早期它还是非常小众的行业，但是现在因为移动平台的出现，很多人都在打游戏，可以说游戏行业是蒸蒸日上的。但与此同时，和我一起打游戏的人已经长大了。我问他们，现在你还会不会长时间地玩游戏？他们说几乎不可能，因为都没时间玩。当时我觉得我人生中很重要的一部分东西好象被成年人遗弃在了背后。我非常爱游戏，我很希望游戏是一个能被成年人接受的东西。
小的时候会有人给我读一些童话故事，这种故事对小孩来说有意思，但是对成年人来说就是很无趣的故事。其实童话故事也可以让成年人和小孩一起有兴趣的内容，不管是电影、动画，比如美国的很多动画片都是成年和孩子一起有兴趣的，为什么游戏就只能给小孩子玩呢？到后来游戏蒸蒸日上，很多朋友都开始玩《愤怒的小鸟》，但是这样的未来不是我想看到的未来，这样的游戏也不是成年人真正会重视的游戏，我觉得游戏行业需要更上一层楼，才能真正成为成熟伟大的行业。现在一说到连续玩四个小时的游戏，大家基本上都会说没有时间；但是他们会有时间读四小时书，或者看一部电影。之所以我的朋友还在读书、看电影，是因为那些书籍和电影给他们生活带来一些真正意义上的光彩。早期的时候一说起游戏，都觉得是毒害青少年；现在人们说起游戏行业，都会说这行很赚钱。但是人们从心底里尊重你吗？我觉得不是这样，我是希望在退休之前，如果你跟别人说你是游戏设计师，就像今天说你是建筑师、电影导演、作曲家或者说你是医生一样，会得到全社会尊重的职业。这是我最大的梦想。
灵感与启发：我要创作什么类型的游戏、创办什么样的公司
陈星汉的《云》奠定了他的设计理念
一开始，其实我也不知道将来要做游戏，直到读研究生的时候才确定。我那时候在南加州大学的电影学院读一个三年制的研究生项目，在读书期间我开发了一个游戏《云》。这个游戏很有意思，是一个学校的奖学金基金项目。当时《GTA3》上市了，里面有很多暴力的情节和行为；又正好发生了好几起枪击案，就有舆论说游戏毒害青少年，让他们变得暴力。因为老师都非常鼓励我们去推动游戏的边界，我们就想能不能开发一个游戏，跟《GTA》相反的、没有暴力的游戏，玩了以后没有焦躁的感觉。最后的灵感来自于小时候，那时候我经常想象自己在天上飞翔，想象天上的云是各种各样的形状，因此就做了一个游戏：一个小孩在医院里不能出去和别人玩，他只能朝窗外看，看到了蓝天白云，想象自己在蓝天上飞行，飞过白云的时候可以拖拽白云，可以用它做各种形状，也可以使云产生降雨。
当时的游戏是非常粗糙的，还没有Unity，我们只能自己写引擎。但是很让我们吃惊的是，游戏上线三个月，就有全世界超过40万的下载量。游戏后来出现被很多媒体报道，我们开始收到各种各样的信件。让我印象很深刻的是，有一个玩家说参与制作的人都是美丽的人。我从小到达没有人跟我说我长得漂亮（笑），所以这对我的震撼非常大。
其实在开发这款游戏之前，还开发了另外两款得过很多奖的独立游戏，但是从来没有这么强烈的用户反馈。我苦思冥想：这个游戏到底好在什么地方？我意识到从情感角度来说，这个游戏和传统主机游戏完全不一样，它给人是一种治愈的感觉。人饿了要吃饭，渴了要喝水，但是如果人在情感上有饥渴怎么办？古代的时候，那些原始人会绕着篝火跳舞，这就是为了获得情感上的安全感。到后来古罗马把自然都征服了，自然界的生物都成了牲畜，也没有战争，这时候人们反而缺乏了自然界带来的危机感，他们就造出了斗兽场。
所以情感需求是可以通过不同的媒体来得到满足的。比如我跟谁分手了以后很沮丧，我可以看一本帮助你励志、治愈的书，我也可以看一场非常浪漫的电影，可以和部分一起出去打球，都可以帮助我治愈我情感上的需求。比如电影是各种媒体中间最年轻的媒体，也是最像游戏的媒体。通过一百多年的发展，电影媒体的市场已经被细分到非常精确，你可以看一下电影市场细分，他们都是按照情感来分的，比如喜剧，你一看就知道它给你带来什么情感。比如恐怖片，一听就知道是什么样的类型，所以看电影之前，你就已经想好你要看什么样的感觉。
电影市场的细分，不仅是按照类型发展，还是按照时间来分，美国是按照月。比如在五六月是学生放暑假，动作冒险片就特别火，因为年轻人就很喜欢很刺激的感觉，所以到夏天大家都有时间看电影，这个市场就开始增长。到十月份恐怖片市场开始增长，因为美国有万圣节，那时候大家都喜欢被吓一下。到了圣诞节，戏剧就开始增长了，这主要是针对成年人，圣诞节一家人坐在一起看电影。但是如果你看一下游戏的类别细分，根本就是和情感没有什么直接关系的，最早期所有游戏都叫街机游戏；慢慢他们开使用科技分析，比如第一人称、第三人称、多人射击游戏、大型多人射击游戏，这些射击游戏并没有体现多少情感。其实同样一个射击游戏是可以用不同情感的，我觉得游戏市场类型的分配是有问题的。如果我用情感来分所有游戏的话，可以看到绝大多数游戏，战略游戏也好，或者早期街机游戏，还是现在的手游，其实主要是以动作、冒险为情感。
我在2006年的时候，就感觉没有成年人喜欢的情感类型的游戏，所以我参考了一下电影工业，一开始的时候他们的电影类型也是跟游戏行业一样。刚开始的时候他们拍什么呢？两个人打拳击，或者很漂亮的酒庄，或者一列火车冲进火车站。到后来电影越来越发展，这时候他们才开始尝试更加复杂的情感。
慢慢地，电影行业就发展成不管你是什么性别，什么年龄，从什么国家来的，你现在是什么心情状态，你总有一部电影是可以看的。电影行业变得老少皆宜，而且它的情感深度和广度是覆盖整个社会年龄层的，所以我们可能会问你是不是玩家，但是我们从来不会问你是不是听音乐的，或者是读书的，因为大家多多少少都要听一些音乐或者读一些书，游戏行业开始从这几年有这个征兆，也许以后可能不会再有人问你是不是一个玩家。所以我们为了让别人尊重，我们必须要尊重历史，我当时就希望能够让游戏行业有更多新的内容，它是老少皆宜的，是可以加深已知情感深度的游戏，然后我创办了ThatGame Company。我希望游戏要老少皆宜，能加深已知情感的深度和广度。创办公司当然是希望赚钱，但我更希望能对行业有帮助。
支持键盘 ← 和 → 分页
发布此文仅为传递信息，不代表认同其观点或证实其描述。
类型：大型RPG
特征：挂机
类型：大型RPG
类型：大型RPG
特征：国战
热门新闻排行
游戏万花筒阿里游戏高可用架构设计实践 - 推酷
阿里游戏高可用架构设计实践
本文根据〖GOPS2016 全球运维大会o深圳站〗李运华演讲整理而成，编辑同学为陈才@腾讯。
欢迎关注“高效运维(微信ID：greatops)”公众号，以抢先赏阅干货满满的各种原创文章。
十余年软件设计开发经验，经历了电信行业和移动互联网行业，曾就职于华为和UCWEB，先后担任软件开发工程师、系统分析师、架构师、技术leader等角色；
现担任阿里巴巴移动事业群（原UCWEB）资深软件工程师，带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责。
技术上专注于开源技术、系统分析、架构设计，对互联网技术的特点和发展趋势有较深入的研究和理解。先后负责过游戏接入高可用项目、飞鸽事件发布订阅系统、交易平台系统解耦项目，对于系统解耦、高性能、高可用架构有丰富的经验。
大家下午好！我是来自阿里游戏的李运华，每次在做自我介绍的时候都会面临一个尴尬，包括今天也是，听到我名字的人看了我的样子之后，第一句话就是：“哇，你这么年轻！”。
但其实我已经在行业做了十多年，大家可以怀疑我的年龄，但不用担心我的实力。
今天演讲的题目是《阿里游戏高可用的架构设计实践》，演讲题目比较长，也很常见，估计大家听了没什么印象，我从整个演讲的内容中提炼出一句话，相信更加容易记住： 把运维的锅让研发去背 ！也就是说，高可用的系统是设计出来的，不是靠运维保障出来的！
今天演讲的内容没有云计算，也没有大数据这些高大上的东西，但是无论是什么业务、什么行业，其实都可以借鉴，也可以比较容易落地实施。
项目启动的背景其实跟这个图非常吻合，叫疲于奔命的运维，非常形象化地展示了当时运维的状态。
我们有一个月发生4次比较大的故障，包括机柜断电、交换机断机、服务器段机、程序Bug，这些故障影响的时间短的可能半个小时，长的可能就一个小时、两个小时。
对于游戏接入来说，如果游戏不能登录的话，很多玩家就打电话投诉游戏厂商或者直接打电话到阿里游戏爆粗口，影响是很大的。
为什么说运维背了很大一个锅呢？
因为一听到说是机柜断电，有的研发同学就长出一口气，“这个是机柜断电导致的，好象跟这个研发设计方案没有太大关系。”
所以，当时除了程序Bug以外，可能其他都是运维背黑锅了。
分析-运维太LOW？
出了这么大的问题，肯定要分析以及给出后面的应对解决方案。于是我们就成立了一个工作小组，小组第一个问题就是 怎么去分析这些问题背后真正的原因？
首先想到的是不是运维太LOW了，比如说硬件质量太差，为什么这个月机柜也坏、交换机也坏，是不是到电脑城买个二手货放里面了？
第二想到的是不是运气不好，之前一个月、两个月才遇到一次，这个月遇到了4次，是不是你们没有在机房烧香？
第三个是不是测试不足，为什么这些Bug测试阶段不能发现，线上才发现？还有运维经验不足，比如交换机出现故障，有的人以为很简单，倒换一下就行了。
甚至有的同学提到了流程不完善，说整个流程中有很多可以改进的地方。 比如说故障发生之后，响应机制是不是不够顺畅，故障发生之后一堆人，包括研发、测试、运维手忙脚乱，是不是要定一个全流程的处理方案，指定一堆的责任人？
经过深入的讨论和分析，最后我们认为，根本原因还是 系统设计方案 有问题，也就是说，技术上是比较弱的。
得到这个根本原因之后，解决策略就比较明显，总结一句话就是“ 把运维的锅让研发去背 ”，不要指望你的运气好或者烧香、提高某某人的运维能力，而是假设所有的这些问题都有可能发生，发生之后你的系统是不是有应对的措施和快速的解决方案？最终我们决定 从技术方面来解决这个可靠性的问题 。
高可用目标-传统方法
确定这个方向之后我们就需要定一个目标，首先确定一个目标。高可用其实都是指几个9，5个9的话可能就是电信级或者金融级的，互联网大部分是3个9到4个9。
刚开始也想用这个指标作为一个目标，比如说想达到4个9或者5个9，但是这个指标的优点是业界通用，搞技术的大家都接受了这个指标。
但是有一个缺点，除了技术人员，其他同学不是很好理解，他们没有办法将4个9或者5个9转换成直观的理解。所以，我们当时在定项目目标的时候并没有这样去定。
高可用目标-面向业务
我们最终确定的目标跟几个9的目标有一个比较大的区别，几个9的目标主要是从系统的角度去考虑的，就是说这个系统的可靠性是几个9。
而我们的目标是面向整个业务，这个目标就是 3分钟来定位问题，5分钟能恢复业务 ，而且问题的发生频率不能太高，2个月发生一次。
这个目标的优点：
1、聚焦业务。
2、容易分解。目标本身就是我们的工作方向，首先要定位问题，怎么定位问题？我们就可以想一个办法，其次是恢复业务，第三是故障的频率不能太高；
3、容易衡量。我们后来再做方案的时候，很多方案只要拿这个标准一套，基本上就能够判断这个方案是否可行。
整个目标最后折算下来，对应的差不多是4个9左右，比4个9高一点点。
高可用整体架构
整体架构一共分为四层：用户层、网络层、服务层、运维层。
整个架构其实跟目标是一样的，我们是面向整个业务的，没有说哪个系统应该具备几个9的高可用，而是站在整个业务的全流程来看假设要达到目标，每一个应该怎么去做。
每一层都需要做一些应对的方案，才能达到目标。
接下来我就详细给大家介绍一下，每一个方案的基本思路和做法。
客户端重试
在游戏接入阶段，游戏里会嵌入我们的SDK，对于SDK内的产品来说，如果遇到后端故障，最快、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，我们重新发一个请求到服务器2，就能够正确处理业务。
重试里面有一个关键点需要特别注意，重试的时候必须保证这个请求不要再发到原来有问题的服务器上面，否则这个重试只是浪费时间。
传统DNS问题
在重试的时候，要尽量保证重试的服务器跟原来的服务器不一样，但是传统的DNS正好在这方面存在天然的缺陷，DNS存在三个方面的问题：
1、DNS劫持
2、DNS污染
3、DNS缓存
比如这个截图就是我们的用户的机器上 DNS 已经被运营商给 劫持 。对于 DNS的污染 来说，在国内大区域网络应该是每时每刻都在发生的。 DNS缓存 ，包括操作系统，为了提高性能，都把DNS解析的结果缓存在本地，这样就会带来一个问题，我们在重试的时候，有可能第二次重试还是发到原来有问题的机器上。
我们做了一套HTTP-DNS方案，用户可以向HTTP-DNS系统请求，其实也是域名和服务器的对应关系，但是它走的是HTPP私有的协议，而不是走传统的DNS协议。
我们的运维人员可以直接在这个HTTP-DNS服务器上去修改配置，比如说某台机器有故障，运维一键就把它下掉了。我们的服务器也可以自己上报一些状态和监控给HTTP-DNS系统。
HTTP-DNS系统有三个优点：
1、 灵活 。因为这个走的是HTTP的协议，而且是私有的，可以基于自己的业务特点做很多个性化的东西。
2、 快速 。因为它不存在缓存这个问题，一旦运维人员甚至是测试同学把这个服务器下掉后，用户这个请求能够立刻拿到最新的结果，避免重复返回到原来有故障的机器。
3、 方便 。这个系统是我们自己维护的，想做什么样的操作都可以，如果是公共的DNS那就做不了。
客户端重试+HTTP-DNS
结合客户端重试+HTTP-DNS之后，整体的解决方案就是这样的，正常的时候走的传统DNS，异常情况下就走只有的HTTP-DNS。传统的DNS成功了，那业务就没有问题，如果失败了，再走HTTP-DNS请求。
为什么正常的要走传统的DNS呢？
这是为了性能考虑，因为HTTP-DNS为了能够快速地处理故障，它其实是不存在缓存机制的。所以，正常情况下走传统DNS有利于我们保证业务服务的性能。
下图是原来的架构，这个系统把所有的功能都包含了，比如说登录、注册、参数下发、消息、日志、更新。
其实对于玩家来玩游戏来说，真正强相关的只有登录注册和参数下发，消息和日志、更新其实并不是玩家玩游戏必须具备或者强相关的。
所以，业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把两个系统之间通过接口调用，互相访问。
这样做的好处，假设非核心业务系统出现故障，它并不影响核心业务系统，因为它们之间是通过接口调用的，并不共享相同的资源。
举一个最简单的例子。
现在因为运营的误操作，下发了大量的消息，最后把整个系统冲死了，玩家登录不了，游戏玩不了。
拆分之后，这块系统自己能够完全挂起，跟玩游戏相关的登录、注册都不受影响，他可以继续访问，只要玩家只要能够登录游戏进行玩，就不会有太大的问题。
当然，这个架构对系统功能实现还是有一定要求的，毕竟有接口访问，核心系统和非核心系统还是有一定依赖的。
所以，对于核心业务系统来说，涉及到非核心业务系统的访问就需要做一定的容错处理。如果接口调用失败后，你自己的业务就失败了，就起不到业务分离的作用。
服务中心类似于DNS，是实现整个内部系统之间服务调用时候的调度功能，服务中心是一个类似于服务的名字系统。
比如说有一个A业务想访问其他系统提供的业务。它首先并不是直接访问到另外一个系统，而是要到服务中心访问一下。
比如说我需要X服务，服务中心告诉A：你去访问Host1+port1的xxx接口。服务中心有一个配置和状态上报，可以根据一些状态、算法、配置，选择一个最优秀的服务器告诉A业务。
那么，A业务收到之后就按照这个指示去访问真正提供业务的机器，比如B系统里的Host1+ port1这个机器。服务中心的作用跟HTTP-DNS的作用差不多，就是希望在内部某个系统故障的时候可以快速处理或者切换。
假设B系统某台机器有问题了，我们可以通过自动或者人工的方式在服务中心把这台机器直接下掉，A业务请求的时候，它就不会再请求到这个有问题的机器上，这一台机器的故障就不影响A业务。
整个系统拆分成核心业务系统和非核心业务系统，在一些紧急情况下，比如说非核心业务系统重启也没有办法，甚至说某个数据库搞挂了，它又影响业务核心系统。
这个时候，接口是可以访问的，但是响应时间特别慢，核心系统就有点被拖慢。
那么，在这种比较极端的情况下，我们可以通过人工的方式下发降级指令，把这个非核心业务系统的功能给停掉，这个停掉并不是把程序停掉，而是说把其中的一个接口或者url停掉，核心系统去访问的时候就得到一个500或者503错误。
我们做了一个专门的降级系统，降级系统可以去下发这些降级指令。一般情况下由降级系统给非核心业务系统下发降级指令，如果到了一些关键时刻，其实核心业务系统中有的接口也是可以进行降级的。
也就是说，我们降级的时候并不是对整个系统或者整个功能进行降级，我们可以做到接口或者url这个级别的降级。通过牺牲非核心业务系统的功能，我们尽最大努力地去保证核心业务系统提供的业务。
这个业界有很多叫法，比如有损服务、可损服务，其实我们这个也是一个可损服务，功能上的可损，不是流量上的可损。
原来的老架构中分两个集群：A集群、B集群。两个集群共用同一个数据库主库，部署在A集群，所有的写操作都放在A集群主库，由A集群主库同步到A集群从库、B集群从库，各集群的读操作都直接读集群本地的从库。
它的缺点是存在全局单点的问题，假如说A集群主库挂了，两个集群的业务基本上全部不能提供了。
第二个问题是跨机房同步时延的问题，从A集群同步到B集群，我们是直接通过MySQL底层的复制机制去同步的，在一些比较极端的情况下，它的时延可能达到半小时甚至一个小时，这么大的时延的情况下，提供的业务可能就有问题。
为了解决全局单点、跨机房同步时延的问题，我们做了一套新架构，如下图：
这个新架构和老架构相比。 最大的特点 ：
1、 业务层数据同步 。现在有两个主库了，每个集群读写自己的库。那么，两个集群的数据怎么同步呢？我们其实是通过应用层进行数据同步的，而没有采用数据库底层的机制读库。
这样做有一个好处，我们能够尽量通过程序去保证同步的有效性和及时性，而不依赖于底层，用程序可以做多种动作。
2、 二次读取 。虽然程序进行同步能够尽最大可能缓解同步时延的问题，但是在一定极端情况下其实还是有一定时延的问题。所以，我们又做了两个集群直接互相读取的功能，叫二次读取。
也就是说，有的数据在A集群还没有同步到B集群，B集群此时是读取不到的，这时B集群的系统会通过程序的接口再去访问A集群的系统，意思是：A集群，你这边有没有这个数据？如果有的话，A集群就要返回数据给B集群，B集群再把数据再写入本地。
3、 可重复生成全局唯一数据 。我们的游戏数据中有一个数据是要求全局唯一的，不管在哪个集群，不管什么时候生成，对于同一款游戏、同一个用户来说，这一个值都是唯一的。
最开始的时候，我们是通过redis两个集群分段来实现的，但是通过redis分段就有一个问题，假设其中一个集群宕机之后，另一个集群并不能把原来集群的业务全部接过去，只是能够保证自己集群的业务没有问题。
我们为了能够解决两个集群互相接管对方的业务，就做了可重复生成全局唯一数据方案。
整体方案从上到下分为五层：业务层、应用服务层、接口调用层、基础组件层、基础设施层。
1、 业务层： 就是我们业务上的打点，根据这些打点进行机型统计或者分析；
2、 应用服务层： 简单来说就是我们url的一个访问情况；
3、 接口调用层： 就是我们自己系统对外部依赖的那些接口的访问情况，比如A系统调用B系统的一个接口，在A系统里统计或者监控调用B系统接口的情况，包括时延、错误次数之类；
4、 基础组件层： 其实就是我们使用的一些组件，包括MySQL等；
5、 基础设施层： 就是最底层的，包括操作系统、网络、磁盘、IO这些设备。
整个监控是分层的，在我们出现问题的时候，定位问题需要的关键信息全部包括在这里面的。
自动化的监控方案是业界现在最常见的ELK解决方案，整个方案是实时采集和分析的，并不需要人工参与。
为什么特别要做自动化日志分析呢？
我们来看看在没有做自动化之前我们是怎么处理线上问题和故障的。
首先，研发测试同学问一下运维同学这些IP是多少，再一台一台机器登录上去，再把日志下载下来，再由研发或者测试同学去写脚本去分析。
整个流程非常低效，从生产网到办公网的网速很慢，要下载1G日志可能需要半小时、一小时，如果下载10台机器，我们之前遇到一次把10台机器日志下来用了三个小时。
其次，现场由测试同学和研发同学去写AWK这些脚本的时候，经常会出现脚本写错了，毕竟研发和测试同学写脚本的经验也不会太多，之前就出现过分析了半天最后发现这个脚本写错了。
要知道，在处理线上故障的时候是争分夺秒，你下载日志半小时、写个脚本写错了调试10分钟、把脚本和日志跑一下半个小时，一个多小时过去了，用户的投诉电话已经打到客服顶不住了。
为了能够快速处理这个故障，我们进行了详细的分析，把真正出故障的时候要关注哪些信息、关注哪些指标，都通过预先的日志采集、计算、分析完成，放在那里等我们要处理故障或者问题的时候，直接看就可以了。
每一层的指标，都通过一个系统可视化展现出来。比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率。
整个立体化监控的这一套系统出来之前，我们定位故障或者处理问题都需要最顶级、最资深、最核心的员工放下手头的工作来处理， 为什么？
因为那些日志，其他人如果你没有做过的话，你不知道分析哪个日志，只能找他们来处理和定位。
有了这套系统以后，只要是做这个业务的同学，不管是研发还是测试，他都能够通过这套系统快速地定位问题。
有了这套系统以后，有的业务部门确定了一个值班机制，每周都安排几个人去检查系统状态，新同学也可以，研发也可以，测试也可以，甚至项目经理都可能上去看一下系统的状况。
整个系统的状态一目了然，基本上识字就能够看懂整个系统的状态。
除了发现比较大的问题外，一些很小的问题，我们也可以通过这个系统发现。
我举一个最简单的例子，比如我们有一个系统，上了这个系统一看，每天到了零点，请求量就爆涨。我们的业务比较特殊，12点没有什么人来真正要去刷或者签到、领礼包之类的；
但是奇怪的是到了12点就暴涨，后来通过可视化的监控系统把每天12点的访问量排行一看，原来是有一个日志接口，代码写成“定时上报，定时12点”，结果在12点大量客户端同时上报日志。
定位问题后其实修改方式比较简单，改一下，在12点左右就行了。
1、 面向业务 。不单单关注某一个系统某一个模块的可靠性和高可用，而是站在 整个业务流程 的角度去分析一下，为了保证这个业务的高可用，每一个步骤、每一个环节、每一个系统应该怎么做，需要做哪些改进和优化。
2、 技术驱动 。我们并没有说制定完善的流程、提高人的素质或者采购更贵的硬件、更好的硬件，整体的方案都从技术的角度去考虑。
3、 关注核心 。非核心业务我们可以紧急的时候停掉或者关掉。
4、 可量化 。360度监控里的这些指标、分析都是可以量化的，整个项目目标也是可以量化的。
整体方案的效果
做这个方案前，几乎是每个月有一次故障，最极端的是有一个月有4次比较大的故障。可用性指标大概是3个9。
做完这个系统之后，到目前为止没有一次大的线上故障，可用性指标达到了4个9。 是不是我们的运气好呢？
其实不是，做了这套方案后，机房的线路也挂过，交换机也断过，就在3月份的时候我们刚刚有一台核心交换机的缓存模块出现故障，最后厂商定位说是他们的Bug，交换机花了半个小时才定位恢复，但是对我们的业务其实没有影响，因为我们把整个业务切到另外一个机房去了。
天下无贼，运维无锅。研发、测试、运维，大家一起来设计高可用性。
谢谢大家！
提问1：我们知道，DNS请求不需要有端，但是HTTP-DNS是有端，在端上找到你们的服务器，你们的服务器出现故障是怎么切换的呢？
李运华：服务器出现故障的话，可以通过人工，也可以通过自动，来修改HTTP-DNS上面的配置。
提问2：不是，我是说HTTP-DNS如果出现故障，端的处理，怎么在端切换的？
李运华：我们整体流程，正常情况下我们走传统DNS，传统DNS有问题的时候，我们再走HTTP-DNS。如果说，正常的DNS也出现问题了，HTTP-DNS也出现问题了，这个就没有办法了。
当然，其实我们有几套HTTP-DNS。
提问3：如果这一台故障了，端那边没有办法处置到另一台吗？
李运华：我们有几个HTTP-DNS系统。
提问4：HTTP-DNS上面的故障和DNS的故障，你们是自动调度过去，两边都会生效，只是说DNS有缓存。
李运华：对。
提问5：刚才讲到的服务中心数据是不是相当于Load Balance
李运华：服务中心和Load Balance还是有区别，虽然它的作用也是Load Balance的作用，但服务中心并不直接接受真正的接口请求，它类似于一个DNS。
提问6：更多的作用还是在于DNS里面。
李运华：对，你可以理解为它是一个服务的名字系统。谢谢。
我是华丽的分割线
参加 GOPS2016上海站 ，老司机带你飞！
& 位运维行业顶级大咖，已经到位！
，时不待我！
8折优惠截止7月31日，请速度！
↓↓↓ 点击& 阅读原文 & 【直接报名】
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致