高精度位置服务平台分布式架构研究与设计

李艳红，成芳，沈朋礼，刘东亮，李晓婉

(1.中国科学院国家授时中心,西安 710600；
2.中国科学院精密导航定位与授时技术重点实验室,西安 710600；
3.中国科学院大学,北京 100049)

近年来，北斗卫星导航系统(BDS)应用快速发展，高精度位置服务越来越多地应用到了各行各业，尤其在测绘、精准农业、形变监测、地震监测、电力监测等领域都被广泛应用[1-2]. 很多省市都抓住北斗发展机遇，大力发展位置服务产业，北斗位置服务平台的建设在省级、地市级逐步开展，像黑龙江省、湖北省、辽宁省、陕西省都建设了符合本地发展需求的区域位置服务平台，这一系列区域公共服务平台的建设改善了北斗散户自发的粗放式应用的局面，将其发展成区域公共服务平台统一运营的增值式高效益应用，更加有利于北斗产业的可持续性发展. 但这些平台只面向区域提供服务，区域与区域之间的服务平台相对独立，各区域平台针对性强、适用性较低，缺少一个相对统一的系统标准，各个区域位置服务平台之间存在重复建设的现象，位置服务数据存在大量冗余，计算资源和存储资源也有很大的浪费. 目前在国内面向全国范围的统一的公共位置服务平台暂时空白.

北斗“一带一路”高精度位置公共服务平台(以下简称高精度位置服务平台)跨越区域限制，面向全国和“一带一路”沿线国家提供位置服务，具有规范的数据、服务、安全、存储等技术标准. 平台采用基于云计算概念和技术的数据中心解决方案，力求建设完成国内最权威、架构最完整、技术最先进、功能最强大的位置服务大数据云平台. 目前高精度位置服务平台集中了高精度位置服务的所有业务，其信息化连续性直接关系到用户体验和服务质量，随着用户量和业务的快速增加，平台将会面临越来越大的访问压力、计算压力和存储压力. 针对这一发展的急切需求，我们提出了在广西、泉州、成都等地建立高精度位置服务平台分中心的发展规划. 面对多中心的布局，如何根据高精度位置服务的不同业务特点，设计主中心与分中心之间的分布式系统架构，使得主中心与分中心之间能做到系统架构融合互通、平台资源相互支撑、数据资源相互共享、业务流程相互促进，则是需要迫切解决的关键问题，也是本文的研究意义所在.

目前已有学者在位置服务平台以及多数据中心业务系统的架构设计上进行过相关研究. 黑龙江位置服务平台[3-4]采用分布式部署与应用模式，在黑龙江省架设总站点，在多地区布设分站，但在平台架构上还是采用集中式架构，以国家“天地图”和省(市)级节点提供的地图服务资源为数据基础[5]，提供规模化、业务化位置服务. 辽宁省北斗高精度位置服务平台[6]采用传统的集中式架构，针对东北高纬度地区可见卫星数量少，空间分布不佳导致的信号接收困难、定位时效性差的问题提出了多星多模数据融合定位. 湖北省BDS 高精度位置服务平台[7]业务体系架构分为基础设施层、应用支撑层、功能服务层、应用层以及表现层，应用支撑层为整体架构设计的核心部分，搭建了可动态扩展的、高可靠的位置服务云平台，平台根据功能服务层各应用领域的需求，为不同的应用领域提供位置服务. 上述区域位置服务平台架构均为集中式架构，拓展性低，集中式架构使得整个平台构成过于复杂，维护成本高，同时也不适用于多中心的运行模式. 秦浩等[8]针对双中心的客服业务系统采用了分布式架构，从用户接入、服务调度和数据复制等多个方面介绍了异地双数据中心的分布式应用架构，实现了双中心的系统容灾和快速切换. 姜青云等[9]针对商业银行多中心运行模式提出了分布式异地多活的基础架构，对其架构进行介绍的同时也指出异地多活运行模式不仅能够容灾还能高效承担业务任务. 上述学者分别对区域位置服务平台和多中心的商业业务系统架构设计进行了研究，但在异地多中心的高精度位置服务平台分布式架构设计上的相关研究却是近乎空白.

本文在以上学者研究的基础上，针对高精度位置服务平台的业务特点以及异地多中心的运行模式对高精度位置服务平台进行总体架构设计以及分层设计，采用目前主流的技术框架结合业务模块，构建一个满足功能和发展需求的高可用、高性能的分布式架构，为平台的业务支撑提供保证.

合理利用分布式架构的技术先进性，采用业界主流的先进技术与模式，并与高精度位置服务业务相结合，确保先进技术与业务模式的有效与适用. 从整体上提高平台的可靠性，降低平台对单一设备可靠性的要求，使得支撑数据中心的资源根据业务应用需求进行弹性伸缩，实现系统的灵活扩展. 构建一个与业务平台相适应的高性能、高可用分布式架构，实现主中心与分中心之间系统架构融合互通、平台资源相互支撑、数据资源相互共享、业务流程相互促进的目标.

高精度位置服务平台主要实现对24 个国际GNSS监测评估系统(iGMAS)以及广域的北斗地基增强系统国内框架网155 个基准站的观测数据、广播星历以及状态空间域(SSR)的实时接收，对于接收到的数据进行统一的管理、分发、处理和存储，并基于这些数据为用户提供其他位置服务. 例如将接收到的实时观测数据要进行统一的存储外，观测数据也可进行质量分析与评估，并通过页面展示或邮件发送数据分析评估结果，从而实现对用户提供数据质量分析服务；
SSR 改正数则可通过平台向用户直接进行播发，为其精确定位提供数据支撑，同时SSR 改正数与广播星历也需要进一步处理生成精密轨道钟差文件，并将其进行存储；
除此之外，接收到的实时数据可根据用户需求用于实时动态定位和实时静态定位以获取精确的定位结果，存储的数据需要为用户提供下载服务等.

高精度位置服务平台的主要功能设计如图1 所示.

图1 高精度位置服务平台

1) 用户管理功能

高精度位置服务平台用户主要分为三类，分别是超级管理员、平台管理人员和获取服务的用户. 不同角色对应不同的权限级别，超级管理员主要是对所有用户账号进行管理并对用户进行权限分配；
平台管理人员负责不断开发和完善平台功能以及对平台状态、各类基准站状态等进行监控和日常维护；
获取服务的用户可在平台进行账号注册和个人信息管理，根据不同应用需求对其进行分级分类，登录账号后获取相应服务，这样以便为不同用户提供分级分类的位置服务.

2) 实时数据接收功能

高精度位置服务平台实时数据主要来源于地基增强系统国内框架网155 个参考站以及24 个iGMAS站. 接收的实时数据包括观测数据、广播星历、SSR产品改正数等. 能够实现Ntrip 实时数据接收及模拟测试数据读取，获取实时数据流之后进行实时数据流解码，并校验各测站的数据完整性. 同时也可以接收用户观测数据以帮助用户完成定位解算. 由于该项功能中的站点，其数据是相互独立的，可以单独接收、处理，因此，适用于分布式处理的方式，每个数据中心只接收、处理部分站点数据.

3) 数据存储功能

接收到的观测数据、广播星历、SSR 产品改正数以及用户观测数据均需进行存储，以便数据的使用和数据核验. 为保证高可用、高可靠和经济性，同时采用结构化存储和非结构化存储，对用户信息、基准站信息等采用关系数据库存储，对于海量文件采用分布式并行存储系统来存储. 分布式并行存储系统支持大量数据和文件的并发读写需求，同时也可以实现容量海量扩展、性能线性扩展，这也完全满足了平台数据量日益剧增和持续发展的需求.

4) 数据产品播发功能

数据产品的播发主要是实时数据和实时产品的播发，将标准化为RTCM 格式的数据流以Ntrip 协议进行封装，外部用户作为Ntrip Client 通过发送请求报文获取Caster 的返回数据流，以此向其他用户提供标准的Ntrip 数据播发服务.

5) 数据下载功能

数据下载功能是指外部用户根据自身需要下载存储系统的观测数据、广播星历、事后精密产品等数据. 平台对外提供统一的服务接口，参照行业规则建立FTP 服务器，对外提供FTP 下载服务，使得外部用户可以访问、下载平台提供的数据.

6) 数据质量分析功能

数据质量分析主要是对各站点观测数据进行分析，数据来源包括从基准站实时接收的数据流、数据存储服务器的数据以及用户上传数据三种. 能够通过结合广播星历、电离层产品和精密产品等分析观测数据从而计算各站点卫星系统位置精度因子(PDOP)、多路径、时序图、星下点轨迹、用户测距误差(URE)、用户等效距离误差(UERE)等，评估结果能够通过页面进行展示并存储.

7) 精密产品生成功能

平台可以实时接收广播星历、轨道、钟差、电离层等实时差分改正数，接收到之后除了进行实时播发，也能够处理生成可供用户进行事后精密单点定位(PPP)的SP3、CLK、DCB 文件，并将这些精密文件进行存储，给用户提供事后精密产品下载服务.

8) 实时精密单点定位功能

基于实时数据流以及实时SSR 改正数产品的接收，进行实时精密单点定位(RT-PPP)解算，从而得到米级甚至分米级的定位结果. 该功能包括多用户并行实时数据预处理模块、误差模型改正模块、多用户并行 RT-PPP 计算模块、多用户并行RT-PPP 结果质量控制模块、多用户并行RT-PPP 结果展示模块，同时能够保证万名用户并发访问、并且具备事后文件输入仿真实时计算的能力.

9) RTK 定位功能

平台RTK 定位功能提供完备的网络RTK—虚拟参考站(VRS)定位功能，RTK 定位基于实时数据流以及用户信息进行组网解算生成虚拟观测数据，结合用户实时观测数据进行RTK 定位解算，能够实现实时厘米级的定位精度. 该功能能够满足对实时性和定位精度都有要求的用户服务，同时RTK 定位是区域定位，在各分中心进行RTK 定位模块的部署，当用户请求RTK 定位服务时可根据用户所在区域进行分区分域任务分配，能够有效降低服务请求的响应时间，提高用户体验.

10) 定制化方案接入功能

平台根据用户不同的定位需求提供RT-PPP、RTK 等完备的基础定位解算功能，但在是实际应用中有多元的应用场景，例如滑坡监测、车辆管理、房屋监测等，这就需要根据行业需求进行定制化服务方案. 平台提供定制化服务接入接口，定制化解决方案可以通过该接口获取平台实时数据并依靠平台计算资源进行相应解算.

11) 定制化方案管理

定制化方案管理即为对定制化方案接入的不同应用场景的管理，主要记录每一个定制化解决方案的基本信息，包括该定制化方案名称、状态、主要服务所在地，以及项目的创建时间、修改时间等，保证每一个定制化方案都能记录在册，方便平台管理人员对项目的的添加、查询与维护，将每一项平台延伸的定制化服务都作为平台的一部分进行统一的管理与维护.

12) 状态监控功能

状态监控功能主要分为两部分，一是通过对实时流数据传输的监测从而对基准站状态进行监控，二是对收集平台运行信息并监控. 对基准站运行状态进行监控，出现异常的站点或者不在线站点以及对未接到实时流数据站点进行异常提醒，连续监测平台的运行状态，出现异常进行警示，提示平台运维人员进行维护.

13) 日志管理功能

日志管理功能是平台运行时各种信息的流水查看功能，主要提供平台运行期间出现的各种日志的查看功能、平台基础服务被外围系统调用的日志查看功能、平台管理人员对平台内部进行的优化、更新、维护等的日志的查看功能、用户操作的日志查看功能等. 通过对平台内各种日志信息的管理有利于平台日常管理和维护.

高精度位置服务分布式架构方案就是针对位置服务平台多中心异地模式，为使得主中心与分中心之间协调工作，实现数据资源相互共享，业务流程相互促进进而扩展设计出的一套高性能和高可用的异地多活分布式架构. 整体的分布式异地多活基础架构如图2 所示.

图2 分布式异地多活基础架构

分布式异地多活首先各个数据中心在地域上是分布的，而非集中的，其次数据中心在机房基础设施、计算资源、存储资源和网络资源的软硬件部署上是分布的而非集中的. 但是多个数据中心之间可以实现资源调度以及基于全局的运维管理，并且每个数据中心都承担一定的业务服务，相互之间协同工作. 当某一数据中心发生故障时，其他数据中心可分钟级接管用户流量，并对关键业务实现接管，达到互为备份和共同承担业务的双重效果[9].

在架构设计上总体采用Dubbo 分布式架构体系，该架构体系的中文文档在国内开源框架中当属一流，为后期开发提供了强大的支撑，其在国内的应用也已有很多成熟案例，同时Dubbo 采用RPC 服务调用方式，相比于目前市场上其他的分布式架构体系具有更好地服务调用性能，更适合异地分中心的运行模式. 业务模块采用微服务集群的形式组合发布，设计的平台分布式架构如图3 所示，从上到下一共分为四层，分别是接入层、应用层、服务层和数据存储层.

图3 平台分布式架构图

1) 接入层

接入层完成用户访问数据中心的第一级流量分发. 用户通过web 浏览器、手机APP、第三方用户OpenAPI 等访问网站请求服务. 在服务请求这一过程中接入层通过域名解析(DNS)智能解析遵循就近原则将用户定向到相应的数据中心，完成用户分流的同时也将用户分配到距离自己最近的分中心(或主中心)，能够减少传输距离，有效降低时延，提升用户体验感.

2) 应用层

应用层主要用于定义业务的工作流程，根据平台功能性需求分析我们可以将高精度位置服务平台划分成用户管理、状态监控、定制化方案管理、日志管理、数据下载、数据质量分析、RT-PPP、网络RTK、定制化方案接入和提供实时产品十大业务模块. 根据各项业务特点按照一定的划分规则来将各项业务划分到不同的数据中心，使得各数据中心能够共同分担访客流量，协同工作.

为了实现业务内聚保证服务实时性，我们选择用户区域作为划分业务的单元，这也就是“单元化”. 把地理位置上接近的用户、基准站划分到同一个中心(机房)，这样用户区域定位的整个流程在同一个机房完成，避免了跨机房调用造成的时延，这样既符合实时数据接收的分布式处理也能在区域定位中保证最小的时延，而像广域定位这种无需单元化的请求则直接分配在主中心完成. 依据这种划分规则进行如下划分：首先主中心应具备提供所有服务的能力，分中心提供部分服务，并与主中心做数据同步. 由于SSR 改正数由主中心来实时接收并播发，所以RT-PPP、提供实时产品服务仅由主中心提供；
网络RTK 是区域定位，需要借助周边基准站来实现，所以网络RTK 服务由分中心来提供；
数据分析、数据下载、状态监控、定制化方案管理、日志管理和用户管理等服务均由各分中心提供服务，并与主中心做数据同步.

每一项业务都由一个服务器集群承载，当同时访问同一业务模块的用户量激增时，或者分中心用户访问某一业务需要转至主中心来完成时，需要将这些请求做负载均衡分配到集群中的每一个服务器上，从而提高平台的整体性能，因此在应用层引入Nginx 集群实现负载均衡. Nginx 作为开源软件相较于硬件实现负载均衡成本更低，同时相较于LVS、HAProxy 等负载均衡软件又具有通过配置能够同时实现负载均衡和反向代理两项功能的优势. 其反向代理功能可减少用户访问网站过程中由于静态资源加载所造成时间延迟. Nginx 作为反向代理服务器将静态资源缓存起来，当用户发起获取网页请求时，静态资源可以直接从反向代理服务器上获取，加快访问速度. 另外，可以采用Nginx+Keepalived 心跳维持组件实现负载均衡的高可用性. 应用层的程序应当是无状态的，不保存任何的中间数据，它将服务ID、函数名以及相关参数传给服务层框架，框架再将这些参数分配到具体的服务上执行[10].

3) 服务层

服务层是一个服务集群，每一项服务都是相对独立的，能独立完成一项任务，并且可以被多个应用程序复用. 本文结合实际业务功能将高精度位置服务平台拆分为权限管理、用户信息管理、实时数据接收、数据产品播发、精密产品生成、RT-PPP 处理、RTK处理、数据质量分析、数据下载、第三方接入、基准站状态监控、平台运行监控、定制化方案管理、日志管理等14 项服务.

主中心服务层与分中心服务层根据所提供服务的不同在服务部署上具有一定差别. 实时数据接收和权限管理是服务层复用最多的基础服务. 权限管理服务是所有业务的基础，任何用户的业务请求都要经过权限管理服务的过滤，保证用户请求的服务与其自身的权限相匹配；
所有需要实时数据的业务都要调用实时接收数据服务作为数据源，服务层的服务参照应用层各个中心业务部署进行相应部署，其中主中心为了完成所有业务模块需要在服务层部署所有的服务，而分中心不具备提供RT-PPP 服务和提供实时产品服务，所以在各分中心部署除RT-PPP 处理、精密产品生成、数据产品播发之外的服务.

每一项服务可以由一个服务器集群支撑，避免单点故障造成多项业务不可用. 服务层的分布式服务框架是依托Dubbo+Zookeeper 的服务治理策略，实现服务配置的集中管理与动态更新，同时也与分布式数据库中间件建立连接，能够访问数据存储层的数据库、缓存和文件系统.

4) 数据存储层

根据高精度位置服务平台各类数据存储规模和存储需求的不同，同时选择和采用结构化存储以及非结构化存储，结构化存储使用关系型数据库MySQL，主要用于存储用户信息、项目信息以及基准站信息等需要持久化的重要业务数据，并通过MyCAT 中间件构建高可用、高并发的MySQL 集群；
平台持续接收的基准站数据以及高精度产品等非结构化数据数据量极大，且对存储的可靠性要求极高，本文中采用基于ParaStor 的分布式存储系统进行存储，其相比于传统的HDFS 具有更高的存储性能和更高的可靠性；
在存储层也引入远程字典服务(Redis)缓存用于缓存用户获取服务期间频繁访问的数据和需要频繁插入数据库的数据. 前者包括用户的权限等级等基本信息、用户操作记录信息以及平台的系统通用信息. 后者包括平台接收的多个基准站的实时数据，这些数据每时每刻都在接收，并且数据量很大，如果将这些数据直接存入数据库，频繁的插入会使得数据库服务器面临巨大的压力，也会使得平台的整体性能大大降低，所以在这里采用Redis 缓存将实时接收到的数据先缓存起来，等积累一定量的数据后再将这部分缓存起来的数据写入到数据库中，减少数据库的读写次数.

高精度位置服务平台最核心的功能就是定位功能，通过对全球卫星导航系统(GNSS)数据处理分析得到定位结果，从而向用户提供相关基础位置服务和定制化位置服务. 在对整体功能设计有了一定了解之后，接下来通过对平台用户获取服务流程以及RT-PPP 和RTK两种定位模式的详细分析来阐述平台的运行逻辑.

1) 分布式平台用户获取服务流程

高精度位置服务平台在分布式异地多中心的设计模式下，同一个域名所对应的是多个IP 地址，并且部署在异地多个数据中心，可以通过智能DNS 服务技术实现各中心间的访问流量负载均衡调度[9]. 当用户访问平台域名时，首先依据就近原则对设备节点的运行状态、节点当前的负载情况、服务能力以及分布等情况进行检测，如果节点运行状态良好是可用节点，则将用户请求定向到相应的数据中心，接下来用户的登录等操作则在该数据中心进行；
如果节点检测结果为不可用，用户访问流量将不发往异常的数据中心，而是根据各节点的分布、负载情况等重新定向到可用的数据中心，这样即使一个节点出现故障也可以保证平台持续无间断的对外提供服务.

用户访问定向到具体数据中心后，需要完成登录操作，系统将对用户所属的区域以及用户账号的状态进行判断，符合区域范围以及用户状态健康可用的允许登录正常访问，不符合区域范围以及账号状态异常的拒绝登录. 通过验证后用户可根据页面显示选择需要获取的服务，系统判断是否为分中心业务，是分中心业务的则提供相关服务，不是分中心业务的转发给主中心处理，从而完成主中心与分中心的调度控制，如图4 所示.

图4 平台用户获取服务流程图

2) 基于分布式的RT-PPP 处理流程

RT-PPP 的关键在于实时轨道、钟差、电离层、地球自转参数、码偏差、相位偏差改正数等，这些实时差分改正参数可以由第三方提供，也可以由陆态网进行数据处理实时生成. 高精度位置服务平台主中心是直接实时接收外部处理生成的实时差分改正数，并将实时产品播发给主中心用户以及分中心，也正是因为主中心处在获取实时差分改正数的最前端，所以在主中心完成RT-PPP 解算将会达到最小时延，定位结果达到最优. RT-PPP 的处理流程主要如图5 所示.

图5 RT-PPP 业务流程图

图中显示了整个RT-PPP 业务模块的处理流程，该项业务服务由主中心提供，整个流程由应用层进行程序控制，该业务的完成需要调用服务层的三项服务，分别是权限管理服务、实时数据流接收服务以及RT-PPP 处理模块. 权限管理服务用于完成用户权限等级的校验，只有拥有此项服务权限的用户才可以获取RT-PPP 服务业务；
实时数据流的接收服务为数据处理过程提供数据源；
RT-PPP 处理服务则是该业务模块的核心处理流程，进行RT-PPP 解算，得出实时定位结果.

3) 基于分布式的网络RTK 处理流程

网络RTK 主要采用双差算法，双差观测模型可同时消除了接收机端与卫星端的钟差、初始相位、相位硬件延迟偏差，且可消除电离层等大部分相关误差. 本文采用VRS 技术来实现动态实时定位，由于VRS 需要根据流动站概略坐标选择附近基准站进行组网，并根据网内各基准站所采集的实时观测数据在区域内进行整体建模解算，通过建立精确的误差模型(如电离层、对流层、卫星轨道等误差模型)来生成，所以在距离流动站更近的分中心实现了RTK 服务，这与基准站分布式数据接收与处理完美契合.

当用户请求网络RTK 服务时，系统根据用户位置定向到距离用户最近的分中心，同时该分中心接收和处理用户附近参考站实时观测数据，相当于整个RTK 流程都在本地完成，将时延做到了最小，定位结果达到了最优. 它的整体处理流程与RT-PPP 业务相似，都是由应用层进行程序控制并调用服务层的相关服务，通过多个服务的协调配合最终实现网络RTK业务. 具体处理流程如图6 所示.

图6 网络RTK 业务流程图

本文基于高精度位置服务平台现有业务的特点以及异地多中心的发展规划对平台功能模块以及分布式架构进行了研究与设计. 在功能模块设计中实现了从实时数据接收到数据处理、播发、存储、管理一整套的服务，同时平台也提供第三方接入服务，为平台资源充分利用以及行业用户定制化服务提供了可能. 在平台架构中采用分而治之的设计思想对整体架构进行了分层设计，各层之间相互独立，为平台开发提供了便利. 通过对目前市面上存在的多种技术进行比较和选型，最终综合考虑采用与平台业务模式匹配度最高、性能最优的主流技术架构完成了高性能的负载均衡方案、服务治理框架以及数据库架构，同时结合每项业务的特点详细分析了服务拆分和部署情况以及分布式平台用户的服务获取、基于分布式的RT-PPP 处理、基于分布式的网络RTK 处理等关键功能流程，解决了目前所面临的主、分中心独立工作、业务不连续的问题，使得主中心与分中心能够资源共享协同工作，实现“多活”，从整体上提高平台性能.

平台发展是一个长期的过程，目前只针对现有资源及用户需求进行了相应的功能设计，在分布式架构设计中也做了有利于功能模块扩展的设计，后期还需要不断的完善和开发，当然在系统架构上也需要不断地进行验证和优化. 随着用户需求和业务发展需求的不断改进，服务拆分仍然是分布式架构中的重中之重，需要充分考虑业务特点以及拆分粒度，具体情况具体分析，这也将是后续研究工作的一个重要方向.