13518219792
前端：
从事棕树数据中心，服务器租用，云主机，网站空间，域名与空间，CDN，网络代维等服务。
1、老一代两大富应用（RIA）框架（目前已经停止更新）：flex、silverlight
2、其他开源（早期项目较多）：openlayer2、amap、bmap、ArcgisAPI4JS（3系列版本）
3、较新框架：openlayer3、cesiums、ArcgisAPI4JS（4.0之后版本）、
4、轻型框架（需要二次封装）：WebGL(例如d3.js、three.js)
后端：arcgisServer、geoserver、mapserver
部分效果如下
flex:
img src="" class="content_image"
openlayers:
img src="" class="content_image"
cesiums:
基于GIS的通信管网管理系统架构设计
管网资源监测管理系统充分利用 GIS 平台，将分布范围广泛的管网设施和地理位置有机地结合，不仅提高了企业的管理水平，而且提升了企业的服务能力。因此，该系统研究具有现实意义和广阔的应用前景。
1 设计方案及原则
1.1 系统设计方案
地理信息系统是对地理环境中的有关问题进行分析和研究的手段，它是一种采集、处理、传输、存储、管理、查询检索、分析、表达和应用地理信息的计算机系统。利用计算机建立地理数据库，将地理环境中的各种要素，包括它们的地理分布状况和所具有的属性数据，进行数字存储，建立有效的'数据管理系统，通过对各个要素的综合分析，方便快速地获取信息，满足应用和研究的需要，并用图形和数字的方式来表现结果。
通信管网资源与地理空间位置有着密切的关系，本系统充分利用GIS的特点，通过Visual Basic6.0高级语言嵌入 TopMapActiveX组件进行二次开发，设计了地理位置信息与管网资源数据有机融合的监控管理综合系统。Visual Basic能够提供创建图形用户界面(GUI)的方法，可以方便快捷地调用外部控件，具有功能强大的数据库访问特性;TopMap ActiveX地理信息系统开发组件具有完善的地图操作功能。利用成熟的技术和可靠的数据采集硬件设备，以 Windows 2000/NT为网络操作系统，使用MicroSoft的SQL Server2000作为后台数据库系统，利用 ADO技术实现数据库访问，能够满足系统的时实性和可靠性。
1.2 系统设计原则
(1)规范性。在系统设计中制定资源分类、编码等一系列方案，同时把通信行业标准考虑到方案之中，做到系统规范化。(2)科学性。编码时采用区段码和从属编码结构，利于计算机的直接存贮和数据库的管理，便于系统数据的快速检索和更新。(3)扩展性。建立一个开放的系统，留有充分的扩充空间，以便对系统扩充或移植。(4)实时性。能进行动态数据的管理，并保持数据的一致性和实时性要求。(5)安全性。对用户权限进行分级管理。
2 系统结构
2.1 系统功能结构
管网资源监控管理系统是对通信站辖区内的通信管网资源(如管道、人井等)进行计算机管理和监控，包括管网资源数据录入、查询、修改、统计分析、打印输出、地理图形显示、监控数据采集和故障报警显示等功能。系统的功能结构如图1所示。
2.2 系统网络结构
整个系统主要由GIS工作站、GIS服务器、数据服务器和多通道通信服务器组成，采用客户/服务器结构，各通信站点通过原有的内部 10/100 m网络访问。其中：GIS工作站负责本地管网数据的维护管理和监控;多通道数据服务器完成对管网监测数据的采集与通信;GIS 服务器实现对地理属性数据的存储;数据服务器用来存储管网资源数据信息。系统的网络结构如图2所示。
3 监控管理模块设计
3.1 资源数据管理
管网资源数据管理包括管网数据(地理信息数据和线路资源数据)录入、数据查询、数据统计和打印输出等模块。
(1)管网数据录入
管网数据录入模块用于对基础地理信息和线路资源信息进行录入、修改、删除、存储。数据库服务器完成基础图形与数据存储处理等功能;系统管理员有权修改用户权限、增删用户账号。
(2)数据查询/统计
系统根据工作人员的需求对基础地理信息和通信网络信息进行查询;按照给定的统计条件对各通信站的分布位置及覆盖区域、管道分布、缆线、人井等线路信息进行统计分析。
(3)打印输出
将GIS中的数据经过分析、转换处理，以直观的图表形式输出。
3.2 监控数据采集
监控数据采集模块通过传感器完成对管网资源状态数据(压力、温度、水位等模拟量)时实采集与通信，实时监测主要监控点的模拟量是否越限，监控数据判别流程如图3所示。
各通信站点通过监测设备从监测现场采样数据，上报数据经过预处理后输入到系统中，通过与监控标准库的数据进行对比分析来判断管网资源是否发生故障。如果检测判断发生管线受损、模拟量越限时发出报警信息，并对故障位置进行准确定位。如果检测判断没有发生故障，系统不报警，同时继续监测现场数据。
3.3 地理图形/监控报警显示
借助可视化技术，通过图形及其图形变换、声音传递消息等手段，可以实现更为人性化的人机交互。系统的显示包括地理图形显示和监控报警显示两部分。
地理图形显示是建立在对该系统内所有的管网资源实体分类的基础上，一类实体建立一个图层，整个系统是由所有实体相对应的图层叠加而成的。地理图形显示用于电子底图和线路资源符号的显示，具有漫游、无极缩放、分层显示等功能。监控报警显示将实时监控数据和地理图形相结合，在地理图形界面上实时监控网管设备的运行情况。当发生故障时，在GIS 图形界面上用特殊颜色进行标记，对管网设备故障准确定位显示，并进行声光报警，通知维护人员及时抢修。
;
微服务是一种架构思想。将原有的单个业务系统拆分为多个可以独立开发，设计，运行和运维的“小系统”。这些“小系统”之间通过服务完成交互和集成。每个”小系统”除了能处理本身的业务功能外，同时也将自身的能力朝外部发布为服务。
SOA
SOA（面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）的紧耦合系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来后，供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
微服务是 SOA 的升级版，做到更细的粒度，处理了更多的问题。
例如图1中将所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑，缺点也非常明显，部署不灵活以及扩展性不够，但我们如果按照图2的为方式，按照业务而不是技术来划分组织，内部各个服务通过REST方式进行沟通，那么可以使平台使部署、管理和服务功能交付变得更加简单。
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
微服务与
一般提到微服务都离不开Docker与DevOps，理解微服务架构是核心，Docker是工具，是手段。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。
DevOps即开发测试和部署运维的一体化。当我们的单体应用拆分为多个“小系统”后，虽然整体架构可以松耦合和可扩展，但是如果拆分的组件越多，这些组件之间本身的部署运维就越复杂。DevOps够实现开发设计到部署运维的一体化。
微服务优势
1. 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。 在功能不变的情况下，应用被分解为多个可管理的分支或服务。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
2. 这种架构使得每个服务都可以有专门开发团队来开发。 开发者可以自由选择开发技术，提供API服务，实现敏捷开发。
3. 微服务架构模式是每个微服务独立的部署。 开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。
4. 微服务架构模式使得每个服务独立扩展。 你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。
四驾马车
最后再谈谈咱们SuperMap家族中的四驾马车（iServer、iExpress、iPortal、iCloudManager），这些产品也是借鉴了微服务设计思想，例如iCloudManager，它可以管理成千上万的Docker容器，将每个Docker完全做到进程级别的隔离，资源占用率又很小，满足微服务架构开发与测试以及自动化部署运维。
