GPS部标平台的架构设计(一)】的更多相关文章

部标GPS软件平台之百度地图设计 地图是客户端中不可缺少的一个模块,很多人在设计和画图时候,喜欢加上地图引擎这样高大上的字眼,显得自己的平台有内涵,说白了就是用第三方的SDK来开发,早期的GPS监 控软件用的都是mapx.mapxtrem.acrgis之类的,使用的都是本地地图.不仅要购买正版地图,还要购买价格不菲的地图引擎license,服务器版的部署的时候,还要绑定到服务器ID上,现在这种开发方式已被抛弃.现在的百度地图.谷歌地图提供的SDK接口丰富,开发方便,系统稳定,大家都用的很爽. 在…
在当前很多的GPS平台当中,有很多是基于asp.NET+siverlight开发的遗留项目,代码混乱而又难以维护,各种耦合和关联,要命的是界面也没见到比Javascript做的控件有多好看,随着需求的增多,平台已经臃肿不堪. 设计基于.NET的GPS部标平台,我们坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架.选用一个灵活的脚手架,同时团队又能掌握这个脚手架为团队所用. 对于一个web应用项目,基于MVC的框架,前面文章提到过,最大的优点就是结构清晰,强制…
注意,此版本是2014年研发的基于Spring2.5和Struts2的版本,此版本的源码仍然销售,但已不再提供源码升级的服务,因为目前我们开发的主流新版本是2015-2016年近一年推出的基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标GPS监控平台,相对于原来的2014年研发的旧版的struts版本,从性能和功能上有了较大的提升,融合了大量客户的需求意见,相对于Struts版本,主要的特点,请点击文章详细阅读和比对: 基于…
设计和开发一个GPS系统似乎并不太难,很多人马上就想到了地图,放大,缩小之类的功能,最多就是在加点报表之类的东西,就成了. 这种观点造成了业界内,很多GPS系统粗制滥造,不堪大用. 事实上,设计和开发一个GPS平台往往耗费数年时间,虽然这不是客户和领导所期望的,但是往往都摆脱不了三年周期的宿命: 第一年满足基本需求能够稳定下来已经很不错, 第二年增加差异化.个性化.有市场竞争力的功能,让平台功能壮大,提升用户体验: 第三年随着功能的堆砌,数据量的增大,接入车辆的增多,需要对平台进行较大规模的重构…
对于GPS软件平台,虽然有功能非常丰富的PC端或BS客户端,但是客户也是需要移动客户端来作为自己的辅助工具,也是需要的.做为GPS平台的设计者和开发者,在开发移动客户端的时候,也需要从常规的服务器开发和客户端开发的思维中,转变过来,当然客户的需求也需要转变,因为毕竟不能随心所欲的将PC端的所有功能需求照搬到手机客户端,手机的开发环境.网络环境.使用环境都决定了设计理念与PC端的设计是完全不一样的. 通常我们成为GPS部标平台的手机客户端为手机查车,实际上现在的功能不仅仅是查车,由于客户需求的推进…
GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标: 2.坐标解偏,或者纠偏,这个我们也是需要的,因为当用户在地图上画出的各种区域,标注,发送到后台存储的坐标都是基于地图所采用的坐标系统,因而是偏移的,这就面临一个严重的问题,因为在部标808协议中,对于区域报警,需要将区域的顶点坐标,下发给终端,终端在实际运行中,不断用GPS坐标和区域坐标进行比对…
在设计的前夕,设计人员喜欢把领导对未来业务的期望带入到设计目标当中,比如当前业务也不过是接入几千辆车,未来业务增长也不过几万台,但领导很多激情,强势要求二期平台的接入能力要达到20万台,这个要求带入到架构设计当中,很多人立即崩溃了,在设计的时候,意淫出很多奇妙的东西,很复杂的数据库结构或者库表,在设计的初期就早早的确立一些框架如MQ,Memcached,Ehcache等等,在后来的实际运行过程中,由于不熟悉,起到反面的作用,性能差,bug多. 要知道设计和实现,是不同的人或团队在做,如果设计的思…
交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分. 客户端设计面临两个问题: 1.基于CS还是基于BS,这是个问题 萝卜白菜各有所爱,客户要什么,我们就开发什么,从客户来讲,更适应桌面客户端,没有浏览器的七七八八问题,速度感觉上也比网页的快,操作方便.当然网页客户端也有很大的优势,部署和维护方便,不需要开发升级系统. 2.与服务端的交互通信,采用Socket, WebService还…
部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临的三个问题: 1)连接的限制 服务器软件接入终端的连接数是有限的,无论如何优化,都是有限的,接入的增多就会排队,超时timeout重置reset等问题就会出现; 2)部标808服务器软件的内存限制的问题 内存的限制,服务器操作系统中一个进程所承受的内存是有限制的,超过则导致服务器软件进程内存溢出而退…
总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对各个子系统进行功能隔离,并通过设计接口规定子系统直接的调用规约. 首先我们根据部标平台的要求,设计和开发出各个主要的服务器子系统,这是平台中最核心的子系统,在实际的应用中,由于车辆规模的大小和行业需求,还会扩展出各种业务子系统.核心子系统如下: 1)808GPS服务器,采用交通部的部标808协议,负…