如何开发高可用的IT系统

发布网友 发布时间：2022-04-22 01:43

我来回答

共2个回答

热心网友 时间：2022-04-09 21:11

我认为要想构成每一层的高可用性，三个点缺一不可，但在我们的实际系统运营建设中，却往往只会关注可以实现高可用性的系统架构，认为有一个完善的高可用性架构就能一劳永逸，“实现”了系统的高可用性，这是错误的想法，因为不存在永不发生故障的系统的。但没有不发生故障的系统并不意味着无计可施，如何缩短故障处理时间是靠高可用性的另外两个支架支撑的：保障手段和运维制度。通过保障手段监控到故障发生，而不是靠使用者投诉系统不可用，就可以大幅缩短故障对业务的影响，如果架构很合适，切换到备用系统上，甚至可以让用户感觉不到故障的发生。通过运维制度将影响系统高可用性的隐患纳入到日常管控中，从根本上避免故障的发生，这其中包括要对故障解决手段定期进行演练等。下面就一层层论述自己的认识。
基础设施层：简单地说，就是硬件，包括网络设备、存储设备、计算设备等等。这一层上，架构设计的要点是——冗余，比如尽可能多的在线设备，比如在磁盘阵列上采用raid0+1等，一方面分担负荷，另一方面也防止设备故障后，修复时中断系统运行，但从投资的角度而言，少有公司把自己的硬件设备会一模一样的复制出一套来，因此如何权衡、如何最终消除单点隐患是在这一层架构设计的核心；这一层的保障手段，从我接触到维护人员多采用定时巡检手段，如观察设备的显示灯，抓取系统日志等，发现设备出现某些告警和损坏，尽快安排备品备件进行更换等，而监控系统在这一过程中发挥的作用有限，在故障发生时，往往采用重启，甚至是断电重启的方式恢复设备运行；这一层的运维制度除了安排好定时巡检，对于基础设施的信息要通过CMDB进行管控，收集设备的告警信息进行分析，及时调整设备的运行状态等。
操作系统层：我有时认为这个层面可以和基础设施层合并，因为无论是网络设备还是存储设备，其实都是有操作系统的，只是被固化到硬件上（这是否是“固件”一词的来历？），所以从架构设计而言，这一层的冗余是和设备同步进行的，但随着虚拟化和云资源池的使用，这一层也有一些变化，限于篇幅不赘述。在保障手段上，对操作系统的监控就成熟许多了，成熟的操作系统都开放了标准接口，可以让第三方监控系统进行监控，但操作系统的故障解决手段只能是重启，甚至是断电重启；这一层的运维制度则是安排好作业计划，根据监控及时对系统核心目录，如IO操作目录等进行管理，在官方发布补丁包后及时更新，并在CMDB中登记等，要关注安全。
第三方软件层：这一层是产品化的软件，如数据库、中间件等。这一层上，架构设计的要点还是冗余和备份，只是由于软件产品的特点，其冗余方式更容易进行，但也更受应用系统层面的影响，因此，这一层的架构设计需要应用软件的系统架构师、数据库架构师等全面考虑，充分利用产品化软件的特点合理设计架构，由于数据库在这一层上，并且对于IT系统而言，数据是绝不能丢失的，因此架构设计上一定要考虑数据备份；在保障手段上，监控系统的作用发挥更大，对于数据库的表空间、核心进程监控都很成熟了，要充分利用监控系统，合理设定告警值，当故障发生时，如果确认是本层的软件产品引发的，故障解决手段也多采用重启软件产品，或者通过恢复初始设置来解决等；在维护制度上，要利用监控系统安排作业计划，要及时更新软件产品的版本、补丁包等，要将软件产品的各种参数保存到CMDB中，要做好完善的数据备份。
应用系统层：这一层才是我们提供给使用者使用的系统，没有前面各层的高可用性支撑，这一层的高可用性绝对是空中楼阁。应用系统层的高可用性架构设计往往是根据应用决定的，有的系统是基于中间件产品，那它可以和第三方软件层在架构设计时结合考虑，但也有的系统是自行搭建了应用架构，如何通过从架构上确保高可用性没有定论，但主导思想依然是冗余；在保障手段方面，仍然是通过监控系统，有些较为成熟的应用软件系统会配套监控系统，有的定制软件则可以开放系统进行监控，但监控对象主要是业务数据流，无论产品软件还是定制软件，故障发生后，重启已经没有太大作用，往往需要维护人员定位故障进行解决，尤其是一些大公司使用的定制软件，除了功能性bug，还有数据错误引发的故障，这往往需要专业维护人员进行处理解决；在维护制度上，主要是对需求变更管理更为严格，避免程序更新如果没有经过仔细的测试和验证就上线，对于知识库更新、维护人才队伍的培养与下三层不一样。

热心网友 时间：2022-04-09 22:29

废气污水澄释lueqiangr473