多层架构的讨论,欢迎拍砖

10-11-24 yinchonging
一套多层架构,有些问题想和大家讨论一下,层次结构大致如下。

第三方通过http请求到架构第一层,如下:

第一层(http服务):提供http服务接收数据,然后后通过tcp和下面第二层通信(第一次tcp连接)。

第二层(tcp服务):接受第一层的数据后,通过tcp和mogonDB1通信获得结果(第二次tcp连接),将结果tcp发送到下面第三层(第三次tcp连接)。

第三层(tcp服务):接受第二层的数据后,通过tcp和mogonDB2通信获得结果(第四次tcp连接),将结果tcp发送到下面第四层(第五次tcp连接)。

第四层(tcp服务):接受第三层的数据后,逻辑计算出最终结果后通过tcp发送到最终目标服务(第六次tcp连接)。

我再总结一下:

1.第一层接受第三方的一个http请求,目的是要将数据发送第三方指定的目标地址。

2.第二层、第三层、mogonDB1、mogonDB2都是用来计算出那个第三方指定的目标地址的。

3.第四层获得了第三方指定的目标地址,然后发送数据,完成整个流程。

大家先不要关心为什么要这样设计,我想和大家讨论一下的是,一个请求流程下来,直到最终完成,期间经过六次tcp连接,这样的设计在性能上、稳定性上、壮健性上、日常维护性、易部署性、易监控性等非功能指标是否可靠?

换一个说话,就是想请大家根据自己的经验对这套架构挑挑毛病,拍拍砖,越多越好,多多益善,小弟拜谢!!!

SpeedVan
2010-11-25 10:06
一个请求下来就产生这么多请求,若果是同步的,性能是个问题,异步的话,设计难度颇高(安全性)-。-。得到结果的时间都比较长,特别是传送时带着庞大的数据集合。

只是计算目标地址的话,为什么要经过那么多东西-。-在提升成本么???

DB1和DB2不能视为一个仓储?毕竟他们之间的通信不会涉及第三方。

每层都得集群,否则,一个当了全都运作不了。这样的话,成本···

若果是想分布式,是业务繁重时,对业务进行分割可以有效提高性能。但这种分布不是本末倒置么-。-这只有一个计算的逻辑(业务)存在啊。(因为不知道你实际咋样,只能猜想)

当然这样的设计,也有好处的——当DB和计算逻辑这些是以服务器为替换单元的话(以换服务器的方式,换逻辑-。-),方便替换-。-

PS:我不觉得那叫分层,而是水平面上的数据传输和分布。

对你那个分层,我觉得如下:

1、HTTP请求处理//这里有点像controller

2、业务(计算逻辑)

3、DB1、DB2(仓储)

可能上面这样会好些,因为请求是请求业务,不是请求数据,只是业务需要数据而已-。-若果业务需要到请求信息,以你那种方式的话,则这次的请求信息需要带到下一次请求,有那么一点不合理吧-。-

当然具体问题具体分析,只是说出我的想法而已。

猜你喜欢