作者：京东零售 刘慧卿
一 前语
关于软件的高可用，是一个老生常谈的话题。“高可用性”（High Availability）通常来描绘一个体系经过专门的规划，从而削减停工时刻，而坚持其服务的高度可用性。其计算公式是：可用率=（总时刻-不可用时刻）/总时刻。
本文重点从落地实践的视角作为切入点，带领咱们从协作功率，技能落地和运营标准几个方面来展示高可用的施行进程和落地细节。为了方便了解，先来统一语言话术，看一下软件交给进程中的各个阶段，如下图：
为什么说软件的高可用会晤临着诸多应战呢？
◦ 从需求交给链路来看，要完结方针交给，需求产品，研制，测验，运维，运营等多方利益相关者的密切配合。有些项目需求，合作者有时可以到达上百人，每个人责任分工各不相同，但却相互配合依靠，任何一个环节呈现纰漏，可用率就有或许受到影响；
◦ 从时刻视点来看，假如要到达全年99.99%的可用率，就意味着一年当中，答应有毛病的时刻为：365*24*60*（100%-99.99%）=52分钟，假如要到达5个9的可用率，答应毛病的时刻仅为5分钟，这差不多是咱们发现问题后，重启使用的耗时；
◦ 从迭代功率来看，不迭代，不上线，问题呈现的概率一定会小许多。软件的迭代功率和可用率之间存在着负相关的关系，平衡好两者之间的关系，也会晤临着不小的应战。
总结一下，咱们详细面对的问题如下：
◦ 怎么处理需求交给相关协作者多，链路长的问题？
◦ 怎么应对毛病时刻容忍度低的问题？
◦ 怎么在频频需求迭代的现状下，坚持可用率不受到大的冲击问题？
二 协作功率确保
认知误区
从整个需求交给链路咱们可以发现，跟着链路的逐级递加，信息的传递链路分支就会越多，传递层级就会越深。这会导致两个问题：
-
信息传递功率下降；
-
信息准确性变差。
这两个问题终究导致的结果，便是协作功率的下降。
一个没有实战经验的同学往往会以为添加人数，就会进步需求交给功率。其实这种主意不完全正确，详细关系参阅下图：
这就像盖高楼，假如一个人按部就班的建设，需求100天完结。假如请了100个人来帮助，能否用1天的时刻完结房子建设呢？答案是否定的。
这儿面有协作的本钱，比方：团队默契（规划师，瓦工，泥工，水电工），岗位匹配，风险操控；
这儿面有流程的依靠，比方：施工依靠于规划，软装总在硬装之后；
这儿面有本钱预算，比方：整个组织的人才梯度，规模巨细（承建方，代理商，承包商）；
以上这些，都不是简单的经过人力铺设来处理的。
流程标准
进步协作功率的底层逻辑是经过削减交给链路层级，缩短信息传递链路，从而确保信息的准确性和传递功率。（组织建设层面的内容这儿不做打开）
这就要求具有今日事，今日毕的行动力。组织层面这叫流程标准，个人层面这叫做事方法，责任心。
尽量避免将当下的事情拖延到下一个环节，不然就会影响后续链路的排期方案和交给功率，极点状况甚至会呈现返工的情形。简言之，考虑清楚，不埋坑。产品需求对研制，研制规划对测验，测验用例对产品等各个交给节点都是如此，交给物一定是靠谱的。
三 技能落地确保
在需求呼应周期中，高质量的落实架构规划，编码完成，安全上线，部署运营等生产阶段，是软件高可用落地确保的条件和根底。
架构规划
架构规划往往影响着体系的前期完成本钱（即ROI）和后续运维难度，属于软件的顶层规划，这儿面既包括宏观的规划方案，也包括落地细节里的范式束缚。
• 流程确保
邀请架构师参与：中心买卖节点、严重需求改动邀请架构师参与，这是闭坑最直接有效的方式；
重视规划文档：方案描绘清楚了，并获得相关利益者的认可，是走在正确道路上的条件。
• 规划确保
容灾规划：要预留后路，提早想清楚，做好容灾规划。可回滚，可熔断，可重试，可降级。
鲁棒性规划：无状况规划，防重规划，幂等规划，数据一致性规划
编码完成
假如说架构规划是骨架，那么编码完成便是神经，血管和肌肉。前者决议了能走多稳，走多久，后者决议着走多快，走多远。落实到编码层面，便是代码的衰老腐败程度。
• 流程标准
代码评定机制：代码评定不仅仅是发现体系中存在的问题这么简单。它是一种长时刻行为，是进行组织文明贯彻和传承的一种形式和载体。评定的进程中，明确了事务责任鸿沟，规划与编码一致，优异的标准导向等研制一致。适当于经过具象化的事例，给出针对性的指导，这些都是确保团队战斗力的基石。
研制进程中的许多问题，经过代码评定机制可以被发现和处理，比方：
◦ 怎么对待暂时需求的规划与完成？
◦ 怎么看待“Hello World!”的N中写法？
◦ 怎么了解规划形式和过度规划的鸿沟？
◦ 怎么评价当时阶段的交给物？
◦ 是否有必要引进单元测验？
• 编码标准
◦ 有没有对过错进行处理？关于调用的外部服务，是否检查了返回值或处理了反常？
◦ 规划是否遵从已知的规划形式或项目中常用的形式？
◦ 开发者新写的代码能否用已有的SDK/Framework中的功用完成？在本项目中是否存在相似的功用可以调用而不用悉数从头完成？
◦ 工程中是否引进了无用的，功用重复的，不同版本的jar包依靠？（json类库，各种utils）
◦ 有没有无用的代码可以清除？
◦ 代码可读性怎么？有没有满足的注释？
◦ 参数传递有无过错，有没有使用断语（Assert）或判别来确保咱们以为不变的条件真的得到满足？
◦ 鸿沟条件是怎么处理的？ switch句子的default分支是怎么处理的？循环有没有或许呈现死循环？
◦ 对资源的利用，是在哪里申请，在哪里释放的？有无或许存在资源泄漏（包括超时时刻，内存、文件、方针引用，大方针，线程数等）？有没有优化的空间？
◦ 代码的效能怎么？最坏的状况是怎样的？
◦ 代码中，特别是循环中是否有明显可优化的部分（string的操作是否能用StringBuilder来优化）？
◦ 关于体系和网络的调用是否会超时？怎么处理?
◦ 代码是否易于测验（方法行数，圈复杂度，出入参界说是否合理）？
◦ 改动是否影响到旧版本、历史数据、上游能否兼容？
◦ 接口规划是否有考虑幂等、并发、越权，降级等问题？
◦ 是否存在缓存、数据库性能问题以及多数据源数据一致性的问题？
◦ 上线方案是否考虑了灰度方案，数据状况不一致问题？
安全上线
线上70%的毛病都是由某种变更而触发的，其间适当一部分占比是不标准的上线引起的。所以安全上线这一环节至关重要。
• 流程标准
◦ 禁止频频上线：比方，每周不大于2次；
◦ 禁止高峰期上线：下降问题影响规模；
◦ 禁止私自上线：有改动，必须经过测验验证，产品回归确认；
• 进程标准
◦ 摘流量：挑选榜首批机器jsf下线/np摘流量(选为冷备)；
◦ 看日志：调查日志确认摘除机器无流量；
◦ 服务预热：确认机器发动成功，中心事务接口需求接口预热；
◦ 挂流量：挂载上线机器流量；
◦ 看方针：调查上线机器mdc方针是否反常(cpu、内存、负载)、日志是否有反常
部署运营
完成高可用的一个很重要的手法便是才能冗余。下面给出方向和思路，详细落地细节和战略，可以根据详细状况各自延展。
• 网络
◦ 运营商层面，联通，电信，移动等；
◦ 链路节点方面，VIP，CDN，路由器/交换机，反向代理，客户端，浏览器等；
• 存储
◦ 无论是数据库主从架构，还是ES的副本架构，都是完成存储高可用的手法，重要数据要利用好相关特性；
◦ 在进行数据结构规划时，相同也需求做好分流战略，容量规划，数据拆分或异构。比方：避免缓存热key，数据库表吞吐量瓶颈，数据库连接数约束等各种影响高可用的问题呈现。
• 服务
◦ 横向扩容：服务要确保可以经过添加资源的方式进行才能扩容，这一点非常重要；
◦ 服务分组：依照事务方或使用场景，对服务进行不同粒度的阻隔，避免极点状况导致服务相互影响；
◦ 极限战略：主要是一些极点反常状况下的防护战略，目的是意外发生后，尽量坚持服务的可靠性。比方：限流，熔断，重试，快速失利等；
◦ 灰度战略：新功用上线，往往是最容易呈现问题的时候，具有成熟的流量灰度才能，是操控问题影响规模的要害；
四 运营标准确保
运营标准
-
可监控：体系运行状况
-
可报警：反常状况可以通知到体系相关人员
-
可定位：呈现问题后，可以快速定位问题原因
-
可修复：呈现反常状况，可以在榜首时刻进行问题修复；
应急预案
高可用意味着对毛病时刻的容忍性差，意味着没有时刻进行毛病排查和修复，更没有时刻打开代码进行缝隙排查。这就要求咱们有一套完备的应急预案，这套预案可以处理大部分可预见的毛病问题。
• 流程标准
◦ 恢复生产榜首；
◦ 排查问题第二；
详细事端应急处理手册，可以参照下图：
• 进程标准
◦ 网络，服务，存储分三个维度制定对应方案，并将应急预案清单（文件名：checklist）填写到自己的代码库中，坚持内容传承和更新；
◦ 可预见性，即问题触发场景要写清楚。举例：依照当时进展（1万/天），跟着数据库数据的添加，估计10个月后，数据库表（xxx表名）会呈现慢查询；
◦ 可执行性，可以消除问题的处理方案。举例：发动历史数据归档使命（xxxWorker），将历史数据进行转移到归档数据库中；
标准合格
再好的流程和标准都需求有对应的机制来贯彻执行，不然便是镜中花，水中月，看着夸姣，实则没用。可执行，能度量，是依照方针变好的条件。所以这儿给出一个《高可用合格定时自查表》的工具，辅佐标准落地。
五 总结
本文从“高可用为什么存在着很大应战？”的问题打开探讨，强调了需求交给进程中，协作功率的重要性，并指出了为什么要遵从“今日事，今日毕”的工作准则。又从架构规划，编码完成，安全上线，部署运营等几个方面，详细介绍了技能落地确保相关的指导标准和落地细节。最后又从上线后运营的视点，给出了应急预案三板斧，标准合格定时自查表等比较有用的运营确保工具。期望可以给读者带来帮助。
本文正在参加「金石方案」
