Chinaunix首页 | 论坛 | 博客
  • 博客访问: 521220
  • 博文数量: 78
  • 博客积分: 995
  • 博客等级: 准尉
  • 技术积分: 1462
  • 用 户 组: 普通用户
  • 注册时间: 2011-11-15 20:22
个人简介

技术中沉思的时候最快乐,问题得到完美解决的时候最有成就感!

文章分类

全部博文(78)

文章存档

2013年(39)

2012年(37)

2011年(2)

分类: LINUX

2012-11-15 17:11:03

之前写过一篇“实战代码解耦--回调”,一个程序中代码的模块解耦这一概念对于稍微有些经验

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

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

广播
例:就拿此篇博客的提交到服务器这一服务器程序来说,数据提交到服务器,假设用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集群可以比较完美的变成一层一层的结构,
底层只需要关心自己的逻辑,而不需要知道调用者即上层是谁,上层在哪里,上层有多少!
阅读(4426) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~