一、自然资源+的多层级立体交叉业务要素，如何组装？
整理出业务事项清单和局内业务运转的总流程后，业务又该如何设计？设计好的业务以什么为抓手落地？如何才能做到反复验证持续迭代优化？
针对自然资源部门“两统一，七个关键环节”的核心职能，参考国家、省级样例，上海数慧对自然资源业务体系做了通用化分类，在每个大类中又划分若干中类和小类。在每个城市落地实施时，根据该城市自然资源管理部门的三定方案和流程要求，做出个性化的调整，快速形成具有地方特色、满足各地具体要求的业务体系。
业务分析设计也是业务治理的过程：在制定业务体系的过程中，需要对业务实行标准化治理，形成标准化的表单、流程、文书证照、报件材料、业务规则等原子级业务要素。在此基础上，通过原子业务要素的组合，形成完整的自然资源业务管理体系，实行“减放并转调”等优化措施。比如，在“多审合一、多证合一”改革中，以前多个不同的审批流程（或环节）具有类似或重复的表单，产生重复的数据录入，容易导致数据前后不一致、业务人员重复审查、群众多跑路等情况。现在通过表单和流程的标准化整合，可以减少冗余环节、实现数据共享、减少重复性工作和出错机会，从而提高业务办理的效率和准确性。
业务组装也是业务持续迭代优化的手段：针对标准化后的各种业务要素（流程、表单、文书证照等），可以参照服务组件化理念，将原来分散在不同应用系统中的流程、表单、报表等业务组件归并起来，封装为流程管理、表单管理、规则管理、报表管理等多个独立的微服务组件，通过服务接口（API）形式，供上层的业务应用系统调用。这些基础的业务服务组件及其相应的API服务接口，即构成越来越丰富的业务服务资产，形成越来越强大的“业务中台”。按照“大平台、微服务、轻应用”的指导思想，将各类业务服务资产下沉，做大做强“国土空间基础信息平台”。然后，在大平台的支持下，通过各种服务接口的编排和调用，采用“快速装配”方式，完成各种业务的组装，实现业务的一体化快速整合和随需应变。
图业务元素微服务化
二、自然资源现有多源、异构、独立的业务应用系统，如何整合？
积累的IT资产，变与不变是两难的抉择，不变影响效率，变则需要考虑成本和可持续性。
自然资源信息化发展至今，在合并了原国土、规划、林业、海洋等不同部门的信息化建设成果后，各类应用系统技术庞杂、运维管理困难等现象。其中，在体系结构方面，有的采用桌面C/S架构，有的采用.NetB/S架构，有的采用JavaEE企业级架构，有的采用面向服务架构（SOA）；在技术实现方面，C/C++、C#、Java、JavaScript、Python等多种语言并存，技术框架不一；在数据存储方面，包含有Oracle、SQLServer、MySQL、Access、MongoDB、FTP等多种数据库技术。若采用传统的应用开发模式，为实现这些应用系统的集成、替换和融合，达到实时协作、数据共享的目标，需要投入巨大的人力物力，以及相当长的时间成本。
针对现有各类自然资源应用系统，在不改变其原有架构和技术实现方式（C/C++实现的仍然保留C/C++，Java实现的仍然保持Java，……）的前提下，将其尚有价值的部分封装为服务接口（API）；对于需要改建或替换的部分，则采用新技术新架构，开发出全新的微服务应用组件，并提供出相应的服务接口（API）。对于这些新旧服务API,都利用去中心化的微服务治理特性，即在微服务的注册、配置、发现（调用）、限流（熔断）、负载均衡、链路跟踪等治理机制的支持下，实现服务API之间的相互调用。通过服务组合，做到已有业务应用和数据资产的快速继承和转型，快速响应新的业务需求，开发出全新的业务应用。
采用微服务的去中心化治理特性，可以最大限度的利用已有的应用和数据资产，减少资源投入，多快好省地解决自然资源信息化面临的技术整合与数据共享等问题。
三、自然资源审批积累的TB级分散的数据资产，如何治理？
数据分散怎么整理？数据服务怎么编排？数据链路怎么打通？
自然资源部门大量异构、多源系统产生了海量的过程和结果数据，目前只是做到了初步的检索，停留在“可查”的层面，其实我们需要从这些数据中看到更多的信息，用数据说话，让数据指导和优化行为、提升工作效率。引入微服务理念后，其快速对接和集成能力、日志收集和链路跟踪促进了数据整合，为数据的分析和使用提供了桥梁与工具。
快速对接和集成能力促进数据整合：自然资源部门与其上级、平级、下级单位间存在密切的协作，映射在信息化范畴本质上是数据的共享与整合，例如与省厅、市政府的公文交换，与审批局、大数据局的数据对接，与省级、国家级的工建平台对接等。
微服务框架中各项业务职能均通过原子服务的编排来完成，在对接与集成方面存在天然的优势，审批过程数据、结果数据均可通过服务提供出来，公文基础信息，也可以通过服务，方便的收入与发出，实现快捷安全的数据共享，辅以微服务网关，可以做到统一接入、安全防控、协议适配和流量管控，保障对外服务的安全可控。
图网关控制
通过快速对接和集成能力，类似于ETL过程，将关键过程和结果数据进行整合，为数据的运用准备好“原材料”。
日志收集和链路跟踪帮助数据说话：日志系统中记录重要服务调用日志、调用链路，直接应用在具体的服务出现异常时可通过日志快速跟踪定位并解决问题；更重要的方面，通过对调用日志、调用链路的大数据分析，可以查找到哪些服务调用频率更高，用于分析流程、表单的设计是否合理以及如何改进（例如多审合一，哪些环节经常需要改派去完成流程、改派到了哪里，依据这些分析可以初步断定环节规则设计存在问题，并根据频率高的操作去提出优化建议），也可以统计哪些服务调用耗费资源较大或者调用速度慢，进而指导系统本身的优化工作，通过对服务调用链路的分析，还可以从服务调用的角度来辅助判断用户操作习惯，提升用户体验。
图日志中心结构图
四、令人抓狂的系统繁杂运维工作，如何优化？
如何让运维更快速便捷？如何不消耗那么多人力？如何形成常态化？
随着自然资源领域机构改革的不断深化，职能调整和流程整合快速推进，已有和在建业务应用系统的数量和规模日益增多。在传统技术架构下，各个应用系统的配置参数高度分散，导致系统运维难度越来越大。对于上级交办下来的紧急任务或改革要求，应用系统的调整往往需要一定的时间来适应，给系统运维和使用人员带来很差的体验，给部门领导以系统繁重的印象。微服务中的容器化、统一配置中心可以大大简化运维工作，提升用户体验以及部门领导印象。
统一配置中心提升运维能力：随着微服务越来越多，独立于应用系统之外的配置文件也迅速增加，传统的XML、JSON文件配置方式存在各种问题，例如格式不统一、不方便管理、配置文件的发布缺少审计等问题。采用微服务特性中的配置中心，可将面向自然资源各个业务域的多种配置统一管理，提升配置效率与准确性。
容器化解放运维人员：采用容器化技术，可实现微服务应用系统的自动化测试和部署，解决当前存在的部署周期长、迭代后系统不稳定问题。避免动不动通宵更新版本，以及人工操作失误或测试不充分而引发的系统更新问题。在解放运维人员的同时，提升系统整体稳定性，提升用户体验。
图配置中心图
五、用户体量大、使用频次高的应用系统，如何健壮？
系统运行如何可靠？如何将系统问题变事后告知为事前预警？
对于单体应用程序，即便是采用了比较先进的SOA架构，但在同一个应用程序内，也依然存在应用组件间的耦合性与整体性。也就是说，系统中某个功能的异常，容易导致整个系统的瘫痪，打断业务连续性。而且单体应用缺乏服务层级监控、预警和治理机制，如果日志记录不够详细，将导致系统排查问题困难，恢复时间长，对业务办理造成严重影响。稳定可靠已经从内需成为影响服务评价的重要内容。
建立容错机制保障系统稳定可靠：针对自然资源全程业务的七个关键环节，可以划分为相应的七大业务域，每个业务域再进一步划分成若干个更小的业务子域。对应于这些业务域或业务子域，开发出独立的微服务应用，实行分开独立部署、运行和维护。当单一微服务应用出现的问题时，可通过限流、降级、熔断来处理，不会对整体系统产生影响。这样，就保障了不会因为系统中某个小的异常而导致整个系统瘫痪，提升了系统的可靠性。
监控中心做到及时预警：单个微服务的异常不会影响系统整体运行，但仍会影响具体的业务功能，需要做到问题的及时发现与解决。不能等到业务办理人员发现功能异常，才来电话轰炸运维中心。监控中心监控每个微服务实例的资源情况（如程序运行情况，内存、堆栈、线程、接口调用日志等），及时发现异常的微服务，快速定位问题。结合多种通知方式（短信、