所谓高可用是指系统如何保证相对较高的服务可用率，以及如何处理故障，包括及时发现、故障转移、故障尽快恢复aspossible等。本文主要围绕评论交易系统的演进来描述如何实现高可用，并结合自己的一些经验。需要强调的是，高可用只是结果，更应该关注迭代过程和业务发展。可用性了解 1。了解目标 业界高可用的目标是几个9。对于每个系统，要求是不同的。对于他们设计或开发的系统，研发人员需要知道用户规模和使用场景，以及可用性目标。例如，5个九的目标对应于全年5分钟的停机时间。 2。拆解目标 几个9的目标比较抽象，需要对目标进行合理分解，可以分解为以下两个子目标。 (1)频率要低：减少失败次数 没有问题，就必须高可用，但这是不可能的。系统越大越复杂，要想避免出现问题，唯一的办法就是通过系统设计和流程机制来降低出现问题的概率。但是如果经常出问题，后面再快点恢复也没用。 （2）更快的时间：缩短故障的恢复时间 发生故障时，不是解决或定位具体问题，而是快速恢复才是重中之重，以防止次生灾难和扩大问题.这里需要从业务的角度去思考，而不仅仅是技术的角度。 下面，我们将详细阐述这两个子目标。 频率要低：减少失败的次数 设计：根据业务变化不断迭代 以评论交易系统的演进过程为例。 童年：2012年之前 使命：满足业务需求，快速上线。 由于2011年团购产品需要快速推向市场，各团队临时抽调的人才大多对.NET比较熟悉，所以第一代团购系统设计采用。网。毕竟满足业务需求是最好的，没机会遇到可用性等质量问题。考虑比较简单。就算都挂了，音量也比较小。如果出现问题，重启、扩容、回滚即可解决问题。 系统架构如下图所示。 青春：垂直分裂（2012-2013） 使命：研发效率&故障隔离。 当2012年群内订单量从几千变成几万，用户日订单量也达到几万，需要考虑迭代速度和研发效率。垂直拆分有助于保持小而美的团队，研发效率可以更高。另一方面，也需要将各个业务相互隔离，比如商品首页的展示和商品详情页的展示，订单和支付流程的稳定性要求是不同的。前端可以缓存，可以静态化，保证可用性，提供一些灵活的体验。后来，支付系统被用于异地容灾。比如除了南汇机房付费系统，我们在宝山机房也部署了，但是后来发现这个系统进化太快了，没有工具和机制来保证双机房的更新，所以以后不好用了。 系统演进如下图所示。服务是垂直化的，但数据并不是完全隔离的，服务之间需要访问对方的数据，而不是自己的数据。 青年期：小服务，无数据共享（2014-2015） 使命：支持业务快速发展，提供高效高可用的技术能力。 从2013年开始，Deal-service（商品系统）偶尔会因为某个大流量（大促或定期活动）挂掉，每隔几个月总有一次，可用性基本在39徘徊。这里的订单和支付系统非常稳定，因为流量从产品详情页到订单有一个转化率。流量太高，详情页就挂了，订单就没有流量了。后来详情页的静态化比较好，可以降低恢复和降级的速度，但是Deal-service的系统依赖太深，端到端的整体可用性无法保证。 所以在2014年对Deal-service做了一次大的重构，把大系统做小，把商品详情系统拆分成无数个小服务，比如库存服务，价格服务，基础数据服务，等等。既然商品详情页的问题解决了，后面的压力就来了，订单系统的压力会越来越大。2014年10月起，订单系统、支付系统也全面上线微服务。经过一年左右的实践，订单系统、推广系统、支付系统这三个领域背后的服务总数将近数百个。对应的数据库有20多个，最多可以支持每天的订单量***。 业务增长可以在应用服务层面进行扩展，但最大的单点——数据库是中心化的。现阶段我们主要将应用的数据访问和读写分离，数据库提供了更多的从库来解决读的问题，但是写仍然是绝对的瓶颈（MySQL的读可以扩展，和写入QPS仅少20,000）。 此时，系统演化如下图所示。该架构可以支持约QPS3000的订单量。 成年期：水平拆分（2015年至今） 使命：系统必须能够支持大规模的促销活动，订单系统可以支持几十个每秒数千QPS，每天数千万订单。 2015年的917美食节，人流量最高。如果还维持以前的技术架构，肯定会失败。所以在917大促的前几个月，我们升级了订单系统的结构，横向拆分。核心是解决数据的单点，将订单表拆分成1024张表，分布在32个数据库中。每个库有32个表。所以在可预见的未来没有什么可担心的。 虽然解决了数据层问题，但是我们还有一些单点，比如我们使用的消息队列、网络、机房等。举几个我过去遇到的不容易遇到的可用性问题： 服务的一个网卡坏了，没有被监控。后来发现另一块网卡也坏了，于是服务就挂了。 我们在使用缓存的时候，发现高峰期可用性很低。后来发现缓存服务器和公司监控系统的CAT服务器在同一个机柜里。高峰期的流量被CAT占据了一大半，业务的网络流量不够用。 917大促期间，我们对依赖它的消息队列的通道能力评估出现偏差，没有备份计划，所以造成了少量的延迟。 这一时期系统的演化如下： 未来：思路还是让大系统变小，基础通道变大，流量块 大系统变小，就是将复杂的系统拆分成单一的职责系统，从单机、主备、集群、远程等架构方向进行扩展。 拓宽基础通道，就是拓展基础通信架构、带宽等高速路。 流量切分是将用户流量按照一定的模型进行切分，让它们聚合到一定的服务集群中，实现闭环解决。 系统的演化可能如下图所示： 以上对交易系统的发展阶段进行了评论，仅以业务系统的演化为例。除了这些，还有CDN、DNS、网络、机房等各个时期遇到的不同的可用性问题。真正遇到的问题是：联通网络宕机，需要切换到电信；数据库电源启动。etc. 易于操作 一个高可用性的系统必须是可操作的。当您听到运营时，人们更多地想到产品运营。事实上，技术也有运营——在线质量和流程运营。比如整个系统上线后，是不是方便切换流量，切换，扩展。这里有几个基本要求： 限流量 在线流量总是出乎意料。在这种情况下，系统的稳定吞吐量非常重要。高并发系统普遍采用的策略是一种快速失败机制。比如系统QPS可以支持5000，但是如果来10000流量，我可以保证连续5000，另外5000我fastfail，这样10000流量很快就被消化掉了。比如917的支付系统就采用了流量限制。如果流量超过某个峰值，我们会自动返回“请稍后再试”。Stateless 应用系统必须是完全无状态的，这样运维才能随意扩容和分配流量。 降级能力 降级能力是和产品一起看的，需要考虑降级后对用户体验的影响。简单的例子：提示是什么。比如支付通道，如果支付宝通道挂了，我们挂了50%，支付宝旁边会自动出现提示，提示这个通道可能不稳定，但是可以点击；当支付宝通道宕机100%时，我们的按钮变成灰色，无法点击，但也会有提示，比如换其他支付通道（刚才微信支付还挂着，又能用了）。还有一个案例，我们在917推广过程中对某些依赖方进行了验证，比如完整性验证。如果判断其消耗资源较多，可控，则可直接关闭或通过开关启用。 可测试性 无论多么完美的架构，验证都是必不可少的一步，系统的可测试性非常重要。 测试的目的是先预估流量大小。比如在某次推广中，需要跟产品和运营商量流量来源和活动强度。必须比较每个页面和每个按钮的位置。准确的估计。 除了测试集群的能力。很多同学在实现的时候总是喜欢测试一个单元，然后横向放大给出结论，但是这样不是很准确。有必要分析系统之间流动的所有流量的比例。特别是流量模型的测试（注意高峰流量模型可能与正常流量模型不一致）系统架构的容量测试，比如我们一个大促的测试方法。 从上到下评估流量，从下到上评估能力：发现每次提交订单有20次数据库访问，读写比高峰期1:1，后续跟进数据库的能力推导出系统应该放什么Traffic，然后做好前端的异步下单，让整个流量顺利的放到数据库中。 降低发布风险 严格的发布流程 目前，评论的发布由开发者自行负责，通过平台自行完成。上线流程及发布大体流程模板如下： 灰度机制 服务器分批发布，按照10%、30%、50%、100%发布，开发者观察监控系统曲线和系统日志判断业务是否正常。 线上流量灰度机制，重要功能可按一定流量灰度上线。 回滚是标准的，并且存在最坏的情况。时间要快：缩短故障的恢复时间 如果目标是保证全年无故障或5分钟内解决故障，就必须充分利用5分钟。5分钟应该是这样拆机的：1分钟找到故障，3分钟定位故障所在的服务，再加上后续的恢复时间。是整个时间的分解。目前我们的系统可以大致实现前两步，和总体目标五个九还有差距，因为恢复的速度跟架构的设计有关，跟开发之间信息沟通的速度有关，运维，和DBA是有关系的，跟工具的能力和处理问题的人的能力有关。 HP： 继续关注线上运行状态 熟悉并感知系统变化，一定要尽快熟悉，熟能生巧，所以要关注线上运行状态。 了解应用所在的网络、服务器性能、存储、数据库等系统指标。 可以监控应用的执行状态，熟悉应用自身的QPS、响应时间，以及可用性指标，并熟悉依赖的上下游流量情况。保证系统吞吐量稳定 如果系统能够做好流量控制和容错，吞吐量稳定，就可以保证大部分场景的可用性，并且可以快速消化峰值流量，避免出现故障和多次流量高峰。 故障 快速发现机制 报警调动 系统可用性报警均应采用微信、短信等通讯机制，确保发现人。 实时报警 目前只能实现1分钟左右的报警。 监控可视化 我们系统目前的要求是1分钟发现故障，3分钟定位故障。这就需要很好的可视化监控，在所有关键服务中管理方法层，然后做监控曲线。否则，很难在3分钟内定位到问题发生的具体位置。大众点评的监控系统CAT可以很好的提供这些指标的变化，我们的系统也基于这些开发了一些更加实时的能力。比如订单系统QPS就是秒级监控曲线。有效的恢复机制 ，如运维四轴：回滚、重启、扩容、宕机。这在系统不是很复杂，流量不是很高的情况下可以解决，但是流量大的时候就很难了，所以要在流量控制和降级体验上下功夫。 几点体会 珍惜每一个真实的高峰流量，建立高峰流量模型。 因为通常的压力测试很难覆盖各种情况，但是真实的在线流量可以忠实反映系统的瓶颈，更能真实地评估应用、数据库等在高峰期的性能。 珍惜每一次在线故障复习，下楼看问题，下楼解决问题。 线上出现问题后，一定要有一套方法论来分析，比如常见的“5W”，连续多问几个why，然后系统地思考解决方案，然后逐步实施。 可用性不仅仅是一个技术问题。 系统前期：重点开发； 系统中期：专注开发+DBA+运维； 系统后期：技术+产品+运维+DBA。 当系统比较简单，体积较小时，开发者更容易定位和解决问题。 当系统进入比较复杂的中期，需要跟运维和数据库的同学一起看系统的瓶颈。 当系统进入到复杂的后期，系统必须考虑如何在随时不可用的情况下提供灵活的体验，这就需要站在产品的角度去思考。 积分和发布是可用性最大的敌人。 可用性上要解决的核心问题是单点，比如常见的手段：垂直拆分、水平拆分、灰度发布；单机到主备、集群、异地容灾等。 另外，系统发布也是导致系统故障的一个关键点，比如常见的系统发布、数据库维护等导致系统结构变化的操作.
