谈谈高可用架构和系统设计

这个话题可能铺开来谈有许多方向可以研究，所以面试会经常遇到这样的问题，用来考察一个人的知识广度，除此之外多看看也有助于我们平时设计系统时考虑问题更全面。

1. 高可用的定义
2. 哪些情况可能会导致系统不可以用？
3. 有哪些提高系统可用性的方法？

图片来自：https://www.51cto.com/article/743179.html

什么是高可用？可用性的判断标准是什么？

高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务。高可用代表系统及时在发生硬件故障或者系统升级的时候，服务仍然是可用的。

一般情况下，使用多少个9来评判一个系统的可用性，比如99.9999%就是代表该系统在所有的运行时间中只有0.0001%的时间是不可用的，这样的系统就是非常非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连9都上不了。

一句话来表述就是：高可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。

高可用的设计思想

高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考量和设计，高可用系统的设计思想包括但不限于：

• 做好研发规范，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准
• 做好容量规划和评估，主要是让开发人员对系统要抗住的量级有一个基本认知，方便进行合理的架构设计和演进。
• 做好服务层面的高可用，主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。
• 做好存储层面的高可用，主要是冗余备份（热备、冷备）、失效转移（确认，转移，恢复）等。
• 做好运维层面的高可用，主要是发布测试、监控告警、容灾、故障演练等。
• 做好产品层面的高可用，主要是兜底策略。
• 做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大。

哪些情况会导致系统不可用？

1. 黑客攻击
2. 硬件故障，比如服务器坏掉
3. 并发量/用户请求量激增导致整个服务挂掉或者部分服务不可用
4. 代码中的坏味道导致内存泄漏或者其他问题是程序挂掉
5. 网站架构某个重要的角色比如Nginx或者数据库突然不可用
6. 自然灾害或者人为破坏，比如停电等
7. ·······

有哪些提高系统可用性的方法？

1.注重代码质量，测试严格把关

代码质量是最重要的，代码质量问题比较常见的有内存泄漏、循环依赖都是对系统可用性的极大损害。大家都喜欢谈限流、降级、熔断，但是我觉得从代码质量这个源头把关是首先要做好的一件很重要的事情。如何提高代码质量？比较实际可用的就是CodeReview，不要在乎每天多花的那1个小时左右的时间，作用很大，值得认真去review。

另外，安利这个提高代码质量有实际效果的宝贝：

1. sonarqube：保证你写出更安全更干净的代码
2. Alibaba开源的Java诊断工具Arthas也是很不错的选择
3. IDEA自带的代码分析工具进行代码扫描也是非常非常棒的。

2.使用集群，减少单点故障

例如redis，如何保证我们的Redis缓存高可用？答案就是使用集群，避免单点故障。当我们使用一个Redis实例作为缓存的时候，这个Redis实例挂了之后，整个缓存服务可能就挂了。使用了集群之后，即使一台Redis实例，不到一秒就会有另外一台Redis实例顶上。

3. 限流

流量控制，原理是监控应用流量的QPS或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

4.超时和重试机制设置

一旦用户请求超过某个时间得不到响应，就抛出异常。这个很重要，很多系统的线上故障就是因为没有进行超时设置或者超市设置方式不对导致的。我们再读取第三方服务的时候，尤其适合设置超时和重试机制。一般我们使用一些RPC框架的时候，这些框架都自带的超时重试的配置。如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法在处理请求。重试的次数一般为3次，再多的重试也没有好处，反而会增加服务器的压力（部分场景使用失败重试机制不太合适）。

5.熔断机制

超时和重试机制设置之外，还有熔断也很重要。熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所以来的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。比较常用的是流量控制和熔断降级框架是Netflix的Hystrix和Alibaba的Sentinel。

6.异步调用

异步调用的话我们不需要关心最后的结果，这样就可以在用户请求完立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。但是，使用异步之后我们可能需要适当修改业务流程进行配合，比如用户在提交订单之后，不能立即返回订单提交成功，需要在消息队列的订单消费进程真正处理完该订单之后，甚至出库之后，再通过电子邮件或者短信通知用户订单成功。出了可以在程序中实现异步之外，常常还使用消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应时间所需时间）并且可以降低系统耦合性。

7.使用缓存

如果我们的系统属于并发量比较高的话，如果单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用系统缓存热点数据，因为缓存存储在内存中，所以速度相当的快！

8.其他

1. 核心应用和服务优先使用更好的硬件
2. 监控系统资源使用情况增加报警设置
3. 注意备份，必要时回滚
4. 灰度发布：将服务器集群分成若干部分，每天只发布一部分机器，观察运行稳定没有故障，第二天继续发布一部分机器，持续几天才把整个集群发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
5. 定期检查/更换硬件：如果不是购买的云服务的话，定期还是需要对硬件进行一波检查的，对于一些需要更换或者升级的硬件，要及时更换升级
6. ·······

参考资料：https://dunwu.github.io/design/pages/9a462f/#%E9%AB%98%E5%8F%AF%E7%94%A8%E6%9E%B6%E6%9E%84%E7%AE%80%E4%BB%8B

https://www.51cto.com/article/743179.html