什么是耦合？
模块间的依赖性就是耦合，两个功能函数之间的依赖程度
如五个人共同开发一个模块，应该尽量松耦合，就是联系越小越好，这样一个模块变动，另一个模块就不会变动
松耦合的方法，一般是底层函数，功能尽量单一，尽量避免修改底层函数，功能相近的函数，可以设计两个以上，不要为了减少代码量，把一个函数的功能设计太多
松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配，只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方
松耦合通讯机制提供了紧耦合机制所没有的许多优点，并且他们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能的好处，便于在客户端和服务之间进行更为紧密的集成（这在存在安全性和事务处理要求时，可能是必须的）
紧耦合架构本质是一个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、综合以上措施，他们共同增强了系统稳定性
最后用一张表对两种架构做个对比，作为两种架构性能特点的总结
| 紧耦合架构 |
松耦合架构 |
|
| 工作方式 |
同步 |
异步 |
| 程序关联依赖 |
强 |
弱 |
| 业务逻辑关系 |
集中控制 |
分散控制 |
| 设计难度 |
容易 |
比较复杂 |
| 响应能力 |
快 |
和并行工作量成反比 |
| 时效表现 |
实时 |
无要求 |
| 业务适用范围 |
简单计算 |
复杂计算 |
| 安全 |
弱 |
强 |
| 应用领域 |
小规模并行处理环境 |
大规模、超大规模并行处理环境 |
| 系统稳定性 |
弱 |
强 |
| 紧耦合架构 |
松耦合架构 |
|
| 工作方式 |
同步 |
异步 |
| 程序关联依赖 |
强 |
弱 |
| 业务逻辑关系 |
集中控制 |
分散控制 |
| 设计难度 |
容易 |
比较复杂 |
| 响应能力 |
快 |
和并行工作量成反比 |
| 时效表现 |
实时 |
无要求 |
| 业务适用范围 |
简单计算 |
复杂计算 |
| 安全 |
弱 |
强 |
| 应用领域 |
小规模并行处理环境 |
大规模、超大规模并行处理环境 |
| 系统稳定性 |
弱 |
强 |