注意,此版本是2014年研发的基于Spring2.5和Struts2的版本,此版本的源码仍然销售,但已不再提供源码升级的服务,因为目前我们开发的主流新版本是2015-2016年近一年推出的基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标GPS监控平台,相对于原来的2014年研发的旧版的struts版本,从性能和功能上有了较大的提升,融合了大量客户的需求意见,相对于Struts版本,主要的特点,请点击文章详细阅读和比对: 基于…
在当前很多的GPS平台当中,有很多是基于asp.NET+siverlight开发的遗留项目,代码混乱而又难以维护,各种耦合和关联,要命的是界面也没见到比Javascript做的控件有多好看,随着需求的增多,平台已经臃肿不堪. 设计基于.NET的GPS部标平台,我们坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架.选用一个灵活的脚手架,同时团队又能掌握这个脚手架为团队所用. 对于一个web应用项目,基于MVC的框架,前面文章提到过,最大的优点就是结构清晰,强制…
部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临的三个问题: 1)连接的限制 服务器软件接入终端的连接数是有限的,无论如何优化,都是有限的,接入的增多就会排队,超时timeout重置reset等问题就会出现; 2)部标808服务器软件的内存限制的问题 内存的限制,服务器操作系统中一个进程所承受的内存是有限制的,超过则导致服务器软件进程内存溢出而退…
总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对各个子系统进行功能隔离,并通过设计接口规定子系统直接的调用规约. 首先我们根据部标平台的要求,设计和开发出各个主要的服务器子系统,这是平台中最核心的子系统,在实际的应用中,由于车辆规模的大小和行业需求,还会扩展出各种业务子系统.核心子系统如下: 1)808GPS服务器,采用交通部的部标808协议,负…
部标GPS软件平台之百度地图设计 地图是客户端中不可缺少的一个模块,很多人在设计和画图时候,喜欢加上地图引擎这样高大上的字眼,显得自己的平台有内涵,说白了就是用第三方的SDK来开发,早期的GPS监 控软件用的都是mapx.mapxtrem.acrgis之类的,使用的都是本地地图.不仅要购买正版地图,还要购买价格不菲的地图引擎license,服务器版的部署的时候,还要绑定到服务器ID上,现在这种开发方式已被抛弃.现在的百度地图.谷歌地图提供的SDK接口丰富,开发方便,系统稳定,大家都用的很爽. 在…
设计和开发一个GPS系统似乎并不太难,很多人马上就想到了地图,放大,缩小之类的功能,最多就是在加点报表之类的东西,就成了. 这种观点造成了业界内,很多GPS系统粗制滥造,不堪大用. 事实上,设计和开发一个GPS平台往往耗费数年时间,虽然这不是客户和领导所期望的,但是往往都摆脱不了三年周期的宿命: 第一年满足基本需求能够稳定下来已经很不错, 第二年增加差异化.个性化.有市场竞争力的功能,让平台功能壮大,提升用户体验: 第三年随着功能的堆砌,数据量的增大,接入车辆的增多,需要对平台进行较大规模的重构…
搭建基于SSI(struts2,spring,ibatis)的javaEE开发环境 最近有很多人不知道如何搭建基于SSI(struts2,spring,ibatis)的J2EE开发环境,这里给大家一个demo,供初学者使用,该框架是基于MVC的,并且已经做好了文件的分层等,并加入了日志文件,好了,废话不多说了   1.搭建struts2开发环境: (1)找到开发strust2应用所需要使用到的jar文件 (2).编写struts.xml文件 struts.xml(struts的总配置文件) 1…
在设计的前夕,设计人员喜欢把领导对未来业务的期望带入到设计目标当中,比如当前业务也不过是接入几千辆车,未来业务增长也不过几万台,但领导很多激情,强势要求二期平台的接入能力要达到20万台,这个要求带入到架构设计当中,很多人立即崩溃了,在设计的时候,意淫出很多奇妙的东西,很复杂的数据库结构或者库表,在设计的初期就早早的确立一些框架如MQ,Memcached,Ehcache等等,在后来的实际运行过程中,由于不熟悉,起到反面的作用,性能差,bug多. 要知道设计和实现,是不同的人或团队在做,如果设计的思…
交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分. 客户端设计面临两个问题: 1.基于CS还是基于BS,这是个问题 萝卜白菜各有所爱,客户要什么,我们就开发什么,从客户来讲,更适应桌面客户端,没有浏览器的七七八八问题,速度感觉上也比网页的快,操作方便.当然网页客户端也有很大的优势,部署和维护方便,不需要开发升级系统. 2.与服务端的交互通信,采用Socket, WebService还…
GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标: 2.坐标解偏,或者纠偏,这个我们也是需要的,因为当用户在地图上画出的各种区域,标注,发送到后台存储的坐标都是基于地图所采用的坐标系统,因而是偏移的,这就面临一个严重的问题,因为在部标808协议中,对于区域报警,需要将区域的顶点坐标,下发给终端,终端在实际运行中,不断用GPS坐标和区域坐标进行比对…
部标监控平台的压力测试是部标检测流程的最后一个检测环节,也是最难的,很多送检的企业平台都是卡壳在这一个环节.企业平台面临的问题如下: 1.对于压力测试的具体指标要求理解含糊,只知道是模拟一万辆车终端进行数据包传输,不知道具体的检测标准是那些指标,等进京考试后落榜了,才知道压力测试失败了,这个时候,还要通知后方的同志改进,耽误的时间和差旅费用成本惊人.很多检测人员需要在京住上几十天,算算得多少钱.因为不知道方向,所以改进也是盲目改进,不知道行不行,应付任务再次送检,也是摇骰子,祈求上天让我们通过吧…
对于GPS软件平台,虽然有功能非常丰富的PC端或BS客户端,但是客户也是需要移动客户端来作为自己的辅助工具,也是需要的.做为GPS平台的设计者和开发者,在开发移动客户端的时候,也需要从常规的服务器开发和客户端开发的思维中,转变过来,当然客户的需求也需要转变,因为毕竟不能随心所欲的将PC端的所有功能需求照搬到手机客户端,手机的开发环境.网络环境.使用环境都决定了设计理念与PC端的设计是完全不一样的. 通常我们成为GPS部标平台的手机客户端为手机查车,实际上现在的功能不仅仅是查车,由于客户需求的推进…
一眨眼距离上次发文好几年过去了,今天翻未读邮件看到博客有文章回复,猛然想起将博客遗忘在角落好几年了,赶紧访问博客.找回密码.翻翻文章,想写点什么但是又不知道从哪下手,N年前的第一篇文章是一个crm设计,今天也放个容器平台架构图吧,水一篇博文,争取一图描述完整. ps:说是容器平台架构设计,实际没有容器内部组件架构,主要是分享下近两年在公司搭建的基于容器平台而建设的项目管理.cicd体系.服务器.监控等整体架构,支撑了公司所有语言平台及业务,有兴趣的童鞋可以参考.…
第1篇 Java Web开发基础第1章 Web的工作机制( 教学视频:31分钟) 1.1 理解Web的概念 1.1.1 Web的定义 1.1.2 Web的三个核心标准 1.2 C/S与B/S两种软件体系结构 1.3 理解HTTP协议 1.3.1 解析HTTP协议URL 1.3.2 解析HTTP协议请求 1.3.3 解析HTTP协议响应 1.4 本章小结 第2章 搭建Java Web开发环境( 教学视频:38分钟) 2.1 JDK的下载与安装 2.1.1 JDK简介 2.1.2 JDK下载安装 2…
1.新加一个类名,实现切换页面主题 在需要变色的标签处,添加该类名,即可实现最简化切换页面主题. HTML: <section ui-view=""> </section>/*页面切换容器 */ <div class="A red">/*A页面 */ <input type="button" class="red-border" value="确定"/> &l…
         ibatis项目中用到了一些基本配置,须要和spring集成,看了看这些配置大部分同hibernate中是一样的,也比較好理解.仅仅是须要他们的配置中每个类的含义,还有当中的一些细节还是须要我们了解的,知识不在多,而在不断吸收和反复,在使用和练习中加深对各种问题的理解. 读取属性文件配置 <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.Prope…
部标1078视频监控平台,是一个庞杂的工程,涵盖了多层协议,部标jt808,jt809,jt1078,苏标Adas协议等,多个平台功能标准,部标796标准,部标1077标准和苏标主动安全标准,视频方面的协议有RTSP, RTMP, RTP, 音视频编码有H.264, AAC,  726,711等,消化这些协议和功能标准就已经是需要一个较长的周期了,而构建一个视频平台的架构,也是比较复杂的,后端不仅有网关,还要有流媒体服务器,转发服务器,播放器,RTSP或RTMP服务器等多个服务器模块,需要的技术…
在开发部标GPS平台中,部标808GPS服务器是系统的核心关键,决定了部标平台的稳定性和行那个.Linux服务器是首选,为了跨平台,开发语言选择Java自不待言. 我们为客户开发的部标服务器基于Mina + Spring + Hibernate + Swing桌面系统开发,整个服务器的架构特点: 1.通信层:基于Java Mina通信框架进行GPS服务器开发,可以使得整个系统架构清晰,开发者可以专注于协议解析.业务和数据处理. 2.GPS终端协议层:而为了对于扩展终端的接入能力,协议层要具有很好…
在开发部标GPS平台中,部标jt808GPS服务器是系统的核心关键,决定了部标平台的稳定性和行那个.Linux服务器是首选,为了跨平台,开发语言选择Java自不待言.需要购买jt808GPS服务器源码+808模拟测试终端工具+压力测试工具(1200元)可以联系我: 2379423771@qq.com: 我们为客户开发的部标服务器基于Mina + Spring + Hibernate + Swing桌面系统开发(基于Netty框架的GPS服务器参见:基于Java Netty框架构建高性能的部标80…
在2011年交通部的796标准推出后,随着各地交管部门的硬性要求,大多数的GPS监控系统或者车辆管理系统或者物流管理系统,无论是旧的,还是新开发的,都必须要以796标准为基础蓝本,首先要满足796的要求,然后在此基础上增加行业应用的个性化要求,如物流运输车辆非常关心的油耗管理,冷链运输非常关心温度控制等等. 所以开发GPS平台的时候,必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档,以此作为自己的功能设计的需求来源,行业需求或用户需求是排在后面的.很多开发团队做出…
基于交通部796标准开发部标监控平台,选择开发语言和技术也是团队要思考的因素,其实这由团队自己擅长的技术来决定,如果擅长C#和Asp.NET, 当然开发效率就高很多.当然了技术选型一定要选用当前主流的技术,现在Asp.NET技术已经发展到5.0, 如果你还是用旧的ASP技术写程序,无疑是为以后的项目维护埋下地雷,后面新来人手学习不到技术,没有兴趣去改进,不愿意维护,没有人愿意接手.代码最关键的是要不断的重构,保持与当前的技术和需求同步,平台才有生命力,否则就会越来越臃肿而变得难以维护.开发一个基…
基于C#和Asp.NET MVC开发GPS部标监控平台 目前整理了基于.NET技术的部标平台开发文章,可以参考: 1.部标Jt808协议模拟终端的设计和开发 2.C#版的808GPS服务器开发->基于部标JT/T 808协议及数据格式的GPS服务器 3.C#版的809GPS服务器开发->基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器 4.Asp.NET版的部标平台开发->基于Asp.NET MVC构建GPS部标平台 5.基于C# winform桌面客户端的部标平台…
现在地方上由于运输车辆的GPS数据都分散在地方上已有的各种企业平台上面,不利于大数据的分析和智能应用,而开发智能的基于大数据的Gps监控平台,往往需要和各种第三方的部标GPS监控平台对接,获取到第三方的企业平台转发的数据,然后进行大数据的分析和应用,经过分析.统计和梳理后的数据,在web页面上进行各种复杂的地图.报表统计等功能的展现. 由于各地的企业平台基本都是符合交通部部标标准的,都具备809协议的转发功能,要和这些企业平台对接,不需要再一个一个的敲定接口标准了,只需要开发出809协议的网关应…
引言:我们已经习惯于一个人独立进行软件开发,每个人都使用自己的风格进行程序设计,但随着工程项目变大或者是对时间要求比较紧时,就需要几个人,十几个人,甚至是上百个人协作进行软件开发与设计,这时一个比较棘手的问题就是如何将若干人所编写的软件代码(有可能是链接库.组件)进行无缝地集成,纵然进行源代码集成是个比较传统也比较成熟的方式,适当使用链接库或组件,也可减少源代码的泄露,但经常的情况是每一次的程序集成和代码维护都需要重新编译与链接源代码和重新发布新软件,这种工作有时又是非常麻烦的.那么就有疑问产生…
源码地址:GitHub·点这里 || GitEE·点这里 一.Seata简介 1.Seata组件 Seata是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务.Seata将为用户提供了AT.TCC.SAGA.XA事务模式,为用户打造一站式的分布式解决方案. 2.支持模式 AT 模式 基于支持本地 ACID 事务的关系型数据库. Java应用,通过 JDBC 访问数据库. 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源. 二阶段:提交异步化,非常…
在我前面有很多篇随笔介绍了Web API 接口层的架构设计,以及对微信公众号.企业号.小程序等模块的分类划分.例如在<C#开发微信门户及应用(43)--微信各个项目模块的定义和相互关系>介绍了相关模块的划分,在<基于微信小程序的系统开发准备工作>介绍了Web API的架构设计思路.本篇随笔对之前介绍的架构内容进行统一的调整更新,以便更加方便实际项目的应用开发,以期达到统一.重用.清晰的目的. 1.公众号.企业号.小程序模块的划分 我们知道,目前微信企业应用,分为公众号.企业号(企业…
前面两篇文章给大家介绍了我们实战的CMS系统的数据库设计,源码也已经上传到服务器上了.今天我们就好聊聊架构设计,在开始之前先给大家分享一下这几天我一直在听的<从零开始学架构>里面关于架构设计的定义以及架构设计的三大原则,希望能对大家有所启发.有着这些基础之后,我们再基于此搭建我们的项目框架吧!如果你在阅读的过程中有任何的问题,欢迎大家在留言区进行留言,或者加入.NET Core实战项目群637326624跟大伙一起交流经验. 本文已收录至<.NET Core实战项目之CMS 第一章 入门…
(转载:http://www.36dsj.com/archives/85383)机器学习与人工智能,相信大家已经耳熟能详,随着大规模标记数据的积累.神经网络算法的成熟以及高性能通用GPU的推广,深度学习逐渐成为计算机专家以及大数据科学家的研究重点.近年来,无论是图像的分类.识别和检测,还是语音生成.自然语言处理,甚至是AI下围棋或者打游戏都基于深度学习有了很大的突破.而随着TensorFlow.Caffe等开源框架的发展,深度学习的门槛变得越来越低,甚至初中生都可以轻易实现一个图像分类或者自动驾…
FROM : http://www.csdn.net/article/2014-08-20/2821302-interview-tencent-b-qq-shuai-wang 对比IaaS和PaaS,SaaS得到的关注显然要少一些.究其根本,不仅因为SaaS关注的是功能方面的探索,更偏向于某个领域或层面的实际应用,还归结于相较前两者,软件的云化已基本趋于成熟,些许突破并不能带来产业上的变革.然而,较少的关注并不意味着缺乏明星产品:放眼国外,企业级SaaS服务已成为许多公司的一项重要收益来源,比如…
我们接着关于爬虫平台的架构实现和框架的选型(一)继续来讲爬虫框架的架构实现和狂阶的选型. 前面介绍了scrapy的基本操作,下面介绍下scrapy爬虫的内部实现架构如下图 1.Spiders(爬虫):它负责处理所有Responses,从中分析提取数据,获取Item字段需要的数据,并将需要跟进的URL提交给引擎,再次进入Scheduler(调度器) 2.Engine(引擎):负责Spider.ItemPipeline.Downloader.Scheduler中间的通讯,信号.数据传递等. 3.Sc…