0 引言

微服务的核心思想是，将应用功能尽可能细地划分成独立的服务，每个服务专注于单一具体的业务功能实现，服务之间采用轻量级的通信机制（通常是基于HTTP的Restful API）互相协调、互相配合，最终为用户提供符合不同需求的功能服务（龙新征等，2017）。微服务架构是一种架构风格，目的是将大型的、复杂的、长期运行的系统拆分为一组相互配合的服务。系统中每个微服务均可被独立部署，各个微服务之间松耦合，每个微服务仅关注于完成一件任务并较好地完成该任务。与传统的面向服务的架构（SOA）相比，微服务架构降低了系统的耦合性，提高了系统容错性、伸缩性及可扩展性，具有易于迭代开发、业务扩展与持续交付的能力。

本文基于中国地震台网中心地震台站监控运维平台现状，对平台架构进行调整设计，在实现平台架构的服务拆分粒度细化的同时，与具体业务相结合，达到各管理服务的内部高内聚、之间低耦合的效果。按照地震站网监控对象，系统包括测震、强震、GNSS、重力、形变、流体、地电和地磁等不同手段，从服务类型和服务对象进行划分设计，进而加工处理、分别划分成微服务。划分后，各服务之间彼此独立，可根据业务需求进行服务调用，从而实现地震台站监控运维平台由综合运维单体架构向微服务架构的转变。新的架构，系统升级灵活性更强，服务功能更加丰富，系统维护成本更低。

1 现状及存在的问题

随着互联网技术的高速发展及企业信息化水平的显著提升，以往地震台站监控运维平台应用的SOA架构面临系统扩展困难、成本比较高的问题，难以满足互联网环境下应用的高并发请求以及海量数据交互的要求。传统架构下的应用模块依赖关系复杂，功能的完善和扩展困难，同时增加了测试和部署的工作难度。任何一个模块中的一个bug（比如内存泄露等）均有可能摧垮整个进程，构建部署和启动时间较长，配置较复杂，在开发环境中的效果与运行环境中的效果难以保持一致，当业务流出现错误和异常时，无法快速定位，需要花费大量时间来查找和定位问题，最终导致运维工作处于被动状态，不利于快速上线、频繁部署的应用场景，阻碍了持续交付。

在云计算、大数据、物联网等新技术日趋普及和成熟的情况下，微服务架构逐渐进入人们的视线。微服务架构的本质是把整体业务拆分成诸多有特定明确功能的服务，通过诸多分散的小服务之间的配合，去解决更大、更复杂的问题。其特点决定了每个服务是分布式部署、独立运行的无状态服务（崔蔚等，2016）。基于微服务架构的应用监控系统可将调用链路及调用链路上的每个节点作为监控对象，对二者性能进行监控和跟踪，并对出现的异常进行报警，方便运维人员对系统的日常运维和优化。微服务技术架构见图 1。

地震站网全流程一体化监控平台微服务架构设计是，将耦合度高的应用划分成一组细粒度的、业务逻辑单一的以及能够高度自治的服务，服务之间互相配合、共同协作，向用户提供最终业务功能。由分布式MySQL数据库集群、HBase集群、HDFS分布式存储文件系统、分布式对象存储系统OSS结合Elastic Search的分布式索引系统提供基础数据支撑，将面向不同服务应用的地震站网监控产品微服务功能封装到可虚拟化部署的Docker容器中，通过Spring Cloud实现服务发现与注册、配置管理、服务调用、服务网关、负载均衡、熔断、数据监控等功能，构建生产级的灵活扩展微服务应用，方便进行地震站网监控服务的持续开发和集成（谭一鸣，2017）。从而以松散的服务方式，实现平台独立化部署各个服务；另一方面，可以基于Docker容器技术，实现平台的初始化部署，并在此过程中完成服务的冗余备份，以保障地震站网全流程一体化监控平台整体的高可用性。

2 系统架构设计

为满足平台资源按需使用、可扩展性要求，地震站网全流程一体化监控平台基于Spring Cloud的微服务架构，结合Docker容器技术，按服务数据类型与服务对象开发集成面向不同应用领域的站网监控管理功能，实现服务业务的可伸缩、可灵活扩展（王方旭，2018），以满足为不同服务对象提供可伸缩、可扩展、灵活定制的个性化站网数据服务的需求。

以层次化、组件化的方式进行平台总体架构设计，集成元数据、中间件（包括Web中间件、消息中间件等）等多种技术，遵循统一的技术标准进行服务平台开发。通过Hadoop分布式处理框架，利用分布式MySQL数据库集群、HBASE（Hadoop Database）分布式存储系统集群以及HDFS分布式存储文件系统，结合分布式对象存储系统OSS，存储管理各种结构化与非结构化数据与产品，实现分布式的高容错数据存储（张羽，2016）。同时以MapReduce并行处理技术以及Spark内存计算技术，实现多种并发数据的分布式处理。

基于Lucene作为内部引擎的Elastic Search分布式全文检索系统，实现大规模地震站网监控数据的快速检索，采用Impala提供的基于HDFS和OSS的分布式快速查询引擎，为整个系统提供基于分布式存储的快速数据访问服务。通过REDIS数据缓存技术，将高频访问的实时服务数据以一定数据结构保存在REDIS内存数据库中，提高实时更新数据的查询、页面响应、显示及应用效率，满足实时数据服务的时效性要求。结合RabbitMQ高性能消息队列，对多任务并发调度信息进行有序管理，实现高可用、多并发任务的高效调度管理。平台整体设计见图 2。

平台采用基于微服务架构开发，各个子模块统一基于JavaEE开发，采用IT行业的主流开发框架Spring Boot，前端采用REACT框架，实现前后端分离，并通过轻量级的REST接口与服务网关交互，降低程序耦合性。

服务内部使用Zuul服务网关做负载均均衡和登录鉴权；Eureka负责服务的注册与发现，避免服务之间的直接调用，方便服务后续的水平扩展、故障转移，将各服务连接起来并保持服务高可用；Hystrix负责服务熔断和降级，连续多次失败进行熔断保护，并按一定间隔时间检查调用失败的服务，若恢复将继续提供服务；Spring Cloud Config提供统一的配置中心服务，实现分布式系统配置文件的统一管理。

结构化数据采用MySQL数据库进行存储。非结构化数据基于内存或分布式缓存Redis、MongoDB等，业务系统信息通过kafka、rabbitMQ等消息中间件传输。

作为一种松散耦合、服务高度自治的架构模式，微服务架构将耦合度高的应用划分成一组细粒度的、业务逻辑单一的服务，服务独立部署并在各自进程中独立运行，服务之间互相配合与共同协作，因此微服务架构本质上是分布式系统。对于服务节点之间的通信，无论是同步还是异步通信方式，本质上是一种服务依赖关系的体现（方志明，2018）。对于地震站网全流程一体化监控平台的微服务，可筛选相互存在依赖关系的服务，并以此关系构建一个有向图Dependency，因服务之间的依赖不存在环的情况，所以是一个有向无环图。该有向图以微服务作为节点，节点的入度表示服务的被依赖关系，即节点的入度越大，该微服务被越多其他微服务依赖。

3 系统功能实现

地震站网全流程一体化监控平台应用微服务技术架构，横向拆分运维系统功能和业务，实现注册中心、告警管理、测试管理、性能监测、事件通知和值勤管理等微服务，向通信指挥和网络运维人员提供稳定、可靠的监控服务集群。地震站网全流程一体化监控平台的微服务组成见图 3。

地震站网全流程一体化监控平台按照功能和业务维度划分为多个微服务模块，每个微服务单独运行，单独部署，各个微服务之间通过API调用实现互联互通。按照层次化设计思想，该平台分为接入层、业务层和应用层进行功能设计。系统组成界面见图 4。

系统接入层实现被管系统的接入和数据采集能力（图 5）。实现与其他系统和设备的连接，并通过接口获取状态上报数据和采集数据，包括对观测设备、通用设备、IP网设备以及其他业务系统状态数据的接入和数据采集。系统为每一种被管对象增加一个单独的适配器服务，保证任何一个适配器服务的正常或异常不影响其他适配器服务模块。

业务层由一组实现不同业务的微服务组成，通过协同处理业务将接入层获取的数据进行处理，综合分析和挖掘，存储并按需进行数据融合处理，包括对资源、设备、运维、流量和测试等相关数据的处理，实现告警监测、通信资源管理、故障分析及流程管理等功能（图 6）。

应用层主要面向用户提供操作入口和全景监视视图。在系统开发阶段，一是基于开源软件，快速构建了服务注册中心服务网关、服务负载均衡、服务容错和分布式缓存等中间件，自主研发了服务监控平台，为系统开发提供了运行基础。抽取分布式调度服务作为基础服务，采用任务“统一调度管理、分布式执行”模式，提供各应用的统一管理和应用件协作服务，并可为其他项目建设重用。基于Maven开源工具，定制了开发环境，包括开发工具、开发模板、构建仓库等，实现了开箱即用、免系统环境配置、一键启动及快速构建等特点（赵乐乐等，2016）。在开发过程中，通过微服务架构设计，提高了系统的灵活性和可扩展性，在业务需求渐清晰的情况下，实现功能快速迭代，应用敏捷开发。

4 平台部署与测试

基于微服务架构的地震站网全流程一体化监控平台由于松散耦合的构建模式，平台中包含数量众多、业务逻辑各异的微服务。面对该情景，采用传统手动部署或脚本部署是相对低效的方式。为了维护地震站网全流程一体化监控平台的高可用性，通过对容器实行冗余备份，构建容器集群。

在进行微服务架构设计时，将系统划分为应用层、业务服务层、基础服务层、微服务中间件层和监视层。其中，应用层和业务层是业务价值体现的关键。应用层“以用户为中心”，专注于用户体验与业务功能；服务层通过将系统专业化分工，采用服务化方式，提供“去中心化”服务调用，并通过服务编排组合，可快速满足多应用多前端的功能实现（辛园园等，2018）。微服务平台主要包含基础服务层、微服务中间件层和监控层等功能。

（1）基础服务层。该层是服务重用和系统快速搭建的基础。微服务划分本质上是对业务功能进行解耦并独立部署而具有共性业务特征的功能进一步内聚和抽取，形成基础服务中心，在系统内或系统间的多个微服务中共享使用。基础服务中心包括认证中心、调度中心、日志中心等公共服务应用。

（2）微服务中间件层。微服务中间件层主要实现服务的统一管理，为服务间的互相协作运行提供技术保障，是架构实现的技术支撑。服务注册中心通过集中地注册管理机制，统一管理服务名称与服务调用地址之间的映射关系，实现服务的自动注册和发现，帮助服务调用者获取服务提供者的地址信息。服务网关实现请求转发、动态路由等功能，可以降低服务演进过程中地址变动和增长带来的更新成本；也可以实现协议转发，能提高基础服务中心的协议扩展性。服务负载均衡通过水平伸缩实现服务调用请求的负载均衡，有效分散单节点的计算负载，实现服务的弹性扩展。服务容错构建流量控制、故障隔离、断路器等容错与修复机制，避免某个服务不可用时，导致故障蔓延，并最终造成整个系统瘫痪的风险（李春阳等，2017）。分布式缓存利用键值数据库基于多台PC服务器，为分布式环境下应用对象缓存、状态缓存等场景提供统一的分布式缓存解决方案。

（3）监控层。监控层是系统稳定运行的保障，随着系统服务数量逐步增多，服务之间的调用关系越来越复杂，这也对微服务架构下如何保障系统可靠运行提出了新挑战。通过对应用服务、资源服务调用链路等进行监控，能够实现微服务架构下请求可追溯、问题可预警、伸缩有依据（张晶等，2017）。其主要功能包括站网应用概览、数据监测详情、环境参数、应用软件服务状况、数据库监控、服务调用链分析等，同时也为监控运维一体化提供了重要支撑工具（图 6）。

系统调整后，项目组对1 036个用例进行了测试，通过1 028个，未通过8个，修复后最终通过测试，能够正常运行。模块中的功能均已正确实现，性能、压力测试指标均达到要求。

5 结束语

本文结合实际开发项目，针对地震站网全流程一体化监控平台中存在的诸多难题和相应的解决策略进行分析。基于Spring Cloud的微服务架构提供灵活可扩展的数据服务，将面向不同服务应用的地震台站监控管理微服务功能封装到可虚拟化快速部署的Docker容器中，构建高伸缩性的数据服务，方便地进行地震台站监控管理服务的持续开发和集成，满足不断拓展的多种多样的地震台站管理服务需求。通过实验证明了微服务架构的服务系统可以提高用户体验，降低开发成本，实现高可用性，具有可持续发展的潜力。随着互联网思维和云平台部署越来越趋势化，微服务架构在地震台站监控管理应用系统的建设中将体现出越来越大的价值。