大众点评高可用性系统运维经验分享

所谓高可用性指的是系统如何保证比较高的服务可用率，在出现故障时如何应对，包括及时发现、故障转移、尽快从故障中恢复等等。本文主要以点评的交易系统的演进为主来描述如何做到高可用，并结合了一些自己的经验。需要强调的是，高可用性只是一个结果，应该更多地关注迭代过程，关注业务发展。

可用性的理解

　　1.理解目标

业界高可用的目标是几个9，对于每一个系统，要求是不一样的。研发人员对所设计或者开发的系统，要知道用户规模及使用场景，知道可用性的目标。比如，5个9的目标对应的是全年故障5分钟。

　　2.拆解目标

　　几个9的目标比较抽象，需要对目标进行合理的分解，可以分解成如下两个子目标。

　　（1）频率要低：减少出故障的次数

不出问题，一定是高可用的，但这是不可能的。系统越大、越复杂，只能尽量避免问题，通过系统设计、流程机制来减少出问题的概率。但如果经常出问题，后面恢复再快也是没有用的。

　　（2）时间要快：缩短故障的恢复时间

故障出现时，不是解决或者定位到具体问题，而是快速恢复是***要务的，防止次生灾害，问题扩大。这里就要求要站在业务角度思考，而不仅是技术角度思考。

　　下面，我们就按这两个子目标来分别阐述。

　　频率要低：减少出故障的次数

设计：根据业务变化不断进行迭代

　　以点评交易系统的演进过程为例。

　　幼儿时期：2012年前

　　使命：满足业务要求，快速上线。

因为2011年要快速地把团购产品推向市场，临时从各个团队抽取的人才，大部分对.NET更熟悉，所以使用.NET进行了***代的团购系统设计。毕竟满足业务要求是***的，还没有机会遇到可用性等质量问题。考虑比较简单，即使都挂了，量也比较小，出现问题，重启、扩容、回滚就解决问题了。

系统架构如下图所示。

　　少年时期：垂直拆分(2012-2013)

　　使命：研发效率