阿里游戏高可用架构设计实践 ------读后感
这篇文章基本总体就是在讲系统的可用性问题，即如何从技术层面解决这个问题。在对可用性的解释，我在之前的《以《淘宝网》为例，描绘质量属性的六个常见属性场景》中有解释到。
可用性：可用性是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。在对可用性的使用场景，我在之前的《以《淘宝网》为例，描绘质量属性的六个常见属性场景》中有解释到。
高可用的系统是设计出来的，不是靠运维保障出来的，
但是如何在设计系统的时候如何提高系统的可用性呢？
1.高可用目标-面向业务
可用性的目标是面向整个业务，这个目标就是几分钟来定位问题，几分钟能恢复业务，而且问题发生的频率不能太高，几个月发生一次（其中的“几”要根据我们的业务目标来定）
2.高可用整体架构（整体架构分为四层：用户层、网络层、服务层、运维层）
1)用户层：客户端重试，即当遇到后端故障的时候，对用户影响最小的解决方式就是让用户重试，如服务器发生故障的时候，就重新发送一个请求到另一个服务器，在另一个服务器中处理业务
2)网络层：HTTP-DNS
3)服务层：架构解耦
·业务分离：业务分离的做法就是把核心业务和非核心业务分拆到不同的系统中，把 两个系统之间通过接口调用，互相访问，这样做的好处，加入非核心业务系统出现故障，它并不影响核心业务，因为它们之间是通过接口调用的，并不共享相同的资源。
·业务降级：通过牺牲非核心业务系统的功能，尽可能地保证核心业务系统提供的业务
4)运输层：要对系统实时监控。这是为了更快的找到故障点，这样的话可以更快的解决故障，增加系统的可用性。比如这篇文章中说：“为了能够快速处理这个故障，我们进行了详细的分析，把真正出故障的时候要关注哪些信息、关注哪些指标，都通过预先的日志采集、计算、分析完成，放在那里等我们要处理故障或者问题的时候，直接看就可以了。”其次还要对系统的监控指标进行可视化展示，比如，今日的访问量、今日的正确率、最近一分钟的平均响应时间、错误率等，系统的状态一目了然，这样的话可以快速的定位问题。
针对可用性对系统架构的设计哲学：
1）面向业务。不单单关注某一个系统某一个模块的可靠性和高可用，而是站在整个业务流程的角度去分析一下，未来保证这个业务的高可用，每一个步骤、每一个环节、每一个系统应该怎么做，需要做哪些改进和优化。
2）技术驱动。整体的方案都从技术的角度去考虑
3）关注核心。非核心业务可以晋级的时候停掉或者关掉，从而尽可能地保证核心业务系统提供的业务。
4）可量化。监控里的这些指标和分析都是可量化的，整个项目目标是可以量化的。
