双机热备工作模式及高内聚低耦合架构解释

简介:

双机热备份技术是一种软硬件结合的较高容错应用方案。
该方案是由两台服务器系统和一个外接共享磁盘阵列柜 ( 也可没有,而是在各自的服务器中采取 RAID 卡 ) 及相应的双机热备份软件组成:

在这个容错方案中,操作系统和应用程序安装在两台服务器的本地系统盘上,整个网络系统的数据是通过磁盘阵列集中管理和数据备份的。数据集中管理是通过双机热备份系统,将所有站点的数据直接从中央存储设备读取和存储,并由专业人员进行管理,极大地保护了数据的安全性和保密性。用户的数据存放在外接共享磁盘阵列中,在一台服务器出现故障时,备机主动替代主机工作,保证网络服务不间断。

双机热备份系统采用 “ 心跳 ” 方法保证主系统与备用系统的联系所谓 “ 心跳 ” ,指的是主从系统之间相互按照一定的时间间隔发送通讯信号,表明各自系统当前的运行状态。一旦 “ 心跳 ” 信号表明主机系统发生故障,或者备用系统无法收到主机系统的 “ 心跳 ” 信号,则系统的高可用性管理软件认为主机系统发生故障,主机停止工作,并将系统资源转移到备用系统上,备用系统将替代主机发挥作用,以保证网络服务运行不间断。

双机热备方案中,根据两台服务器的工作方式可以有三种不同的工作模式: 
1)双机热备模式
2)双机互备模式
3)双机双工模式

下面对这三种模式分别介绍:

1
2
3
4
5
6
7
8
9
10
1)双机热备模式---即目前通常所说的 active /standby  方式
active 服务器处于工作状态;而 standby 服务器处于监控准备状态,服务器数据包括数据库数据同时往两台或多台服务器写入 ( 通常各服务器采用 RAID 磁盘阵列卡 ) ,保证数据的即时同步。当 active 服务器出现故障的时候,
通过软件诊测或手工方式将 standby 机器激活,保证应用在短时间内完全恢复正常使用。典型应用在证券资金服务器或行情服务器。这是目前采用较多的一种模式,但由于另外一台服务器长期处于后备的状态,从计算资源方面考量,
就存在一定的浪费。
 
2)双机互备模式
是两个相对独立的应用在两台机器同时运行,但彼此均设为备机,当某一台服务器出现故障时,另一台服务器可以在短时间内将故障服务器的应用接管过来,从而保证了应用的持续性,但对服务器的性能要求比较高。配置来说相对简单点。
 
3)双机双工模式 :
是目前 cluster(群集) 的一种形式,两台服务器均为活动,同时运行相同的应用,保证整体的性能,也实现了负载均衡和互为备份,需要利用磁盘柜存储技术 (最好采用San 方式) 。 WEB服务器或FTP服务器等用此种方式比较多。

-------------------------------------------高内聚、低耦合架构说明-------------------------------------

1
2
3
4
5
6
7
8
9
10
11
12
13
14
在运维系统架构中,一般都会追求高内聚,低耦合的设计,这样的环境对后期管理、开发使用、安全维护等都是十分有利的。下面就对这两个概念做一简单介绍:
高内聚低耦合:是软件工程中的概念,是判断设计好坏的标准,主要是面向对象的设计,主要是看类的内聚性是否高,耦合度是否低。
1)高内聚
内聚就是一个模块内各个元素彼此结合的紧密程度,高内聚就是一个模块内各个元素彼此结合的紧密程度高。 所谓高内聚是指一个软件模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一责任原则。
  
2)低耦合
耦合:一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差,模块间耦合的高低取决于模块间接口
的复杂性,调用的方式以及传递的信息。 )对于低耦合,粗浅的理解是: 一个完整的系统,模块与模块之间,尽可能的使其独立存在。 也就是说,让每个模块,尽可能的独立完成某个特定的子功能。模块与模块之间的接口,尽量的少而简单。如果某两个模块间的关系比较复杂,最好首先考虑进一步的模块划分。 这样有利于修改和组合。
  
3)为什么要追求高内聚和低耦合
软件架构设计的目的简单说就是在保持软件内在联系的前提下,分解软件系统,降低软件系统开发的复杂性,而分解软件系统的基本方法无外乎分层和分割。但是在保持软件内在联系的前提下,如何分层分割系统,分层分割到什么样的粒度,并不是一件容易的事,这方面有各种各样的分解方法,比如:关注点分离,面向方面,面向对象,
面向接口,面向服务,依赖注入,以及各种各样的设计原则等,而所有这些方法都基于高内聚,低耦合的原则。 高内聚和低耦合是相互矛盾的,分解粒度越粗的系统耦合性越低,分解粒度越细的系统内聚性越高,过度低耦合的软件系统,软件模块内部不可能高内聚,而过度高内聚的软件模块之间必然是高度依赖的,因此如何兼顾高内聚和
低耦合是软件架构师功力的体现。高内聚,低耦合的系统有什么好处呢?事实上,短期来看,并没有很明显的好处,甚至短期内会影响系统的开发进度,因为高内聚,低耦合的系统对开发设计人员提出了更高的要求。高内聚,低耦合的好处体现在系统持续发展的过程中,高内聚,低耦合的系统具有更好的重用性,维护性,扩展性,可以更高
效的完成系统的维护开发,持续的支持业务的发展,而不会成为业务发展的障碍。
***************当你发现自己的才华撑不起野心时,就请安静下来学习吧***************
本文转自散尽浮华博客园博客,原文链接:http://www.cnblogs.com/kevingrace/p/6244549.html ,如需转载请自行联系原作者
相关文章
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
1月前
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
162 6
|
1月前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
75 2
|
1月前
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
66 2
|
1月前
|
存储 缓存 监控
探索微服务架构中的API网关模式
【10月更文挑战第1天】探索微服务架构中的API网关模式
93 2
|
21天前
|
缓存 监控 API
探索微服务架构中的API网关模式
随着微服务架构的兴起,API网关成为管理和服务间交互的关键组件。本文通过在线零售公司的案例,探讨了API网关在路由管理、认证授权、限流缓存、日志监控和协议转换等方面的优势,并详细介绍了使用Kong实现API网关的具体步骤。
41 3
|
21天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
探索微服务架构中的API网关模式
40 2
|
2月前
|
JSON 监控 安全
探索微服务架构中的API网关模式
【9月更文挑战第22天】在微服务架构的海洋中,API网关如同一位智慧的守门人,不仅管理着服务的进出,还维护着整个系统的秩序。本文将带你一探究竟,看看这位守门人是如何工作的,以及它为何成为现代云原生应用不可或缺的一部分。从流量控制到安全防护,再到服务聚合,我们将一起解锁API网关的秘密。
|
3月前
|
分布式计算 负载均衡 API
微服务架构设计原则与模式
【8月更文第29天】随着云计算和分布式计算的发展,微服务架构已成为构建大型复杂应用的一种流行方式。这种架构模式将单个应用程序分解成一组小型、独立的服务,每个服务运行在其自己的进程中,并通过轻量级机制(通常是HTTP资源API)进行通信。本文将探讨微服务架构的基本设计原则、常用模式以及如何有效地划分服务边界。
355 3
|
3月前
|
弹性计算 Kubernetes Serverless
Kubernetes 的架构问题之Serverless Container中不支持特权模式的问题如何解决
Kubernetes 的架构问题之Serverless Container中不支持特权模式的问题如何解决
91 6
下一篇
无影云桌面