“
面对 GIS 行业业务数据总量和种类的增多以及对稳定、安全等要求的提高，密集计算、分层隔离、业务上云等需求不断涌现，迫切需要能够集约化利用各类资源的 GIS 架构，超图在 2018 年推出了融合云计算技术的云原生 GIS。云原生 GIS 研发至今，提升了应用系统的稳定性与灵活性，实现了更微、更快、更稳、更智能的服务供应模式，可满足 GIS 智能计算与存储，提供了可靠的 GIS 基础平台底座。
日前，在 2021 SuperMap 开发者大会 “云 GIS 开发专场”，超图研究院副院长胡中南作《云原生时代 GIS 开发全解读》报告，全面介绍了云原生 GIS 的开发、探索与落地的情况，展望了最新技术方向。现分享资料如下：
演讲视频
演讲 PPT
大家好！我是超图研究院副院长胡中南，我的报告题目是《云原生时代 GIS 开发全解读》。
我将从 3 个方面向大家介绍云原生 GIS 技术，包括：第一，这个技术本身是什么？它有什么价值？第二，超图如何拥抱云原生技术？以及它的历程。第三，对于 GIS 开发者，我们该如何采用云原生，一步一步地把云原生技术拥抱起来，去乘风破浪？
第一，介绍一下云原生技术是什么？有哪些价值？
云原生，顾名思义就是 Cloud Native，它就是为云而原生、为云而优化，从而让应用构建和运行更弹性，更充分地利用云的优势。
具体来说有 5 个要素：第一是微服务，第二是容器化，第三是自动编排，前三个是架构部署层面的技术，后两个是流程方法工具，包括持续交付，以及 DevOps 开发运维一体化。接下来我会分别介绍这 5 个技术。
首先是架构的微服务化，它就是把以前的单体应用拆分为多个微服务。比如以前单体架构里有很多个功能模块，包括服务调度、业务功能服务、权限管理等等。
我们把它拆分成多个微服务，放在不同的部署模块里，在最上面有一个服务网关，底下有权限微服务和多个业务微服务，不同的业务微服务都可以进行单独的部署，从而可以让粒度更细，粒度更细就可以让每一个服务可以单独地去伸缩，实现更高的弹性。第二是相互独立，每个服务之间是独立部署的，从而实现了故障的隔离。
第 2 个技术是容器化部署。我们把应用或者说刚才讲的微服务，每一个微服务可以单独去部署到这个容器里面。
容器化部署是由相当于之前的虚拟化、虚拟机这个部署方式来的。虚拟机部署的内容较多，每一个虚拟机都是一个独立的操作系统，加上上面的应用本身。容器化技术比这个更小，因为容器运行时，是一个抽象隔离的层。容器本身只需要放一个应用和一些简单的依赖就可以了。
容器化有哪些价值呢？相比虚拟机来说，它的性能更高，因为它快于传统虚拟机技术。第二是资源占用更少，它采用容器节省了虚拟机里面的操作系统。一个大的空间，容器化资源占用更少，从而可以在同样的配置下面运行更多的服务。第三是可以处处运行，因为容器运行时做了操作系统和应用本身的解耦，可以减少环境的依赖。
第 3 个技术是自动化编排技术，它可以自动伸缩管理多个容器。
比如像本页报告所示，每一个菱形是一个微服务，每一个绿色的圆是一个容器。当这个服务请求比较多的时候，它可以自动去伸缩；当服务请求变少的时候，可以再自动地去收回这些资源，实现自动化的编排。
对应的价值是：第一，弹性伸缩；第二，实时更新，每一个微服务，每一个容器可以去实时地去更新；第三个是可以自我修复，当发现出现故障的时候，可以直接再重新启动一个容器节点来实现自我修复的能力。总体来说提高了自动化，降低了运维成本。
接下来我们介绍另外两个技术。
第一个是持续交付 (CD)。持续交付，就是一套工具与流程，用来实现从开发、构建、单元测试、集成测试、部署到生产环境整个链条的自动化，可以让交付的过程，从以前的手动、要数天甚至数月这么长时间到自动化地、持续地每天甚至几个小时就可以完成。
第 5 个要素是 DevOps，也就是开发和运维的一体化。
开发运维一体化的价值就是可以加快迭代的效能。例如我们有一个需求，通过研发流程，就是 CI/CD 持续集成、持续交付流程，可以将需求变成一个可交付的产品，也就是 Release。此外，我们再把运维和研发也实现集成，就是所谓的 DevOps 一体化。
DevOps 更多是和组织与文化相关。我们往往只关注工具的层面，包括 Git、Jenkins、Docker 等等。更多的还有流程，流程就是持续迭代交付的过程，包括开发、运维、修复等各个环节。
再往上往往不被大家所注意到的就是文化层面，它可以促进研发、测试、运维之间的沟通和闭环协作，来共同达成业务目标。往往来说，工具可能很容易就能够做到，流程和文化却需要更长的时间去持续推动。
CD 和 DevOps 作为流程的价值可以加速交付。以前传统方法是人工的，可能需要几周几个月的时间来推动，复杂度比较高。因为人参与的过程往往容易出错。如果采用 CI/CD、DevOps，它可以几个小时甚至几分钟就实现自动化的构建。因为没有人参与，复杂度就变低了，可以加速新功能推出，减少 Bug。
以上就是我对云原生技术 5 个要素：微服务、容器化、自动编排、持续交付、DevOps 的介绍。
总体来说，它带来了很多改变，包括：应用从单体到微服务；部署从虚机到容器；管理从手动到自动。从而可以让应用更稳定、集约，部署更快速、通用，管理更智能、更易用。
SuperMap 是如何拥抱这些云原生技术？我们如何把这些云原生技术运用到 GIS 平台研发过程中？
首先我们介绍一下 SuperMap 云 GIS 软件的云原生化的过程。
云 GIS 技术发展有以下几个历程。首先是从 2010 年开始，我们做了云使能，从云计算开始做云使能的 GIS，当时用的是虚拟化、集群、负载均衡等技术。这里有两个时间节点，就是对应的两条竖的虚线。
第一个是我们在 2015 年发布的 SuperMap GIS 8C 的时候使用了容器化技术。在那个时候可能云原生这个概念还没有出来。我们用容器化来替代虚拟化。2018 年之后，我们把微服务和动态编排两个技术使用起来，就实现了从云就绪 GIS 到云原生 GIS 的变化。
总的来说，我们把 GIS 服务器也就是 SuperMap iServer 10i 做了全面的微服务，从下层的 GIS 内核做了组件化，上层 GIS 组件有二十多个 GIS 功能，做了功能的拆分，再往上对 GIS 微服务有三十余个 GIS 服务，都是全面的微服务化、容器化，可以实现自动编排运维。
另外，我们在 2019 年发布了 SuperMap iManager for K8s，实现了自动编排运维和 GIS 能力的一体化。
包括 SuperMap iServer、iPortal、iManager 三驾马车都实现了全面的云原生，可以在 K8s 等环境里自动部署。
实现一键的部署，无论是大数据、分布式，还是门户、AI 等环境，都可以实现自动化地一键创建，包括各种数据库，甚至一个自定义应用，都可以实现基于 K8s 集群来自动创建。它通过 K8s 集群向下封装抽象了各种物理环境。
这一部分的报告后面会由云产品研发中心的产品经理周世杰来详细讲述。周世杰长期从事 SuperMap iManager 产品的研发和管理，将会介绍《SuperMap iManager+K8s 部署运维的实战——从 0 到 1 的快速搭建云原生 GIS 平台》。
云原生实践的第二大块是 SuperMap Online，也就是线上平台的云原生化。
因为它是一个线上平台，所以它是除了做技术层面，包括容器、微服务等，还做了 DevOps 开发运维的结合，包括 CD 持续交付的结合。因为这些技术有很多特点和优势，正好可以解决 SuperMap Online 的痛点，包括更新上线慢、周期长、移植性差，以前用虚拟机部署就会有这些问题，采用容器部署可以解决这些问题；包括 DevOps 实现开发应用的结合，可以更快地交付；包括微服务，可以把多个服务模块解耦，避免开发不灵活的问题；包括用持续交付加快上线的周期，更新、更稳定，也更不容易出问题。
SuperMap Online 云原生改造分为三大步，首先从最简单也是最有效的方式开始，就是容器化，将现有服务整体迁移到容器，直接从虚机迁入容器，提高部署的效率。第二步是做 DevOps，就是开发运维一体化，从本地，包括阶段部署、主站部署，统一用镜像，实现 CI 自动构建，避免人工的参与，可以实现滚动的更新。包括逐步地对代码架构、框架进行改造，做了微服务化的改造，让这些复杂的服务逐步拆分，实现微服务化，提高稳定性。因为 SuperMap Online 是基于云 GIS 三驾马车，同时它拥有特有的业务，这些业务也可以实现微服务化。
最后就是持续改进，将云原生 GIS 和阿里云结合，就是 SuperMap Online 的一个部署方式。因为 SuperMap Online 也是采用了阿里云上的一些服务，比如 ECS 服务器、存储 NAS、还有 ACK，也就是容器集群服务，以及各种阿里云的依赖，这也是云原生最直接的优势，可以快速地利用起来，充分地利用云的弹性。
SuperMap Online 采用阿里云的 ACK，这是一个阿里云后台控制台界面。
SupeMap Online 在 2020 年全面迁移到云原生，并且用 Istio 实现灰度发布，也是通过这个服务网格等微服务治理技术，实现灰度发布。
总的来说，SuperMap 云原生 GIS 技术栈，包括微服务层面和容器化层面，有很多层面，后续大家有需要可以再和我们线下交流。
另外一个是流程层面，就是从持续交付到 DevOps，实现 SuperMap 精益敏捷研发流程的管理。前面也讲到这个更多不只是工具，还包括流程、文化、组织等方面。
比如我们做了随需应变的敏捷开发模式。而瀑布开发模式，包括需求分析、设计、编码、测试、发布，时间周期非常长。SuperMap GIS 平台软件的一个大的版本，可能 1-2 年才发布。
这个瀑布开发模式需求一旦在前几个月确定了之后，后面两年的时间就不能改变，或者说变更、更改的周期流程非常复杂，导致发布时间因为需求往往会变化，新需求很难加入，时间也可能推迟。
我们采用敏捷的开发模式，实现需求分析、设计可以在两周之内持续迭代，持续按需交付，时间是可控的。如果需求到期，我们可以在两周迭代之间去动态调配，可以快速响应需求的变化。包括软件也是随时可以用的，因为中间的版本都是经过持续集成，持续交付来实现自动化测试，确保软件的可用性和质量是可控的，最后进行发布。
另外就是我们的持续集成机制，包括开发人员提交代码到代码审查，自动化的审查和人工的审查以及编译打包，这个时间间隔可能十几分钟，只要机器是空闲的，没有其他人提交代码，就会自动地去触发这个构建、打包、自动化测试等流程。
如果中间在任何环节出现问题，都会以自动发邮件等方式反馈，让开发人员可以持续地看到问题，并快速地去解决这些问题。
精益敏捷研发的管理工具集包括 DevOps 一体化，以及其他内容，这里我就不展开讲了。
在前面的部分我们介绍了 SuperMap 平台软件，从流程、方法、工具、技术等环节，对云原生技术的采用。那么 GIS 应用系统开发是否也需要云原生呢？
答案是肯定的。因为 GIS 应用系统开发也是一个系统工程，包括从组织、流程、工具到架构、开发、运维等各个环节，应用系统的开发和平台软件开发本质上都是开发工程。
其次，GIS 应用开发也需要解耦、弹性。不管这个开发项目有多大，它也需要从架构，包括平台选型、数据库选型、架构设计、基础设施等；包括数据层面的数据怎么归类，瓦片怎么生产；包括部署监控，这些服务器、门户系统以及数据部署之后，如果发现问题，如何实现部署监控管理；包括前端 UI，无论你是通过门户定制还是通过扩展定制，还是自定义开发，都需要有一定的开发工作，也需要去结合行业的功能，结合用户的需求去做设计和随需应变。总体来说，GIS 应用开发也是需要解耦、弹性、敏捷。
云原生正好可以实现这些特点，提供解耦、弹性、敏捷等价值。紧耦合，低容错可以通过微服务技术来避免；应用难迁移，资源利用率低，可以通过容器化技术来规避；运维管理复杂，可以通过 SuperMap iManager for K8s 自动编排来实现；迭代更新慢可以通过 CI 持续集成，CD 持续交付，包括 DevOps 运维一体化来提高迭代更新的速度。
另外一个就是趋势，我们的后端基础设施开始云化。不管是行业应用还是基础应用，各种行业云都在逐步地建设过程中。所以，我们作为开发者也需要拥抱这个趋势，就是对应的后端技术云原生化。
那么 GIS 开发者如何来采用云原生新技术呢？
不管是什么新技术，在选型的时候都要考虑它是否先进，是否适用，是否合规。第二就是作为引入途径，我们往往不可能全部从 0 开始，而需要考虑利旧，逐步地去尝新，渐进式地引入这些技术。
结合超图使用云原生技术的经验，我们也提供了一个路线图。首先是做容器化，就是把应用整体迁移到容器，这个是最简单最快速的办法；第二是依赖服务 K8s 化，将我们的外部环境解耦，因为解耦就把第三方依赖部署到这个容器中，并且用 K8s 来自动编排运维；第三步是实现我们自身应用架构的微服务化，将应用中的各种能力进行微服务拆分，就会更加灵活；第四步是把拆分后的微服务用 K8s 来做自动编排运维，进行多节点的运维，这更加复杂；最后一个是在研发流程中使用 CD/DevOps 将开发、测试、上线、验收等过程融合，这就涉及对流程、组织、文化的变迁，也是最复杂最需要长期来开展的工作。
首先，我们将应用三方服务从虚拟机迁移到容器，因为这个技术都比较成熟，大家在网上也可以看到很多资料，这里就不展开介绍了。
第二个是把三方服务从容器化做到 K8s 化。市面上有一些资料，比如《Kubernetes 权威指南》这本书籍，目前已经出到了第 5 版，推荐大家阅读。
另外也可以直接看 K8s 官网的入门文档，包括它在 Windows 上也可以部署运行，并没有大家想象得那么复杂。
第三个方面就是对应用架构做微服务化。微服务化是要把这个架构从单体架构变成微服务架构，把业务逻辑拆分，把服务接口也拆分成多个 API，把数据存储和微服务本身放到一起，实现应用的灵活部署，快速伸缩。
一般来说微服架构设计，因为你把这个服务拆分了，就会考虑更多的东西，但是现在有很多微服务架构的设计框架，比如 Spring Cloud，Dubbo 等，包括可以用 Service Mesh 微服务治理等的技术来实现更好更轻松的微服务架构改造。
这个也有一些对应的参考材料，比如图左的《微服务架构的设计模式》，它把一些常用的架构和考虑都变成模式，让你可以更快速地使用其他的研究成果。另外就是如何设计微服务，推荐阅读《微服务设计》书籍。
在 GIS 里微服务拆分粒度，我们一般是会参考 OGC。比如说 OGC 一个 WMS 服务就可以作为一个微服务的粒度，WCS 服务作为一个服务，WFS 服务作为一个服务，包括 STAC，以及新的 OGCAPIs 都可以天然地作为一个微服务的粒度。同时在最外层做一个 API 网关，来实现这些服务之间的调配。
第四步是应用。从容器化到 K8s 化，容器化 K8s 化也有较多步骤，推荐阅读《凤凰架构》书籍，它对大型服务系统的构建与部署做了详细介绍。
第五是流程组织工具方面，包括持续交付和 DevOps，也推荐两本比较经典的书籍。一本是《持续交付 2.0》，详细介绍了持续交付和 DevOps；另外一本是《DevOps 实践指南》，该书从开发运维一体化的实践和理念进行了阐述。
总的来说，云原生开发理念就是所谓的五分离，云化的五分离包括从存储、计算、服务、治理、应用五个维度进行不同的解耦，存储采用云原生存储，计算采用容器化来作为部署粒度，实现无状态、解耦和弹性，包括服务用 REST、OGC, WebSocket；包括 ProtoBuf 等技术来实现这个服务，API 层面的服务；包括服务治理，前面也提到一些，比如用 SpringCloud、Consul、K8s、服务网格等技术来实现更好地服务治理；包括应用层也可以解耦，用容器来部署你的 Web UI、管理 UI、Web 应用等等。
后续将由超图研究院支持与培训中心支持经理张永利作《GIS 应用云原生迁移实战——如何从 “云就绪” 到“云原生”》报告，欢迎大家收看。
另外一个途径是你可以站在他人的肩膀上。超图云原生套件实现云原生的改造，并且它还支持定制和扩展。
比如这个部署结构图其实有很多维度，从服务的微服务化，从门户、Web UI 层的容器化，从 SuperMap iManager 管理运维层面的云原生化都做了改造，同时每个层面都可以实现定制。
比如我们可以基于 SuperMap 云原生 GIS 做行业微服务的扩展，SuperMap iManager 中的服务治理模块，对自由的 GIS 服务和用户定制扩展的领域服务都可以实现同样的管理运维。也就是说你加入一个新的服务，可以直接不用考虑这个服务怎么治理，考虑什么微服务模式，就可以使用上云原生 GIS 平台软件的服务治理能力。
最后我介绍一下 SuperMap 云原生 GIS 技术将如何发展。
总的来说就是更加原生。我将会从以下几个维度来介绍，比如我们在 Java 平台上面采用 GraalVM 来实现更细粒度，更轻量级的容器镜像。包括采用 Go 这种现代语言，实现更轻粒度更原生的服务开发；包括采用云原生存储，比如阿里云的 OSS 来存储 GIS 中常见的数据，比如瓦片化的矢量瓦片、栅格瓦片等等；包括影像，采用云存储；包括 AI，借鉴 DevOps 技术开发运维一体化，实现机器学习过程和运维，就是实现 AI 工程化的运维，可以快速地实现原生的机器学习平台。
接下来由饶庆云来作《SuperMap iServer 信创环境部署优化实战——从 “能用” 到“好用”》报告。饶庆云长期从事服务器产品的研发和产品推广工作，他在信创环境下也参与了很多实际应用。
我的报告就到这里，谢谢大家！
超图集团
编辑：王宇卫
审核：胡中南 吴晓燕
审签：刘宏恺
近期回顾
●BIM+GIS+IoT 着力打造规建管一体化 “雄安质量”
●“唱响地信” 线上 K 歌大赛邀您参加｜唱地信人自己的歌《经天纬地》
●赞！中国高速公路 BIM 项目获 buildingSMART 国际大奖！
●城市信息模型（CIM）基础平台助力廉江新型智慧城市建设
https://mp.weixin.qq.com/s/bq7btVgI33q1FVJlIbcWjQ
若有收获，就点个赞吧
0 人点赞
