GPS部标平台的架构设计(二) 可扩展性设计
在设计的前夕，设计人员喜欢把领导对未来业务的期望带入到设计目标当中，比如当前业务也不过是接入几千辆车，未来业务增长也不过几万台，但领导很多激情，强势要求二期平台的接入能力要达到20万台，这个要求带入到架构设计当中，很多人立即崩溃了，在设计的时候，意淫出很多奇妙的东西，很复杂的数据库结构或者库表，在设计的初期就早早的确立一些框架如MQ，Memcached,Ehcache等等，在后来的实际运行过程中，由于不熟悉，起到反面的作用，性能差，bug多。
其实架构设计中有两个可扩展性要求：
一个是性能的可扩展，随着接入车辆压力的增大，不需要改动代码，只需要增加硬件配置，如增加服务器，增加软件运行的进程实例来达到要求；
一个是功能上的可扩展，在运营平台上，为不同的物流企业提供运营服务，各个企业必然有自己个性化的需求，想要吸引客户，销售上就得尽量答应客户的各种要求，技术上就要想办法实现客户的要求，但是其他企业客户八竿子用不着。很多运营平台都经历过功能弱智简单、功能丰富最后到臃肿再到最后推到重来这样的过程。
这两点明确后，我们知道自己的设计目标：
1) 性能可扩展方面
首先要面向服务进行设计，对子系统当中的调用接口进行定义，在子系统中加以实现，形成服务。这些服务可以本地部署，可以分布式部署，服务的部署对于调用者来说是透明的，不影响的。做到了这一点，我们才可以在压力来临的时候，通过改变和增加服务器的配置，透明灵活的分布式部署方式，来缓解压力的上升。
面向服务的开发中，对于远程方法调用的协议，Java的有RMI，DotNet的有WCF，都是非常好的可以基于TCP二进制交换数据的协议，远胜于webservice，但在设计的时候，可以完全不用考虑这些，在实现的时候，由于现在的Spring框架很强大，仅仅通过几行XML配置，就可以将一个接口透出变成一个RMI服务或者WCF服务。
对于压力的处理，通过不同的服务，来分担压力，如解析后调用入库服务，解析程序只是简单调用入库服务的接口然后立即返回，而在入库服务内部，则会通过异步处理保证服务调用后能够立即返回，而不是阻碍整个处理流程。
2)功能可扩展方面
这个其实是最难的，因为它的要求是比较抽象，就是软件要求能够修改完善添加现有的功能满足软件未来的成长，直白点将就是软件能够改动已满足用户新增的需求。一些人可能会问，只要有代码，可以随便改。如果是这样，为什么我们的客户提出需求后，我们总是拒绝。这是因为随着功能的增多，代码的增多，可维护性变差，修改某个功能的代码，或者添加某项功能，会耗费大量的人力和时间，拔出萝卜带出泥，打扫卫生把瓷器打碎，一句话，很难改。
什么算是好的可扩展性，只能说，设计好的，代码容易改动，容易添加功能，设计的不好的，一个小小的功能，能改出一头汗，测试的时候，要回归测试一大片。
软件功能可扩展性设计最理想的是基于插件化或者模块化的设计，通过动态加载、事件注册、功能回调等机制，来达到要求，当然插件化的设计的弊端就是复杂，以复杂为代价，甚至要牺牲部分性能，来达到软件的可扩展性。
插件设计这个在部标GPS服务器的设计中用的比较多，对于不同的终端的协议，可以基于插件化的设计，不同的协议，按照插件标准进行编写，形成一个庞大的协议库，在系统运行的时候，可以静态配置，也可以动态加载，根据不同的车辆，不同的客户，不同的设备，不同的版本，来加载不同的协议插件进行解析。
联系：2379423771@qq.com
(7192)
