构建高可用系统的常用招数

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了构建高可用系统的常用招数，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4555字，纯文字阅读大概需要7分钟。

内容图文

互联网等系统对于可用性都非常的重视，构建一个高可用的系统，有些常用的招数，在这里简单的说下，其实多数都是靠各互联网公司在实战中摸爬滚打积累出来的“血泪”经验。 1. 监控和报警 没有监控和报警的在线系统，就像是开着一辆没有仪表盘的车一样，因此如

互联网等系统对于可用性都非常的重视，构建一个高可用的系统，有些常用的招数，在这里简单的说下，其实多数都是靠各互联网公司在实战中摸爬滚打积累出来的“血泪”经验。

1. 监控和报警
没有监控和报警的在线系统，就像是开着一辆没有仪表盘的车一样，因此如果没有监控和报警，其他一切都是浮云，这点说起来容易，做起来却是比较折腾的，例如监控点需要有哪些，怎么报警是合适的。

这个的评估比较容易，就是故障发生是不是都是监控和报警先发现的，故障发现率是衡量这件事做的咋样的一个不错的指标。

2. SPoF(Single Point of Failure)
这是高可用系统中最不允许的现象，应用如果只部署在一台机器上，就意味着只要这台机器出现问题，就不可用了，为了避免这个问题，通常会采用cluster、主备的方式，实在不好做的情况下才用主备，例如带状态的DB等，而对于不带状态的，最好还是用cluster的方式，因为主备方式实现较麻烦，另外不具备伸缩性。

单台机器这只是SPoF中的一个狭义的点，更放大看还会有单框机器（如果是刀框的话）、单个机柜、单个网络核心路由、单个机房、单个城市，可见一个真正的高可用系统要解决的技术问题是不少的，并且是要付出较高的成本的。

3. 解耦
业务逻辑在实现上总是会有很多关键的逻辑，还有一些附加的逻辑，例如在做完操作后要发个短信通知什么的，如果把这些逻辑也放到主逻辑过程中一起实现，可能会出现的问题就是这些边缘逻辑出问题，然后导致主逻辑挂了，因此在实现系统时需要做一定的解耦，关键的逻辑同步完成，而非关键逻辑则通过异步的消息系统来完成，这是在设计高可用系统时一个非常关键的点。

除了后端这种实现的解耦外，前端页面的构成其实也需要考虑好解耦，例如一个页面上，有些内容即使不显示也不会出什么问题的，对于这些内容应该通过ajax等方式来实现和主要内容解耦。

4. 隔离
一个业务系统，必然会涵盖多种多样的功能，而这些功能中必然会有重要的和不重要的，例如上面解耦后页面上有些不重要的内容会通过ajax来异步获取，而如果这个不重要的内容的生成和重要的内容生成是同一个系统的话，有可能会出现不重要的内容生成的代码处理慢，从而导致把共同的处理线程池的所有线程耗满。

为了解决这个问题，通常可以采用两种办法，一是拆分系统，直接把重要的和不重要的拆成两个应用，二是通过七层路由来分到不同的机器上，也可以是域名，这样系统仍然是同一个，七层路由对性能损害很大，慎用（除非是类似基于zk实现的软负载，然后在客户端执行的七层路由）。

除了重要功能和不重要功能外，还会出现耗资源和相对不怎么耗资源（包括很多种，例如DB连接..）、给重要用户和普通用户，对于这些情况，都需要采用上面的两种办法来做到隔离。

5. 容灾
一个在线运行的系统，不可避免的要面对各种灾难事件，而一个高可用的系统，必须做到在各种灾难事件面前坚挺的活着，为了做到这个，需要有N多的措施。

通常系统都会依赖到其他的一些系统，而这个时候首先要做的就是超时控制，看过N多的case，都是由于没有设置超时时间，从而在依赖的系统响应变慢的情况下，自己的系统的所有处理线程也被拖S的现象，因此所有的阻塞的wait的地方都一定要是带超时的，在线系统更能接受的是失败，响应慢绝对是在线系统的噩梦。

除了超时外，在代码的实现上需要做一些自动降级的策略，有些时候调用的这个后端系统可能不是那么关键的逻辑，那么在这种情况下，应支持自动的降级，当后端系统出现超时等问题的时候，直接忽略掉，例如很多应用都会有待读的消息数，当读不到的时候，其实不显示关系也不大，因此此时可以自动降级掉。

除了自动降级外，还需要有多种手动降级的策略，例如一个页面上的很多功能点都需要支持手工关闭的开关，这样可以在某些系统出现问题，或压力大时可以直接关闭掉，降低系统压力，一种典型的例子是例如高清晰的图片会消耗掉很多的带宽，如果带宽紧急的情况下，应该支持显示更低质量一点的图片，当然，这是有一定损害的降级，但相比系统全挂，显然是这个方式好。

自恢复能力也是系统设计时的重要考虑点，例如当依赖的系统出问题到恢复后，系统本身也要能自恢复，例如一个最简单的是依赖的一个系统挂了，不能说还得重启系统本身才能恢复。

自我保护能力是容灾中的重要点，例如需要处理的请求超过了处理能力，那这个时候应该拒绝，要做到这点，必须首先知道系统的处理能力到底是多少（小声的说一句：所有的模拟的压力测试都是无法反应系统的处理能力的，要拿到系统的处理能力必须是用真实的访问来测试，原因是数据、用户行为其实是无法模拟的或者说难度非常非常的高），除了处理能力的保护外，还应该做负载层面的保护，以避免某些情况下即使在处理能力范围内，负载出现飙高导致无法登陆机器处理故障的现象。

除了上面说的这些系统层面的策略外，容灾还需要考虑机房层面的容灾、地域的容灾。

从上面5点来说，要做到一个高可用的系统真心不容易，从编程技巧、系统设计以及基础设施（IDC）建设都需要作出巨大的努力，并且要付出巨大的成本，而对于一个高访问量的大规模系统而言，基本上所有认为不太可能发生的事其实都是会发生的，如果没有准备好的话，瞬间可用率就会大幅损失。

原文地址：构建高可用系统的常用招数, 感谢原作者分享。

内容总结

以上是互联网集市为您收集整理的构建高可用系统的常用招数全部内容，希望文章能够帮你解决构建高可用系统的常用招数所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端