松耦合和紧耦合的架构设计、性能对比


  • 如果要在计算器的业务逻辑加上其他操作符运算,能否不影响原来的业务逻辑?这时可以用继承、多态的面向对象思想方法把各种操作符分开不同的类,如果要改动或增加删除某一个操作符,都不会影响其他操作符,这就进一步降低了耦合度。
    先说紧耦合,这种架构是我们在Laxcus 0.x、1.x中采用的。紧耦合架构本质是一个Client/Server模型。客户机发起请求给服务器,服务器收到,根据请求做出应答,然后反馈给客户机。这种架构最典型的应用就是我们每天都用到的WEB服务。优点嘛,就是简单。架构简单、设计简单、开发周期短、能够快速投入部署和应用。在Laxcus集群的早期运行中,这些特点都得到有力的验证。
    但是到了后期,随着Laxcus集群规模的不断扩大,访问量的不断增加,尤其是数据计算量、计算时间成倍数的增长后,紧耦合架构渐渐不堪重负,缺点开始不断暴露出来,主要有以下几个方面:无法支持大规模的计算业务;计算机载荷无法控制;任务执行过程中管理难度大;对网络资源消耗大;安全控制力度差;程序代码之间关联度过高,不利于模块化处理;以上现象最终导致系统稳定性变差。
    这些问题出现后,我们开始考虑修改系统设计。经过多番考量、比较、权衡之后,我们决定改用松耦合架构重新规划系统设计。新框架是在原来Client/Server模型之上的改进,即在Client/Server模型之间加入一个代理(Agent),把CS模型变成CAS模型。在新的架构下,客户机的角色不变,代理服务器承担起与客户机通信,和对客户机的识别判断工作,服务器位于代理服务器后面,对客户机来说不可见,它只负责数据处理工作。另外我们也把CS模型的同步操作改为CAS的代理处理。    在设计新架构的同时,我们还发现,如果要适应松耦合架构,原来在紧耦合架构下运行的程序代码,因为现在的工作方式发生了发生了变化,它们几乎都要重写。这可是一个庞大的工程,需要消耗大量的人力、时间去修改和调试。所以我们在松耦合架构之上,结合代理服务器,又设计了一套Invoke/Produce机制。这是另一种代理方案,是针对数据处理进行抽象化处理和分组分级管理。原来的数据处理和业务逻辑套用这套机制后,程序代码基本不用修改,转移到CAS模型上运行就可以了。1c8d198c-af4f-4ae1-872f-a981168d5465-image.png ca40d398-2be7-4863-8c81-2790e9227ac3-image.png