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

要知道设计和实现,是不同的人或团队在做,如果设计的思路不能贯彻下去,走样是必然的。

这在设计界有个定律,就是设计的越复杂,实现的时候,越难实现,开发周期越长,代码越复杂,bug越多,功能越不稳定,性能越差,砸锅的概率越大。

还有一个定律是:大部分设计者只具备了把事情搞复杂的能力,不具备把复杂的事情搞简化的能力,所以领导的期望有多大,设计就有多复杂。

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

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

一个是功能上的可扩展,在一个运营平台上,同时为多个不同的物流企业提供运营服务,各个企业必然有自己个性化的需求,想要吸引客户,销售上就得尽量答应客户的各种要求,技术上就要想办法实现客户的要求,但是其他企业客户八竿子用不着。随便一个功能的增加,都要考虑对平台的冲击,多版本的维护,平台稳定性等等。很多运营平台都经历过功能弱智简单、功能丰富最后到臃肿再到最后推倒重来这样的过程,而推倒重来的代价是,罗马不是一夜建成的,架构是美好的,不代表功能的完善和稳定,新版本的不稳定,功能的不完善,给运营又会造成极大的冲击,客户、客服、售后、市场销售等连带着怨声载道,痛不欲生,纷纷追思旧版本如何如何的美好。所以推倒重来的代价是壮士断腕,代价很大,不断也不行,断了就要经历短期的波动。

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

1) 性能可扩展方面

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

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

对于压力的处理,愚蠢的设计是在一个功能里反复优化,好的设计往往是分而治之,通过不同的服务,来分担压力,如协议解析、入库、消息通知、应答等分解成不同的服务,解析后调用入库服务,解析程序只是简单调用入库服务的接口然后立即返回,而在入库服务内部,则会通过异步处理保证服务调用后能够立即返回,而不是阻碍整个处理流程。

2)功能可扩展方面

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

很多弱智的设计,因为惧怕未来的扩展,所以对实体类和库表都保留了N多的扩展字段,因为不知道未来要做什么用,然后起个无意义的名字,如data1,data2,data3,data4,还有f1,f2,f3这样的字段,应对未来用户扩展要求。这算是扩展设计吗,很难想象,不仅起不到作用,反而制造大量的垃圾,代码的可读性变的非常差。这种设计可以休矣。把可扩展设计理解成冗余设计,预留冗余这种手段称不上设计,未来也肯定用不着。

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

可扩展性的设计原则只有两个字。

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

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

善于运用设计模式,也会提高可扩展性,如熟练运用模板模式,善于将数据和表现、格式分离。比如Ibatis框架,通过sql模板,将原有臃肿无聊的sql代码剥离出来。大大提高了代码的可读性和可扩展性。

GPS部标平台的架构设计(二) 可扩展性设计的更多相关文章

  1. GPS部标平台的架构设计(四)-百度地图设计

    部标GPS软件平台之百度地图设计 地图是客户端中不可缺少的一个模块,很多人在设计和画图时候,喜欢加上地图引擎这样高大上的字眼,显得自己的平台有内涵,说白了就是用第三方的SDK来开发,早期的GPS监 控 ...

  2. GPS部标平台的架构设计(三) 基于struts+spring+hibernate+ibatis+quartz+mina框架开发GPS平台

    注意,此版本是2014年研发的基于Spring2.5和Struts2的版本,此版本的源码仍然销售,但已不再提供源码升级的服务,因为目前我们开发的主流新版本是2015-2016年近一年推出的基于spri ...

  3. GPS部标平台的架构设计(一)

    设计和开发一个GPS系统似乎并不太难,很多人马上就想到了地图,放大,缩小之类的功能,最多就是在加点报表之类的东西,就成了. 这种观点造成了业界内,很多GPS系统粗制滥造,不堪大用. 事实上,设计和开发 ...

  4. GPS部标平台的架构设计(十)-基于Asp.NET MVC构建GPS部标平台

    在当前很多的GPS平台当中,有很多是基于asp.NET+siverlight开发的遗留项目,代码混乱而又难以维护,各种耦合和关联,要命的是界面也没见到比Javascript做的控件有多好看,随着需求的 ...

  5. GPS部标平台的架构设计(六)-Android手机客户端和手机查车设计

    对于GPS软件平台,虽然有功能非常丰富的PC端或BS客户端,但是客户也是需要移动客户端来作为自己的辅助工具,也是需要的.做为GPS平台的设计者和开发者,在开发移动客户端的时候,也需要从常规的服务器开发 ...

  6. GPS部标平台的架构设计(五)-地图服务算法库

    GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标 ...

  7. GPS部标平台的架构设计(九)-GPS监控客户端设计

    交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分. 客户端设计面临两个问题: 1.基于 ...

  8. GPS部标监控平台的架构设计(十一)-基于Memcached的分布式Gps监控平台

    部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临 ...

  9. GPS部标监控平台的架构设计(八)-基于WCF的平台数据通信设计

    总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对 ...

随机推荐

  1. Redis学习笔记(4) Redis事务、生存时间及排序

    1. Redis事务 Redis中的事务(transaction)是一组命令的集合,一个事务中的命令要么都执行,要么都不执行.事务的原理是先将属于一个事务的命令发送给Redis,然后再让Redis依次 ...

  2. AlertDialog对话框简单案例

    什么是Dialog? Dialog类,是一切对话框的基类,需要注意的是,Dialog类虽然可以在界面上显示,但是并非继承于View类,而是直接从java.lang.Object开始构造出的.类似于Ac ...

  3. pointers on c (day 1,chapter2)

    交叉编译器(cross complier)就是在一台机器上运行,但它所产生的可执行代码运行在不同类型的机器上. 翻译阶段由几个步骤组成,组成一个程序的每一(有可能有多个)源文件通过编译过程分别转换成目 ...

  4. eclipse调试solr

    eclipse调试solr 现在solr的源码包,我这里是4.10.2, 编译, ant ivy-bootstrap ant eclipse 导入elipse,将solr/example/solr/下 ...

  5. 为什么<b></b>不推荐使用

    曾经在网上看见说:不推荐是用b标签,咦,我好像用过不少,难道我又坑了别人……度娘是这样说的:只要是从网页的简洁性和搜索引擎的友好度来看的.<b>是加粗,和css的font-weight在视 ...

  6. DOM元素的大小和位置

    HTML: <div id="parent"> <div id="box"> 测试测试测试测试测试测试测试测试测试测试测试测试测试测试测 ...

  7. .net core 基本概念

    asp.net core 是基于 .net core的,所以能够跨平台. 目前存在.NET Framework (CLR), .NET Core (CoreCLR) or Mono,可根据项目的具体情 ...

  8. ZeroMQ接口函数之 :zmq_msg_size - 以字节为单位返回消息内容的大小

    ZeroMQ 官方地址 :http://api.zeromq.org/4-2:zmq_msg_size zmq_msg_size(3)  ØMQ Manual - ØMQ/3.2.5 Name zmq ...

  9. 2016huasacm暑假集训训练三 D - Invitation Cards

    题目链接:http://acm.hust.edu.cn/vjudge/contest/123674#problem/D 题意:一张个向图,求从点1开始到其他各点的最短路权值和加上从其他各点到点1的最短 ...

  10. C++标准库 -- tuple

    头文件:<tuple> 可访问属性: 无(用get方法来访问数据) 可访问方法: swap(tuple) 和另外一个tuple交换值 其他相关方法: swap(t1, t2) 交换两个tu ...