智能终端运营管理系统之微服务架构改造实践

王卫国，潘 雨

(北京智芯微电子科技有限公司，北京 102202)

0 引言

目前电力系统中以智能电表、智能插座、充电桩等为代表的智能终端种类越来越多，应用也越来越广，相应的运营管理系统辅之以手机App即可实现定位、远程查询、控制、支付等功能，极大地提高了用户便利度和交互时的友好性。

不过随着业务场景的快速发展变化，采用传统单体应用架构实现的现有智能终端运营管理系统逐渐显现出资源浪费严重、部署效率低下、技术选型单一、扩展能力有限、需求响应速度慢、产品交付周期长等诸多问题。FOWLER M于2014年提出了“微服务”这一全新概念。微服务架构易于开发、维护和扩展，服务可独立部署，服务间松散耦合，开发技术栈选型灵活，系统资源可按需伸缩。随着该架构思想的逐步成熟与落地实践，前述问题逐渐得到有效改善和解决。微服务架构带来了上述诸多好处，与此同时也提出了不少挑战。具体来说，微服务架构须具备服务注册与发现、服务调用网关、客户端负载均衡、统一配置中心、服务治理与监控等基础设施。

实现将微服务架构在智能终端运营管理系统中切实落地，对于提升运营系统性能、可靠性及稳定性都具有十分重要的积极意义。本文详细描述了各个基础设施所使用的具体技术，开发人员可集中精力专注于具体业务而无需过多关注整体架构。同时本文还使用了Git、Jenkins以及Docker来实现分布式代码管理、代码持续集成以及服务封装与快速部署。随着系统架构和功能的逐步完善，仅需通过有针对性地增加相关的服务节点数量以及少量的代码修改和配置，即可轻松应对海量智能终端接入系统所带来的巨大挑战，而不再需要通过横向部署更多的单体应用来实现，节省了大量服务器资源。

本文所采用的微服务技术栈综合考虑团队成员技术构成、新技术学习曲线、项目周期等因素，并结合当前国内微服务实践经验与现状最终确定。

1 改造后智能终端运营管理系统构成

改造后智能终端运营管理系统由主站平台、手机App(iOS、Android)、智能终端三部分组成[1]。

(1)主站平台是整个系统的中枢部分，用于协调内部各个服务与手机App、智能终端之间的数据交互。主站利用心跳机制与接入系统中的每个终端保持长连接，处理响应来自手机App和终端的上、下行指令和数据,为相关人员提供历史数据查询、统计和分析研究，实时监测运行终端运行工况等。

(2)手机App是用户参与数据交互过程、监控终端运行状态、控制终端通断、定时开关、查询历史数据的唯一途径。

(3)智能终端内置WiFi通信模块，经简单设置与家庭内部路由器相连，用户可通过手机App与特定智能终端完成绑定，随后在联网条件下可对绑定的终端进行远程即时、定时控制及其他操作。

2 智能终端运营管理系统采用的微服务技术栈

通过一系列微服务基础设施以及集成封装部署工具集，同时利用Spring Boot简化应用开发，可快速搭建起简单易懂、易部署维护的分布式系统开发工具集，如图1所示。

图1 本文微服务技术栈总体示意图

2.1 Spring Boot轻量级Java微服务开发框架

本系统采用Spring Boot[2]开发微服务主体框架程序。Spring Boot是一个轻量级实现Java微服务的开发框架，其设计初衷旨在简化Spring应用的开发与配置。通过自动配置、起步依赖、命令行界面和Actuator这4大主题，可实现代码快速开发，经过简单配置，即可利用其内置Web服务器实现一键启动部署。

2.2 微服务基础设施

本文所采用的微服务基础设施主要包括以下组件：

(1)Apollo(阿波罗)是由携程网发布的一款开源配置管理中心组件，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。该组件可通过Git、SVN和本地文件存储，实现公共信息配置。其功能和性能明显优于Spring Cloud Config，且该组件已通过生产环境的严苛检验。

(2)Zookeeper是服务注册与发现组件，负责服务的注册、发现以及状态同步，是顺利完成微服务框架中各个服务间调用的信息中枢。该组件是目前用于解决分布式一致性的普遍性解决方案。

(3)Kong是由Mashape公司开源的一款API网关与API服务管理组件。该组件作为访问系统服务的唯一入口，对外屏蔽了其内部所有复杂性，同时明显简化客户端实现与微服务应用程序之间的沟通方式。该组件底层运行在NGINX之上，同时使用Lua扩展了NGINX，因此可轻松处理超高并发，支持水平扩展，能够对外提供身份验证、安全、流量控制、日志、协议转换、访问路由、负载均衡等功能，同时还可根据项目实际需要自行开发插件进行功能扩展。

(4) Netflix Hystrix是服务治理与监控组件。Hystrix是一个实现了超时机制和断路器模式的工具类库[3]。服务断路器通过配置熔断和降级规则，可实现服务调用过程中故障的快速处理，保证服务调用能够快速响应，避免雪崩效应的产生。同时利用可视化监控组件Dashboard及Turbine，集中展现微服务集群中多个服务的实时监控数据和结果。

图2 平台技术架构示意图

2.3 集成封装部署工具集

在微服务架构中，每个服务均有可能由不同的编程语言来实现。服务的运行环境往往也是千差万别。尤其在服务数量较多的场景下，运行服务前，安装各个服务的运行环境通常十分繁琐、费时。Docker容器技术可以实现将服务及其运行环境加以封装，并以封装后的产物作为交付物。

开发人员不定时将代码提交到Git远程仓库，持续集成工具Jenkins按预先设定周期定期从Git仓库拉取指定项目代码并自动完成构建，生成基于Docker容器的测试环境。测试人员在该测试环境中开展测试工作。上述过程经过多次反复迭代，测试完毕后得到稳定的项目源码。最后再次经由Jenkins、Docker得到项目的Docker容器。利用Docker相关命令，可快速完成服务的部署运行[4]。这里每个服务对应一个单独的项目。

3 微服务技术栈在智能终端运营管理系统中的应用

利用微服务技术栈对智能终端运营管理系统进行改造，旨在通过优化系统整体架构实现系统的高性能、高可用。通过将单体应用拆分为多个可独立运行的微服务模块，最大限度降低系统模块间的耦合，实现代码快速开发和服务节点快速部署，大大降低运维的时间成本，显著提升系统的整体扩展能力。

3.1 系统架构设计

本平台架构目前只实现了部分业务的微服务化。展现组件部分由于时间和技术方面的限制，目前尚未实现。同时根据当前的业务需求，对历史数据服务组件进行微服务改造的意义不大，因此只是将其作为一个单独的工程。经微服务化后的模块根据业务分为接口服务组和实时数据服务组。具体技术架构如图2所示。

(1)实时数据服务组：由数据采集服务、数据包解析服务、指令下发服务、数据存储服务以及定时指令服务组成，采用Netty开源框架，利用NIO、多线程技术，负责与每一个智能终端进行通信，包括数据采集、指令下发、协议解析、数据校验、数据加密/解密、协议适配、分布式部署、对外提供标准REST服务接口等功能。

(2)接口服务组：由App接口服务、Web接口服务、第三方接口服务组成，所有外部服务均通过REST方式调用相应接口服务，接口服务均返回JSON格式数据完成交互。接口服务组与实时数据服务组通过基于AMQP协议的RabbitMQ消息队列实现异步调用、服务间解耦。

(3)展现组件：该组件支持手机端App和PC端浏览器两种访问方式。手机端App分为iOS与Android两种操作系统版本，智能终端用户利用App与智能终端进行互动操作；PC端浏览器作为系统平台运营方的管理工具，主要用于查看业务统计信息、配置平台运行参数、回顾历史数据、辅助决策等。

(4)历史数据服务组件：为展现组件提供数据支持。

3.2 系统架构工作原理

按照上述系统架构设计，将接口以及对实时性要求较高的数据服务拆分成多个职责单一的微服务：接口服务组、实时数据服务组。这两个微服务组与微服务基础设施再结合展现组件、历史数据服务组件，可基本实现整个运营管理系统的高可用。

接口服务组除了提供Web应用和App应用，还提供第三方接口。本系统中的服务可以为第三方系统提供调用接口，实现多系统功能、业务上的集成。同时经过协议转换后的其他类型智能终端也可以接入到本平台中。

在实时数据服务组中，需要指出的是：数据存储服务通过MySQL数据库集群持久化相关业务数据，通过Redis NoSQL数据库集群在内存中记录上行报文的实时状态。数据采集服务与各个智能终端之间采用基于TCP长连接的实时通信方式，数据包解析服务采用多节点部署方式可对高并发、多协议适配提供高效的支撑。

接口服务组以及实时数据服务组中所有服务均经过一定的负载均衡策略后发生调用，这样可以确保未来海量智能终端以及系统中各实时服务的正常运行与高可用。

综上综述，每个微服务启动时从统一的“配置管理中心”组件获取与自身相关的配置信息，启动后将自身的对外服务信息注册到“服务注册与发现”组件。所有的客户端请求都会首先进入“API网关与API管理中心”组件，该组件首先根据当前请求中的服务名称从“服务注册与发现”组件中获取对应的服务配置，随后根据服务配置直接调用相应的服务。

4 结束语

本文探讨了微服务架构在面向互联网、在海量智能终端运营管理系统中的实际应用，详细描述了所采用的技术架构、设计思路及具体实现。利用微服务架构改造智能终端运营管理系统可为智能终端的大规模应用提供强有力保障，促进用户有序充电，更加高效地普及用户侧电力需求响应。后续可将展现组件、历史数据服务组件微服务化，并在后者中引入Hadoop大数据离线分析工具[5]进一步对海量数据进行深度分析用以辅助决策。