耦合,松耦合,紧耦合

本文探讨了紧耦合与松耦合架构的区别,分析了紧耦合架构在大规模并行计算中的局限性,并详细介绍了如何通过引入代理服务器和采用异步通讯机制来优化系统设计,从而提高系统的稳定性和安全性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

什么是耦合?

模块间的依赖性就是耦合,两个功能函数之间的依赖程度

如五个人共同开发一个模块,应该尽量松耦合,就是联系越小越好,这样一个模块变动,另一个模块就不会变动

 

松耦合的方法,一般是底层函数,功能尽量单一,尽量避免修改底层函数,功能相近的函数,可以设计两个以上,不要为了减少代码量,把一个函数的功能设计太多

 

松耦合系统通常是基于消息的系统,此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配,只要消息符合协商的架构,则客户端或服务的实现就可以根据需要进行更改,而不必担心会破坏对方

 

松耦合通讯机制提供了紧耦合机制所没有的许多优点,并且他们有助于降低客户端和远程服务之间的依赖性。但是,紧耦合性通常可以提供性能的好处,便于在客户端和服务之间进行更为紧密的集成(这在存在安全性和事务处理要求时,可能是必须的)

 

紧耦合架构本质是一个client/server模型,客户机发起请求给服务器,服务器收到,根据请求做出回答,然后反馈给客户机。这种架构最典型的应用就是我们

每天都用到的web服务。优点嘛,就是简单。架构简单、设计简单、开发周期短、能够快速投入 部署和应用。在Laxcus集群的早期运行中,这些特点都得到有力的验证。

紧耦合架构

但是到了后期,随着laxcus集群规模的不断扩大,访问量的不断增加,尤其是数据计算量、计算时间成倍数的增长后,紧耦合架构渐渐不堪重负,缺点开始不断暴露出来

1、无法支持大规模的计算业务,因为大数据业务对计算机资源占比普遍很大,导致多任务并行能力有限,举个例子,我们曾在一台Pentium IV 2.G+2G的机器上测试一项小规模的数据处理业务,当并行任务量达到100多个的时候,计算机已经发生超载现象

2、计算机载荷无法控制,换句话说,就是计算机不能控制超载现象,而超载对硬件伤害非常大,这会严重降低计算机稳定运行能力和使用寿命

3、任务执行中管理难度大,任务在执行过程中不受管控

4、对网络资源消耗大,同步操作在数据发送和数据返回之间,有很大一段是空闲的,这种空闲占用是对网络资源的极大浪费

5、安全控制力度差,因为服务器直接暴露给客户机,容易引发网络攻击行为

6、程序代码之间关联度过高,不利于模块化处理

7、以上现象最终导致系统稳定性变差

这些问题出现后,我们开始考虑修改系统设计,经过多番考量、比较、权衡之后,我们决定改用松耦合架构重新规划系统设计。新框架是在原来client/server模型之上的改进,即在client/server模型之间加入一个代理,把CS模型变成CAS模型,在新的架构下,客户机的角色不变,代理服务器承担起与客户机的通信,和对客户机的识别判断工作,服务器位于代理服务器后面,对客户机来说不可见,它只负责数据处理工作,另外我们也把CS模型的同步操作改为CAS的代理处理

在设计新架构的同时,我们还发现,如果要适应松耦合架构,原来在紧耦合架构下运行的程序代码,因为现在的工作方式发生了变化,它们几乎都要重写,这是一个庞大的工程,需要消耗大量的人力,时间去修改和调试。所以我们在松耦合架构之上,结合代理服务器,又设计了一套invoke/produce机制,这是另一种代理方案,是针对数据处理进行抽象化处理。原来的数据处理和业务逻辑套用这套机制后,程序代码几乎不用修改,转移到CAS模型上运行就可以了

松耦合架构

新架构设计和代码修改完成后,我们在原来的集群上,和紧耦合架构做了各种对比测试。结果表现是出其的好,不仅解决了紧耦合架构上存在的所有问题,而且其中很多技术指标还超出了我们的预估,主要表现以下一些方面

1、多任务并行处理能力获得极大提升。同样是上述那个数据处理,紧耦合架构只能支持最大约100多个并行,而转到松耦合架构上,达到了8700多个,这还只是在Pentium IV 2.0芯片上的表现,放到Core 2平台,并行处理任务很轻松地超过10000个

2、实现负载自适应机制(根据当时运行环境,松耦合架构分配并行工作任务,避免超载现象)

3、实现了运行任务的随机控制(松耦合架构对运行中的工作任务进行随机调整和控制,进一步避免了持续超载现象)

4、基本杜绝了网络攻击行为,由于代理服务器的隔绝和筛查作用, 同时结合其它安全管理手段,外部攻击在代理服务器处就被识别和过滤掉了,这样就保护了后面的服务器不受影响

5、Invoke/Produce机制改善了程序结构的模块化,有利于实现复杂的数据业务处理

6、异步操作减少了网络资源消耗和操作关联

7、综合以上措施,他们共同增强了系统稳定性

 

最后用一张表对两种架构做个对比,作为两种架构性能特点的总结

 

紧耦合架构

松耦合架构

工作方式

同步

异步

程序关联依赖

业务逻辑关系

集中控制

分散控制

设计难度

容易

比较复杂

响应能力

和并行工作量成反比

时效表现

实时

无要求

业务适用范围

简单计算

复杂计算

安全

应用领域

小规模并行处理环境

大规模、超大规模并行处理环境

系统稳定性

 

转载于:https://www.cnblogs.com/z-x-y/p/9230856.html

### 视觉惯性里程计中的耦合耦合 #### 耦合原理 在视觉惯性里程计(VIO)中,耦合是指将相机和惯性测量单元(IMU)的数据在一个统一的状态估计框架下进行联合优化。这种融合方式通常采用扩展卡尔曼滤波器(EKF)、无迹卡尔曼滤波器(UKF)或者基于图优化的方法来处理多模态数据。具体来说,在耦合方法中,相机观测到的特征点位置被作为约束条件引入状态向量中,而IMU则提供连续的时间动态模型更新[^3]。 这种方法的优势在于它能充分利用两种传感器之间的互补特性——摄像头提供了精确的空间几何信息,而IMU能够在短时间内给出高频的姿态变化预测。因此,即使是在光照剧烈变化或运动模糊严重的环境中,系统仍然可以通过IMU保持较好的鲁棒性和精度[^1]。 #### 耦合原理 相比之下,耦合则是分别独立运行两个子模块:一个是纯视觉SLAM部分负责构建地图并跟踪轨迹;另一个是单独依靠IMU完成短期内的姿态推算。之后再把两者的结果结合起来校正彼此可能存在的误差累积问题。例如,当视觉SLAM检测到了闭环时,则可以用此修正之前由积分漂移引起的偏差[^2]。 这种方式实现起来相对简单直观,并且由于各组件之间相互隔离的关系使得调试更加方便快捷。然而缺点也很明显,因为缺乏深层次的信息交互机制,所以整体性能往往不如前者那样稳定可靠特别是在快速移动场景下容易受到较大影响[^4]。 #### 主要区别总结 | 方面 | **耦合** | **耦合** | |--------------|-----------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------| | 数据融合层次 | 在同一状态估计框架内直接融合 IMU 和相机原始数据 | 各自独立计算后再组合最终结果 | | 计算复杂度 | 较高 | 较低 | | 鲁棒性 | 更强,尤其适合高速动态环境 | 较弱,易受单一传感器失效的影响 | | 实现难度 | 复杂,需设计复杂的非线性优化算法 | 简单,易于开发 | ```python # 示例代码展示如何设置 EKF 的状态转移矩阵 (仅用于说明概念) import numpy as np def ekf_state_transition_matrix(delta_t, g=np.array([0., 0., -9.8])): F = np.eye(15) # 假设状态维度为15维 F[:3, 3:6] = delta_t * np.eye(3) # 更新位置相对于速度的变化关系 F[3:6, 6:9] = delta_t * np.eye(3) # 更新速度相对于加速度的变化关系 return F ``` 上述 Python 片段展示了定义一个简单的扩展卡尔曼滤波器所需的部分操作逻辑,其中涉及了时间步长 `delta_t` 对应的动力学方程建模过程。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值