[toc]
前言
架构的演进从来不是一撮而就的，也不是一成不变的，从来就没有所谓的最NB的的架构，只有最适合的架构。我们说架构的演进，都是根据业务场景，从实际情况出发来谈的，脱离了业务场景空谈架构，都是耍流氓。综观哪些伟大的公司的伟大的产品，他们的技术架构也不是一步到位的，而是在业务需要的倒逼下，一步一步发展起来的。《淘宝技术这十年》这本书就深刻的阐述了上面的这个道理，没有最NB的架构，只有合适的架构。下面我就结合我工作中的一个真实的业务场景，来学习一下我们是怎么一步一步的构建了高性能可扩展的遥感智能解译系统的。
一、业务场景
下面我从三个方面说明下我们在构建系统之初的一些规划，我会分别从项目背景，产品设计以及技术栈三个维度分别进行介绍。
1.背景介绍：
我们的主要服务对象是地理信息行业，主要的业务是根据地理信息行业的业务场景提供具体的技术解决方案，地理信息行业又可以细化为遥感测绘、地图服务、导航定位服务、地理信息系统等等，我们主要面向的遥感测绘行业，主要的数据类型包括遥感影像数据，雷达数据，卫星影像数据，矢量数据，点云数据等等。遥感影像数据，雷达数据，卫星影像数据有一个共同的特点是：单文件非常大，最大可以达到TB级数据，最小的也有几十G左右，还有就是影像数据分辨率特别高，可达亚米级别。我们要做的事情，就是基于这些数据，根据遥感中心的业务需求，给出响应的技术解决方案。
随着WEB3.0时代的到来，带来了各行各业都得到了快速的发展，地理信息行业同样也在时代的浪潮中滚滚向前，他们面对的是海量的遥感数据，灵活多变的业务需求也需要迫切的展开，他们急需一套完整的数据管理系统来帮助他们快速的构建他们的业务，管理他们的数据。正是在这样的背景下，遥感数据管理平台应用而生。
2.系统设计：
遥感数据管理平台旨在打造一套从数据生产到数据应用的全生命周期管理的数据资产底座，形成了全流程、自动化、智能化、模块化的业务生产服务能力；形成数据贯通、资源共享、功能集成、服务响应的服务能力，为行业应用提供基础数据、要素产品、数据智能分析、空间分析、二、三维展示等数据保障和多元化技术支撑。
因为系统供应商不同，以及系统本身技术复杂度等原因，遥感数据管理平台被设计由俩部分组成，为数据湖及遥感智能解译系统组成。数据湖系统负责整个平台的数据管理，业务应用，数据治理等业务。遥感智能解译系统则主要负责遥感数据的智能解译相关的功能，包括模型的管理，数据集的管理，模型训练及数据解译等工作。
数据湖具体产品架构设计如下：
从上图可知，数据湖整体上分为应用层，支撑层，存储层和存储平台等：
- 业务层：主要为用户提供业务所求，包含数据展示，遥感监测，数据统筹，专项监测等等，
- 支撑层：主要负责系统的正确运行，包含用户认证，系统监测，任务调度，大屏管理等核心功能，
- 存储层：主要负责底层数据的管理，包括数据的采集，入库，存储，治理等等。
- 平台：系统存储平台涉及NFS网络共享存储，对象存储，数据库存储技术及内存数据库的。
遥感智能解译系统架构如下所示：
遥感智能解译系统同样包含应用层，支撑层，存储层和存储平台：
- 应用层：主要为用户提供业务功能，包含地物分类，道路检测，水体检测等功能。
- 支撑层：为遥感智能解译系统提供业务支撑功能，包括遥感数据的处理及遥感数据训练等能力
- 存储层：主要存储遥感数据的各种形态数据，包括模型数据，数据集，瓦片数据，遥感数据等。
- 存储平台：主要指系统的运行环境及数据库的存储平台，包含本地文件系统，数据库系统和共享网络文件系统等
3.技术栈设计：
- 微服务搭建：基于Spring Boot Alibaba 技术栈进行微服务搭建。
- 大数据计算：基于Spark进行离线数据计算
- 大数据调度系统：基于Azkaban构建任务调度系统
- 海量数据存储：基于对象存储OSS进行数据存储
- 遥感数据解译：基于人工智能-计算机视觉模型（RCNN，YOLO）进行遥感影像数据的智能解译。
二、初代遥感智能解译
在项目的初期，我们首先解决的是有无的问题，我们需要根据项目需求和业务场景为用户提供系统产品，这也是用户最迫切需要的。
1.目标设定
数据湖实现数据管理基本功能，智能解译系统实现数据解译等工作。同时，能够从数据湖中进行遥感数据的下载，然后在智能解译系统中实现遥感数据的解译。有些人可能要问，为什么不直接把数据放在智能解析系统，对于这个问题，我们的回答是：我们对俩个系统的定位不同，遥感智能解译系统我们更多的理解它为一个工具，不涉及数据的大规模存储，数据湖才是项目的主体和底座，所有的业务及功能应该是围绕着数据湖来展开。
2.架构设计
项目的架构设计图如下，我们分别实现了数据湖功能和智能解译系统，对于数据湖与智能解译之间的数据串联，我们主要还是通过人工的方式进行，主要原因是产品有俩个项目组独立负责，同时也有项目周期，项目人员，项目排期等原因。
3.成果及比较
基于上述的产品架构，我们基本上完成了项目的主要功能，数据湖实现了遥感数据的基础管理，智能解译系统能够实现遥感数据智能化管理。
4.缺陷或不足：
因为篇幅和本章主题的原因，我们这里只讨论数据湖到智能解译系统相关的问题，其他问题不是本文的重点。我们目前主要的问题是数据同步效率低下，项目需要专业的业务人员根据业务场景和数据特性进行数据筛选，然后进行数据下载到客户端，通过U盘或者硬盘同步数据到智能解析系统，实现数据的存储，入库成功之后才能够进行数据解译，几点整理如下：
- 数据筛选困难，需要专业人员进行数据筛选
- 数据同步慢，需要业务人员进行数据下载，数据上传等操作，而且无法同步进行
- 数据回传慢，对于数据解译成功的数据，业务人员需要再次进行数据导出，数据入库，整个流程非常的缓慢。
智能解译系统处理一幅500G大小的影像数据，需要差不多8个小时的工作，效率非常的低下。在业务量大的时候，是很难满足要求的。
三、自动化遥感智能解译
1.问题分析：
针对上述问题，我们分析了整个链条，总共涉及了7个步骤，如下图：
其中数据传输时间占了1.5小时，数据解译等占了2小时，数据等待4个小时，占了整个用时的50%，我们需要自动化的数据下载，上传等功能来简化和优化数据的解译流程，重新设计数据的解译流程：
我们分别完善数据湖功能和智能解译系统功能，实现了数据湖的自动下发，智能解译数据的自动接入，解译完成之后的数据自动上传到数据湖等工作。
2.目标设定
- 优化原有数据湖功能和智能解析系统功能，使之支持数据湖数据自动下发，自动入湖操作。
- 优化智能解译系统，使之能够自动数据接入，解译完之后的数据自动上传入湖。
3.架构设计
我们完善了原有的设计架构，在数据湖中增加了消息推送模块，在智能解译系统中增加了数据接收模块，架构图设计如下:
和初代的相比，我们在数据湖中加入了消息推送模块，主要服务入湖消息，下载消息的逻辑处理，智能解译系统增加了数据接受模块，主要负责数据湖数据的下载及本地解译数据的上传工作，几点整理如下：
- 数据湖-消息推送：数据入库，数据下发消息通知
- 智能解译-数据接收：数据湖数据下载，解译数据数据湖上传
3.技术方案：
针对对象存储OSS中存储的数据，我们使用的是对象存储OSS JDK进行编程的，对于本地系统数据的下载上传，我们使用的是JAVA JDK 构建。
- 对象存储-数据下载上传：基于OSS JDK实现对象存储数据的下载上传，
- 本地系统-数据下载上传：基于Java 实现本地数据的下载上传
4.成果及比较
通过对人工进行数据传输模块的优化，我们实现了从数据湖到遥感智能接系统之间，数据的自动流转工作，效率得到了大大的提升，大大降低了人工的参与，整个过程，时间由8小时降到了4小时一下，整体速度提升了进一倍。
5.缺陷或不足
虽说从8小时到4小时有了一倍的性能提升，但是，对于用户来说，没有最好，只有更好。因为自动化的引入，同时也暴露出来一些不足：
- 效率：8小时变为4小时对于此时的用户来说，还是觉得时间有点长
- 稳定性：因为自动化的引入，增加了系统的不稳定性，系统在数据的传输过程中，因为网络的问题有时存在传输错误等问题，数据丢失等问题
- 传输速率：自动化数据下载上传时的网络传输速率在200M/s左右，速度有点慢，远远没有达到网络带宽的限制
四、高性能遥感智能解译
自动化模块的引入，引入了系统的不确定性，同时数据的传输速率也有很大的提升空间。我们需要在解决稳定性的同时，提供速度的传输速率，我们既要，也要，我们不光要鱼，还要熊掌。
1.目标设定
我们需要同时满足稳定性和速度的要求。
- 稳定性：提高数据湖与智能解析系统之间进行数据传输的稳定性，支持断点续传，支持MD5校验，支持断网重传等能力
- 传输速率：数据湖与智能解析系统之间，数据传输速率至少需要达到1G/s的传输速率，
2.架构设计
优化上述架构设计，完善智能解译系统-数据接收模块，更改为数据接收Agent，完善数据湖-数据推送模块，更改为数据订阅/推送，架构入下图所示：
上图中，我们分别引入了智能解析系统-数据接收Agent和 数据订阅/推送模块：
- 智能解译-数据接受Agent：实现智能解译系统和数据湖的数据上传与下载，同时通过心跳机制，保持与数据湖的连接，对于超时的情况，进行数据续传或进行数据重传的。
- 数据湖-数据订阅/推送：负责对智能解译系统进行数据订阅和数据消息推送，同时与Agent保持长连接，支持通过订阅的方式对数据进行自动派发机制。
3.技术方案
- 数据订阅/推送：基于消息中间件RabbitMQ实现智能解译系统与数据湖系统之间的消息订阅与发布，
- 保持心跳：通过微服务架构Spring Boot Alibaba 技术栈，Agent定时与数据湖保持心跳，对超时的连接，数据湖不进行数据下发，只有在线的Agent能够接受到消息，重新上线的Agent可以接受到历史消息。
- 数据并行传输：Agent集成qscamel实现数据的高并发上传下载，同时支持数据的重传或端点续传。
4.成果及比较
基于上述架构的优化，智能解译-数据接受Agent与数据湖-数据订阅/推送目前支持稳定的数据传输，成果如下：
- 稳定传输：基于数据订阅及心跳机制，保证了数据湖与智能解译系统之间数据消息的稳点传输，通过消息中心保证了数据的不丢失
- 断点续传：通过集成qscamel，实现了影像数据的断点续传，数据重传及MD5校验等功能。
- 高性能传输：基于qscamel，实现了数据的高并发传输及高性能传输，数据传输性能提高了6倍，速率可以到达1.5G/s 左右。
5.缺陷或不足
引入Agent代理端机制的优势在于它实现了点到点的数据快速传输，不足的是需要在远端服务一对一部署，如果我们现在同时存在一个类似于智能解译的业务场景，那么我们需要搭建同样的一套Agent进行数据同步，这对于我们来说是存在一些如下痛点：
- 1.可扩展性差：如果同时对多个Agent进行数据推送同一份数据，如何保持数据的一致性
- 2.数据重复传输：如果同时对多个Agent进行数据推送同一份数据，存在大量的重复数据传输等情况，有没有只传输一次，多地可用的技术呢？
- 3.客户端业务单一化：目前Agent只针对客户端进行单一的业务处理，如何让Agent同时支持多个业务处理，而且性能还不下降，业务之间能否达到速度平衡是接下来需要考虑的。
五、高性能可扩展的遥感智能解译
上面高性能遥感智能解译已经可以满足用户95%的业务场景了，对于如何面对更好的可扩展是接下来需要考虑的问题。假设我们在A端点部署了一套智能解译系统，现在我们需要在B端部署一套类似的系统，数据湖现在需要同时给A端和B端进行数据传输，假设我们需要传输的单文件遥感影像大小为500G，按照一天需要处理的遥感影像数据为40幅，则我们需要传输到A端的数据体量大概为：500G*40=20T，按照1G/s的速度来算，需要传输20000G/60/60=3h左右。如果我们往A端同步的同时，也往B端同步，同样的，我们需要划掉额外的3小时，传输体量达到惊人的20T， 有没有一个高性能的方案，能够让我们只传输一次，可以同时在多端使用是我们接下来要解决的事情。
1.目标设定
针对上面我们对现有业务架构的剖析，如果我们同时往A端和B端传输数据，可能会划掉额外的3H小时和用掉20T的数据盘，我们需要做的就是：
- 时间和空间：同样的数据只传输一次，可以在多端共用，不仅可以节省传输时间，而且节约了硬盘资源，一举俩得。
- 可扩展性：未来我们面对的业务不光有A类，B类，也可能面对C类，D类，我们需要设计一个灵活的数据共享框架，做到一次传输，多端使用，做到正真的可扩展。
2.架构设计：
根据上述的业务目标，我们分别调整了我们现有的智能解译架构和数据湖架构，优化了智能解译-数据接受Agent，数据湖-数据订阅/推送，同时在数据存储层面，我们增加了对网络共享文件系统NFS的支持，方便在业务远端进行灵活使用。
- 智能解译-数据接受Agent：完善对NFS共享网络文件系统的支持，支持动态挂载NFS文件系统，支持文件重传判断等能力
- 数据湖-数据订阅/推送：完善对NFS共享网络文件系统的支持，支持动态调度远端数据接收Agent，进行文件传输或者文件状态判断等逻辑。
- 智能解译-NFS共享网络文件系统：主要为远端文件系统提供高性能文件读取性能，NFS共享网络文件系统不是在本地，其他远端可以挂在本地端点进行数据使用。
- 数据湖-NFS共享网络文件系统：与智能解译-NFS共享网络文件系统不同的是，数据湖-NFS共享网络文件系统提供更加易用的文件访问协议，通过在数据湖侧完成数据的同步操作，在远端直接挂载使用，但是性能上可能没有部署在本地端点性能那么高。
3.技术方案
- 智能解译-数据接受Agent：支持对NFS文件系统的文件状态判断，文件版本判断等操作。
- 数据湖-数据订阅/推送：整体调度管理Agent，协助Agent对文件进行智能化输出，避免文件误传或文件修改传输等操作。
- 智能解译-NFS共享网络文件系统：部署在系统运行本地的NFS系统，本地系统通过读取本地文件的方式进行文件管理，其他远端想进行文件管理，则挂在此NFS网络文件系统即可，如下图。
- 数据湖-NFS共享网络文件系统：部署在数据湖的NFS文件系统，针对的是多端都需要共同的数据文件，我们只需要同步数据到这里的NFS共享文件系统，其他多端只需要挂在此文件系统即可，如下图。
此处技术稍微复杂一些，附上本地挂载NFS,远端挂载NFS中间的数据流转：
挂载盘A是部署在智能解译本地硬盘之上的，所以智能解译系统访问数据还是通过本机接口进行的，同时挂载盘A还在业务1和业务2分别哟挂载点，业务1和业务2可以同时对挂载盘A进行文件读写操作，此处需要通过读写锁进行分布式管理，防止对统一文件进行同时读写。
挂载盘B是一块共享网络盘，分别挂载到了业务3，业务4和数据湖，他们可以同时对共享挂载盘B进行文件读写，主要场景是数据湖通过挂载点5对挂载盘B进行文件写入，业务3和业务4读取挂载盘B中的数据。
4.成果及比较
通过多端Agent技术架构及NFS网络文件系统，我们实现了在多端进行统一文件系统管理，不需要同一份数据重复传输多遍的情况，大大节省了时间和空间，提高了系统的可用性和可扩展性。
- 可扩展性：其他远端需要我们的共享数据，不需要重新适配Agent，只需要挂在NFS网络文件系统即可，轻松实现数据访问。
- 时间和空间：通过文件唯一性判断和文件存在接口判断，同一份数据我们做到只传输一次，节省了大量的时间和空间，非常方便多端的使用。
小结
通过前面四个阶段的架构升级，我们实现了遥感解译系统与数据湖之间的高性能可扩展的数据传输，智能解译系统能够实时高性能的使用数据湖中的数据，通过智能解译系统的智能解译，成果数据也能实时的回到数据湖中方便对数据进行统一管理。我们从最初的从0到1实现了智能解译和数据湖系统，进而实现了他们之间的自动化数据传输和高性能数据传输，最后实现了数据远端可扩展架构，大大提升了系统的生产效率，节省了数据生产的周期和占用存储资源。
通过上面整个技术的演进来看，也正应了我们在开头说的那句话，架构的演进从来不是一撮而就的，从来就没有所谓的最好的的架构，只有最适合的架构，架构的演进，都是从业务场景的实际情况出发而演进来的。脱离了业务场景谈架构，都是耍流氓。
本节关于数据湖与智能解译系统之间的数据传输进行详细的技术演进的说明，系统架构的展开也是围绕着个维度进行的，并不代表我们的系统架构就是这样的，我们的系统架构远远超过了上文中输出的，其中有很多功能没有讲到，文中有什么不对的地方或者有疑惑的地方，同学们都可以提出来，我们共同的学习，共同进步。
