GPS部标平台的架构设计(二) 可扩展性设计

2014年5月15日 分类: GPS系统, 部标监控平台

在设计的前夕,设计人员喜欢把领导对未来业务的期望带入到设计目标当中,比如当前业务也不过是接入几千辆车,未来业务增长也不过几万台,但领导很多激情,强势要求二期平台的接入能力要达到20万台,这个要求带入到架构设计当中,很多人立即崩溃了,在设计的时候,意淫出很多奇妙的东西,很复杂的数据库结构或者库表,在设计的初期就早早的确立一些框架如MQ,Memcached,Ehcache等等,在后来的实际运行过程中,由于不熟悉,起到反面的作用,性能差,bug多。

其实架构设计中有两个可扩展性要求:

一个是性能的可扩展,随着接入车辆压力的增大,不需要改动代码,只需要增加硬件配置,如增加服务器,增加软件运行的进程实例来达到要求;

一个是功能上的可扩展,在运营平台上,为不同的物流企业提供运营服务,各个企业必然有自己个性化的需求,想要吸引客户,销售上就得尽量答应客户的各种要求,技术上就要想办法实现客户的要求,但是其他企业客户八竿子用不着。很多运营平台都经历过功能弱智简单、功能丰富最后到臃肿再到最后推到重来这样的过程。

这两点明确后,我们知道自己的设计目标:

1) 性能可扩展方面

   首先要面向服务进行设计,对子系统当中的调用接口进行定义,在子系统中加以实现,形成服务。这些服务可以本地部署,可以分布式部署,服务的部署对于调用者来说是透明的,不影响的。做到了这一点,我们才可以在压力来临的时候,通过改变和增加服务器的配置,透明灵活的分布式部署方式,来缓解压力的上升。

   面向服务的开发中,对于远程方法调用的协议,Java的有RMI,DotNet的有WCF,都是非常好的可以基于TCP二进制交换数据的协议,远胜于webservice,但在设计的时候,可以完全不用考虑这些,在实现的时候,由于现在的Spring框架很强大,仅仅通过几行XML配置,就可以将一个接口透出变成一个RMI服务或者WCF服务。

  对于压力的处理,通过不同的服务,来分担压力,如解析后调用入库服务,解析程序只是简单调用入库服务的接口然后立即返回,而在入库服务内部,则会通过异步处理保证服务调用后能够立即返回,而不是阻碍整个处理流程。

2)功能可扩展方面

  这个其实是最难的,因为它的要求是比较抽象,就是软件要求能够修改完善添加现有的功能满足软件未来的成长,直白点将就是软件能够改动已满足用户新增的需求。一些人可能会问,只要有代码,可以随便改。如果是这样,为什么我们的客户提出需求后,我们总是拒绝。这是因为随着功能的增多,代码的增多,可维护性变差,修改某个功能的代码,或者添加某项功能,会耗费大量的人力和时间,拔出萝卜带出泥,打扫卫生把瓷器打碎,一句话,很难改。

 什么算是好的可扩展性,只能说,设计好的,代码容易改动,容易添加功能,设计的不好的,一个小小的功能,能改出一头汗,测试的时候,要回归测试一大片。

  软件功能可扩展性设计最理想的是基于插件化或者模块化的设计,通过动态加载、事件注册、功能回调等机制,来达到要求,当然插件化的设计的弊端就是复杂,以复杂为代价,甚至要牺牲部分性能,来达到软件的可扩展性。

  插件设计这个在部标GPS服务器的设计中用的比较多,对于不同的终端的协议,可以基于插件化的设计,不同的协议,按照插件标准进行编写,形成一个庞大的协议库,在系统运行的时候,可以静态配置,也可以动态加载,根据不同的车辆,不同的客户,不同的设备,不同的版本,来加载不同的协议插件进行解析。

   联系:2379423771@qq.com

(6732)

标签: ,
目前还没有任何评论.

Leave a Comment