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