立足监控，深耕管理——GIS大管家的晋级之道

本文刊登于2018年8月第58期《超图通讯》

经过三年多的发展，SuperMap iManager与云平台的结合由浅到深，监控指标日益完善，如今已发展成云GIS项目标配的一体化监控运维组件。

SuperMap iManager是超图云GIS平台“四驾马车”解决方案的组成部分。经过三年多的发展，SuperMap iManager与云平台的结合由浅到深，监控指标从少许到丰富，如今已发展成云GIS项目标配的一体化监控运维组件。

随着IT技术的发展，传统的GIS服务器架构已经不能满足业务快速发展的需求，微服务改造势在必行。我们选择了Kubernetes作为GIS微服务的部署运行方式，而正在研发的新版SuperMap iManager承担了GIS微服务的管理调度工作，“GIS大管家”即将升级为GIS应用不可或缺的一个必选部分。

丰富的监控报警策略

GIS应用涉及数据、服务、门户等方方面面，背后支撑的服务器、GIS进程、数据库也多种多样。上线运营中，难免会出现突发的异常和资源需求。清晰统一的监控是保证异常得到及时处理、资源需求得到及时响应、GIS业务稳定运转的重要保证。

随着项目实践积累的不断增多，SuperMap iManager提供了越来越多的实用监控指标和功能，在技术方面也不断开放，不仅将监控功能内置，方便普通用户使用，还积极对接IT界常见的DevOps软件，例如提供GIS专用的Zabbix、Prometheus、 Grafana、Kibana等模板，方便已有监控系统的强IT客户引入GIS业务。

°

可定制的大屏概览和拓扑图

为便于直观查看，我们提供了几乎涵盖所有监控指标的大屏概览，值得一提的是，前端页面采用了Web Widget技术，每一个图表都可以根据管理者的喜好随意拖拽、移除，定制大小、位置，同时支持浅色/暗色两种风格的UI切换，保存后形成专属的Dashboard。

为了帮助管理者在查看的同时还能了解系统结构，我们提供了拓扑图版的概览，对异常节点进行闪烁警报之余，还能清晰地看到节点之间的层次关系，直观判断受影响的范围。

GIS节点拓扑展示

°

通用的节点监控，所有内容尽收眼底

SuperMap iManager早期版本只提供了GIS节点相关的监控，例如GIS服务器、GIS门户的热点图、访问统计、CPU、内存等多类健康指标，但没有提供对非GIS服务、节点的监控。然而在实践中发现，除了GIS之外，项目往往还包含了部署行业应用的节点、客户历史节点等内容，只监控GIS业务难免偏颇，不能真正的纵观全局。由此，SuperMap iManager在丰富GIS节点监控指标之余，还提供了通用节点监控入口，只需简单操作，就可以将任意机器加入监控。

节点监控详情

°

多种GIS数据库监控

在生产环境中，地理数据一般会存储在数据库中，数据库也是GIS应用重要的组成部分。了解GIS数据库的运行状态，对提高存取效率、及时发现并处理异常、提升系统健壮性很有帮助。

SuperMap iManager内置提供了对Oracle、MongoDB、MySQL、PostgreSQL等常见数据库的监控，无需复杂配置，在UI界面填写必要的参数后，即可实时查看数据库状态。

Oracle数据库监控详情

°

微信智能报警和管理

系统报警手段多中多样，除弹窗、Email、定制短信之外，SuperMap iManager新提供了微信报警的手段，绑定微信账号后，系统的突发异常就会通过微信发送给管理员，由管理员进一步处理。在微信占据手机通讯主流的时代，这项设置使监控运维变得更加便利。

微信报警和管理

°

高可用的软负载均衡，解决单点失效问题

SuperMap iManager提供通用负载均衡功能，不仅为GIS，还为非GIS的任意Web服务高并发时服务的访问瓶颈提供了解决方案。

SuperMap iManager内置的负载均衡方案，可以把任意GIS服务或Web服务组建负载均衡组，提升业务的并发处理能力。同时附带高可用（HA）策略，可以解决负载均衡中的单点失效问题，助力系统高可用。

所有过程仅需在UI上简单操作即可完成，避免了用硬件负载均衡器的高采购成本和开源方案复杂配置的高时间成本。

GIS服务高可用结构图示

GIS微服务管理之路

微服务架构风格定义为：构建的应用由一系列服务组成，每个服务独立部署于不同进程中，服务间通过轻量级的交互机制来通信，每个服务还可独立扩展伸缩。

在传统的单体应用架构中，一个应用系统包含了所有的业务功能，且应用本身可作为一个庞大的部署单元直接部署，也就是将所有功能部署在同一个进程中。尽管拥有逻辑缜密的模块化设计，单体应用仍然需要整体打包和部署。例如，传统情况下，一个GIS应用对应系统中的一个进程，一个传统的GIS服务启动后，就可以在系统的任务管理器中看到相应的Java进程。

单体应用带来的问题有：

1、系统复杂度高：内部多个模块紧密耦合，关联依赖复杂；

2、运维困难：变更或升级的影响范围大，任何一个简单的修改都需要全部重新上线，还可能导致整体不稳定；

3、无法灵活扩展：不能拆分部署，出现性能问题只能增加服务器或增加集群节点；

4、可靠性低：任何一个模块的问题都可能导致整个系统瘫痪，出现宕机事故。

微服务架构基本思想是：将单体应用封装为多个服务，服务间进程隔离。服务各自独立部署在不同的进程中，这样方便利用多个服务器或计算资源横向扩展，不仅部署升级相互独立，在某个服务成为瓶颈时，还可以快速单独扩展，更加集约地利用资源，在同样的计算环境下，实现更高的可用性。

微服务带来了很多开发和部署上的灵活性和技术多样性，但也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题，需要有一个角色来承担GIS微服务的管理调度工作。在正在研发的GIS微服务化工作中，SuperMap iManager扮演了这个角色。

SuperMap iManager选型了Kubernetes作为这些GIS微服务的部署运行平台，GIS微服务首先被容器化，然后形成GIS容器编排，借助Kubernetes平台部署在服务器集群中，GIS微服务的升级、迁移、动态伸缩通过调用Kubernetes API实现；而日志、监控方面SuperMap iManager已有成熟技术，直接迁移到Kubernetes平台，形成一套融合云原生GIS微服务部署方案。

Kubernetes是一个通用的、用于自动部署、扩展和管理容器化应用程序的开源系统。但只有在应用程序微服务化后，才能在平台中快速伸缩、动态管理，充分利用Kubernetes的特性。

在GIS微服务化设计中，我们把业务服务进行了拆分，业务服务组件中仅保留了功能代码，配置信息、请求流转等都交给了服务治理层处理；服务治理层中，配置中心提供集中式配置服务，注册中心提供服务发现功能，网关服务对服务器请求进行转发；对日志、安全等基础服务也进行了抽离。

°

快速建站

基于Docker技术，GIS微服务被进行了很好的隔离，不再依赖运行环境，开发环境测试通过的微服务容器，可以无差别地部署到生产环境中。在做了编排之后，不仅微服务容器之间的关系固定了，而且部署到服务器集群时，还会根据资源需求和其他约束自动放置容器，仅使用需要的资源，提高资源利用率。

°

自我修复

在云原生GIS微服务系统中，发生异常时会重新启动失败的容器，以便在节点不可用时，替换和重新编排节点上的容器，终止对用户定义的健康检查做不出响应的容器，并在可用后告知客户端。

°

无缝升级

借助Kubernetes，GIS微服务可以在不中断服务的情况下，进行独立的平滑滚动升级。升级时会新建一个副本，在新副本上检测可用后，才会切换对外提供服务；如果升级失败，即服务不可用，平台会自动进行版本回滚。

°

横向伸缩

平台可以便捷地调整某个GIS微服务的副本数，实现横向伸缩，伸缩后的副本自动负载均衡。不仅可针对某个GIS微服务的局部伸缩，避免了传统单体应用伸缩时的资源浪费，还可根据CPU的使用情况或其他自定义阈值自动伸缩，实现系统的自运维。

SuperMap iManager秉承实用的精神，以开放的心态拥抱IT技术，在集成新技术的同时，提供被集成的手段，做开放的智能监控解决方案；同时积极投入GIS微服务改造，在云计算时代，为用户提供真正云原生的云GIS落地方案。

云原生GIS服务器体系结构

作者 | 超图研究院云产品研发中心 苏乐乐

责编 | 王静静

【近期回顾】

▼

欢迎转载~