架构解耦

转载 2015年08月29日 17:09:33
转载:http://blog.chinaunix.net/uid-26443921-id-3409745.html
的开发来说都是知道的,实际开发中也会或多或少的解除或者使用过;
但系统架构之间的解耦恐怕一般人很少接触,换种说法就是一般人很少有架构解耦的概念和思想;
一方面是因为很少有书文章讲怎样做架构,恐怕也很难做架构,另外一方面一个项目中真正做全局架构的
人一般只有一个,很多人根本接触不到;
顶层架构往往决定了项目技术要素的成功与否,好的架构一定看起来是很漂亮的,就像一件精美
的艺术品,来源于架构者深刻的修养和沉淀之久的经验;

解耦对于代码的精简和美丽是至关重要,同理,解耦对于架构的优美和稳定更是重之又重!

广播
例:就拿此篇博客的提交到服务器这一服务器程序来说,数据提交到服务器,假设用php实现,
php插入数据库,然后插入一条待审核记录到admin之类的数据库(如果不知道审核是啥玩意,那你肯定没
有在天朝做过互联网产品后台开发);
看起来非常合理也简洁的一个架构。假设现在要增加一个需求:文章发布后,要发邮件或者发信息
通知订阅我的博客的用户有新文章发布,于是开发人员毫不犹豫的修改了发布程序,最简单的做法就是在
程序后面加上“订阅发送”这一功能实现--查询订阅关系数据库,然后一一发送邮件或信息;好像很快完成
了需求,只是程序看起来有点变味了;
过了两天,新的需求又来了,比如:要求文章发布后,需要由编辑挑选出质优的放到网站网页展
示,比如:要求文章发布后,需要立即通知搜索引擎更新数据,以方便搜索引擎立即能搜出新文章!!

于是,随着需求越来越多,越来越杂,这个程序改动的版本越来越多,代码行数越来越长,越来越
多的业务逻辑集中到了这个程序里面,然后发现这个程序变成了个大染缸,什么都有,维护的人感觉越来越
恶心,用户反应发系统响应度越来越慢;甚至过了一段时间,你会发现:呃,怎么有些已经废弃的业务代码
还存在;另外,有时开发会感觉非常为难:有些一次性的需求也要放到这里面,比如:需要搞个活动,比如
这个月要搞个发表文章大赛;这种一次性需求明显只需要出现一个月即可,一个月后,即可删除!!

这种情况在经历中的项目中出现的太多太多了,开始看起来很简洁很健康的架构和代码随着需求味
道变得越来越坏,终于一天失去了控制,没人去维护,没人完全懂这个繁杂的业务程序到底做了多少事情!

关键点在于:这里的架构确实有比较大的问题,正确的可高度扩展的且不影响主业务流程的架构
还是解耦,目标很清晰:将不相干的功能全都剥离出去,发表文章就是发表文章,成功后,一次广播即可
关心这个发表结果的各业务程序只需要收听这个广播即可;当然这个广播和udp中的广播还是有很大的不同的
具体实现其实很简单:
发表程序常驻内存,并开启一个端口提供广播注册,某业务需要接收广播,只需要连接上来即可
发表程序一旦有新的文章,即可遍历所有的注册程序所对应的网络连接,然后一一主动通知;

这里有个最大的问题是:广播信息有可能丢失,比如监听广播的业务模块重启,比如网络问题,这
其实是可以采用一些手段简洁漂亮的解决的(比如递增的信息ID);

广播这一机制在系统架构中的解耦是非常有用的,这一机制将系统节点划分成:一个稳定简洁支持
插件式扩展的主框架架构+若干以usb方式插入主框架的业务框架;站高点看:主架构框架在每个关键的地方
留下一个插槽,这个插槽就像usb口一样,业务框架插入usb即可直接接入主架构,享受主架构的信息,完成
自己的业务需求;而主架构框架对这些业务架构的插拔和更改保持不需要知道的幸福状态!


回调
例:一个系统,有一个稍靠近底层的svr集群B,其功能就是完成某一请求,但这一请求可能要比较
长的时候才能完成,另外一个是接入层svr集群A,其功能就是接收用户请求,然后调用B集群;因为需求要求
B完成后,要把结果返回到A;因为A和B之间的连接有可能不可靠,所以如果依赖常连接将结果送回去将比较
有问题;这时候一般的开发会直接在B里面把A的配额加上,然后在操作完成的时候,直接将结果通过B到A的
主动连接发送给A;
问题:其实这个问题和代码中的模块耦合问题一模一样,只不过耦合对象不同而已,架构中的是svr
集群,代码中的是一个模块或一个类;导致的问题也一样:B不应该需要知道A的存在,却无缘无故的必须知道
A(比如加了A的配置),在架构图上将出现非常恶心的循环调用,出现双向箭头!!另外一个问题是:灵活
性不足,比如现在假如另外一个新的svr集群加入,比如C,也要向B发一类的请求,然后需要等返回结果,这
个时候,B 不但需要知道A和C的存在,而且还要区分一个返回到底属于A还是C!假如再加一个D呢???
最后的结果是 B 搞的乱七八糟!!

解决方法其实也和代码中的模块解耦一样,回调:
A在发给B的请求中带上 callback 信息,只不过这个 callback 信息和代码模块的callback不一样
代码中是函数指针之类,而这个callback是 ip+port 之类;

回调这一机制在理清系统的层级关系中的作用是非常重大的,这一机制可以比较完美清晰的将系统
划分成多层金字塔的单向调用层级!!站高点看:系统中的svr集群可以比较完美的变成一层一层的结构,
底层只需要关心自己的逻辑,而不需要知道调用者即上层是谁,上层在哪里,上层有多少!

用产品思维设计API(二)——数据解耦,才是前后分离的本质

用产品思维设计API(二)——数据解耦,才是前后分离的本质前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下。 - 一个优雅的API该如何设...
  • yzzst
  • yzzst
  • 2017年01月07日 23:07
  • 3346

模块化与解耦

http://blog.cnbluebox.com/blog/2015/11/28/module-and-decoupling/ 本文主要讲述了在iOS开发过程中,模块化工程...

面向对象的php之类解耦的好处

为什么要解耦呢? 举个例子: getScore($student){ } 假如一个课程类,里面有一个获取学生分数的的方法getScore()。该方法要求传入一学号。 在这个方法中,就跟学生类...

函数指针与软件设计

函数指针与软件设计 记得刚开始工作时,一位高手告诉我,说,longjmp和setjmp玩得不熟,就不要自称为C语言高手。当时我半信半疑,为了让自己向高手方向迈进,还是花了一点时间去学习longjmp和...
  • absurd
  • absurd
  • 2006年05月29日 20:24
  • 6239

[笔记-架构探险]框架优化与功能扩展3.1.优化Action参数、提供文件上传功能、与ServletApi解耦.

http://git.oschina.net/zhuqiang/smart-framework 跟着书上学习的 框架git地址 http://git.oschina.net/zhuqiang/mr...

用java观察者模式解耦经典三层架构

三层架构是一个非常经典的架构模式,根据系统的职责不同,将系统分成了表现层,逻辑层和数据访问层,并且配合数据实体进行数据传输,可以大大的封装性和复用性。 经典的三层架构图: 我们再深入到架构...
  • xqf309
  • xqf309
  • 2014年07月28日 15:05
  • 11439

JavaWeb项目为什么我们要放弃jsp?为什么要前后端解耦?为什么要前后端分离?2.0版,为分布式架构打基础。

前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦, 并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构...

你的解耦战术,决定了架构高度!

转自:http://developer.51cto.com/art/201711/557827.htm 架构设计中,大家都不喜欢耦合,但有哪些典型的耦合是我们系统架构设计中经常出现的,又该如何优...

JavaWeb项目为什么我们要放弃jsp?为什么要前后端解耦?为什么要前后端分离?2.0版,为分布式架构打基础。

前戏 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦, 并且前后端分离会为以后的大型分布式架构、弹性计算架构、微...

数据库解耦

  • 2017年11月29日 08:46
  • 146KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:架构解耦
举报原因:
原因补充:

(最多只允许输入30个字)