系统结构的选择

最近在帮公司整理系统结构,原来的系统采用thrift消息打通各个节点“奇经八脉”,但是这种网状的系统结构维护起来非常复杂,虽然thrift是个好东西,但是梳理好系统的交互和关系比用什么工具更加重要。

首先,这里说的系统结构指的是系统的模块以及功能的划分,各个模块存在的形态(独立的节点还是类库)。有一点我们应该时刻提醒自己——不要设法用一种系统结构去解决所有问题,这会让自己陷入无止尽的循环中。那么系统结构到底有哪些呢?我目前接触到的有——C/S结构,心型结构,树状结构,网状结构,用得最多的当属C/S结构。

C/S结构的系统是非常简单直接的,做过网络编程的程序员能够很容易的搭建起来。其特点通俗一点来说就是:客户端所有信息都从服务器拿,所有信息都向服务器上报,另外客户端还会接收服务的通知。举个具体的例子,我想用一个web来管理流媒体服务器,另外还有多个客户端APP可以访问这个流媒体服务器上媒体流。这里使用C/S结构是最好不过的了,web服务作为后台管理,可以对流媒体服务器进行管理和操作,可以为客户端提供登录,媒体信息推送,以及客户端之间的消息交互等。客户端则根据web服务提供的信息向流媒体服务器取流。这里我们并没有让客户端直接向流媒体服务器获取流的信息,而是通过web服务下发,好处是第一,让管理配置工作有专门的模块处理,让流媒体服务器做好自己流分发的事情;第二,web服务做后台管理有着天生的优势(数据库访问接口,MVC框架,工程管理……);第三,以后加入其他服务模块可以参考流媒体服务器的做法,接口可以重用。这种结构非常适合中小型系统,作为初期系统原型,而开发和维护只需要JAVA程序员1枚,C/C++程序员1枚,客户端开发另计。

心型结构,是以某一个节点或者一个集群(对外表现为一个节点)为中心,其他节点通过该中心节点与其他节点进行交互,而中心节点仅仅作为一个中转,本身并不保存这些消息。这种结构与C/S结构很像,消息都是通过某一节点,不同在于心型结构是要在自身隐形,就像我们打电话一样,我们并不知道我们的电话线路经过了多个节点,只要知道对方的电话号码就能够与对方通信。使用这种结构的系统,一般都具有多个相同或者不同功能的节点,各个节点之间彼此需要频繁的通讯,所以通过一个中心节点进行路由是一个方便的选择。在我做过的系统中,核心网产品曾经使用过这种结构。核心网的网关使用的是一种ATCA的硬件架构,我们的产品中有主控板和业务板(接口板)组成,这是个非常复杂的产品,心型的消息框架为应用提供了板卡之间通讯的能力。

树状结构,其实是一种跨系统的解决方案,比如:一个用户从一个系统漫游到另一个系统,一种方式就是在这两个系统之上再构建一个节点,用户同步这个用户的数据。

网状结构,我工作这么久没有使用过,见过其他人用过,但个人觉得用的并不好。

后两种系统结构,我还需要时间去多了解一下,现在不能做过多评述。