http://www.Sina.com/http://www.Sina.com /
摘要)高可用性架构师APP体系结构设计的最基本要求是，无论产品是处于初期阶段还是处于快速发展阶段，在作为业务软件向用户提供服务时，都必须考虑可用性设计。
作者：中国移动云能力中心——
可用性：可用性，系统可用时间的说明，即uptime，计算方法：
a=uptime/(uptimedowntime )其中uptime和downtime分别是可用/不可用时间。
我们常说的“几个九”，最多是指系统的可用性。 当然，可用性越高越好，但可用性越高就意味着投入了越多的资源，需要根据实际业务发展阶段进行权衡。 实现不同级别可用性的技术手段通常见下表。
wydxhd
一、基本概念
可用性等级
可用性数值
基本上可以使用
99%
88 h
负载平衡
高可用性
99.9%
8.8 h
自动化部署
可在高级别使用
99.99%
53分钟
微服务APP应用监控容错的灵活扩展
非常高的可用性
99.999%
五分钟
异地灾难恢复
年最大停机时间
是什么降低了可用性？ 影响系统可用性的因素是什么？
影响可用性的因素
可见，系统的可用性除了受技术管理类因素(如不规范的变更)的影响，如不准确的流量预测、未考虑的资源冗余等，还多来自系统架构的初步设计。
常用的技术手段
对于软件开发人员来说，负载均衡、数据库主控等最常见的系统可用性方案也有可能通过云平台为云产品提供资源的灵活伸缩。 这些方案都是一般性方案，不重点介绍。 重点讨论体系结构设计中另外两种经常被忽略的可用性方案：容错和限制流。
从某种意义上说，前面提到的负载均衡和数据库主备簇都属于容错范畴，具体来说，对于系统运行阶段的容错设计，比开发阶段的容错设计成本更低，更容易理解。 其实，开发或设计阶段的容错设计对系统的可用性是“关键”。
二、影响系统可用性的因素
程序是人类开发的，错误当然是不可避免的。 良好的容错方案可以大大提高软件对错误的兼容性，即使系统遇到突发错误也能保证一定的可用性。
三、可用性设计的常见方案
采用负载均衡策略时，比较直接的容错方式通过引入多个节点解决故障节点的业务负担问题，一般节点越多容错效果越好。
1、容错设计
服务降级是“牺牲局部、保全全局”的思想，实现在系统面临崩溃时保证主线业务的生存。 服务降级的主要方法如下。
当33558www.Sina.com/EC平台为“618、双11大促”时，如果发货时效性不是最重要的，可以关闭物流发货服务，空闲资源可以优先保障产品、订单和计费服务的正常运行典型的软件系统通常允许关闭系统日志功能或延迟通知类消息的发送。（1）避免单点请求短：如果系统流量超过预定值，则如需要查询高速缓存(90 )数据库) 10 )的组合场景那样，简化了系统过程10 ) )流量百分比也会导致数据库崩溃。 通过配置为实时更改缓存更新时间，可以提高缓存命中率，并进一步提高部分缓存的承载比例。 另一种思想是采用更粗暴的处理方式，直接返回预定格式的结果，请求直接在入口折返。 两种方式都采用了短路方式简化了系统过程，提高了容错能力； 裁剪枝节(指系统主流行程以外的业务枝节，即管理类服务。 常见的管理类服务包括定时任务、数据采集任务等。 这两类任务往往对系统的CPU和网络IO有一定的影响，如果系统流量超标，可以考虑关闭定时任务、数据采集任务等(如统计类、结算类服务等)。（2）服务降级业务异步交接：当系统流量压力较大，后端部分数据无法及时处理时，将同步任务改为异步交接方式。 例如，引入消息队列临时接受请求，在实际业务恢复后进行最终的数据处理。 当然，这种处理方式会给数据的完整性带来损失。 “写入”交接：与队列类似，但在数据库的“写入”级别而不是业务数据上，在数据库之前构建高速缓存，接受写入请求，然后单击数据库中的
即时写”压力。这是一种变相的异步特性。必备要求服务降级在落地上有一定的要求，首先，需要对于所有服务进行优先级的排序，编排若降级模型（如A服务压力大，关闭C服务），另外最关键的一点即是“支持一键配置”，支持一键切换，实现对于预定服务模块的关闭、流程的干预，否则服务降级则为空谈。
（3）重试机制
超时重试是比较典型的架构容错设计思想，但是重试机制不可肆意运用，无限制的重试机制对于服务来说可能会是一种灾难。重试的实现方试包括编码和开源框架两种，参考如下：
基于编码的重试对于Java类应用，利用Try-catch原生机制实现重试，即在catch里面直接通过编码实现重试，对于一些高级一点的策略，增加重试时间间隔和重试总次数的控制。此种方式下产生的重试编码和业务逻辑代码严重耦合，通常需要引入异步方式实现，无形中增加了对于线程安全的控制成本。
基于开源框架的重试基于注解的Spring-tryer工具，支持对于重试方法最大执行次数、延迟间隔的设置。
基于Guvua-retrying框架工具，实现了比Spring-tryer更多的策略配置支持，如随机重试、智能等待时间策略、单次限制时间、停止策略等。对于通知类的应用程序，建议添加重试逻辑，使用Guvua-retrying是个不错的选择。
（4）隔离设计
隔离设计的初衷是将错误控制在一定范围，避免错误的传播，对于交易型的业务系统一定要进行“隔离设计”。常见的隔离设计包括如下四种。
系统隔离性设计方法
2、限流设计
限流设计是一种面向未知的设计思想，在流量超过实际容量时，拒绝容量之外的请求以达到保护系统的目的，对于高并发类业务系统，限流是必备选项。
限流算法常见的限流算法主要包括如下三种：
固定窗口算法/fixed window该算法不是真正以上的平滑限流，固定的窗口一般不会设置的太短，通常为分钟级别，然而分钟级别并不能实现精确的流量限制，在窗口交替处可能会带来突发的流量涌入。
不过该算法实现简单，业务开发人员可以利用缓存等常见方案实现，对于一般的系统来说，可以基本满足需求。
漏桶算法/Leaky bucket通过队列来缓冲请求，先进先出，整体上保持出桶的流量是稳定平缓的，该方式下的队列帮助系统实现了“削峰填谷”的效果。
令牌桶算法/token bucket每秒放入x个token，桶最多可以放入m个token；每到达一个请求就消耗掉一个token，该算法是一种改进型的漏桶算法，只要桶内有令牌就支持突发的流量流出队列，所以该算法相对漏铜算法，支持一定程度的突发流量。
（2）限流方案
在微服务架构下，各服务之间实际承载的业务请求量是有很大差距的，所以限流策略不能一概而论的开展，需要做针对性的限流。常见的限流方案参考如下：
Guvua限流实现了令牌桶算法，Guava通过提供限流工具类RateLimiter来实现限流目的，该工具提供两种令牌桶的细分算法：
平滑突发限流：SmoothBursy平滑预热限流：SmoothWarmingUp专业限流工具SentinelKongNginx限流在如Nginx类的负载均衡软件上进行的限流，属于“全局入口限流”，实现最粗粒度的限流目的。Nginx的限流主要有以下几种方式：
连接数限流（ngx_http_limit_conn_module）限制并发连接数，流量异常识别、恶意攻击，支持通过健值设置的连接数限制
Limit_conn_zone $remote_request_ip zone=req_server_ip rate=50r/s
实现针对IP地址的每秒50最大连接数的限制。
请求限制（ngx_http_limit_req_mobule）限制请求数，通过漏桶算法实现
Limit_req_zone $remote_request_ip zone=req_server_ip rate=50r/s
Limit_req zone=req_server_ip burst=5
实现针对IP地址的每秒50最大请求数的限制。
四、小结
可用性设计是软件架构设计的最基本要求，可用性设计常常被开发人员所忽略，尤其在云计算时代，可以凭借云原生产品帮助产品轻松实现运行态高可用，而本文所提出的容错和降级方案对于产品设计态阶段仍然具有参考价值。
版权声明 (原创)：本文内容由移动云用户自发贡献，版权归原作者所有，移动云开发者社区不拥有其著作权，亦不承担相应法律责任。如果您发现本社区有涉嫌抄袭的内容，可填写举报信息，一经查实，本社区将立刻删除涉嫌侵权内容。