基于微服务架构的统一应用开发平台

方志宁，谢 华，张金营，曹亚南

（1.国电电力发展股份有限公司，北京 100101；2.国能信控互联技术有限公司，北京 102209）

0 引言

企业因受制于传统IT技术的影响，多沿用传统单体式架构进行一系列平台构建等开发工作[1]，但是随着工业技术的不断发展和迭代，企业信息化建设愈发趋向一体化，传统IT架构无法应对当前业务数据几何倍增长，应用服务不断延伸迭代的情况[2]。单体式架构系统其拓展性低，开发工作重复严重，运维难度大，代码耦合程度高等弊端日益显著[3]，前中期系统平台的开发和后期运维工作难度急剧上升。

为改善现阶段平台系统开发工作和运维工作内容重复、难度过大等问题，本文一改传统使用单体式架构中心化开发建设系统的理念，将复杂应用细粒化划分服务[4]，提出基于微服务架构搭建的统一应用开发平台。在平台设计中，将一个复杂进程拆分成数个甚至数十个相互之间具有独立性的组件，相关功能组件封装成单一业务服务，在进行拓展时只操作对应功能的微服务，而非类似单体式架构需要将应用程序堆栈进行整体处理[5]。应用组件化，组件服务化，将软件产品开发中重复繁琐的步骤抽离出来，让开发更简单、更快速。

国内外企业越来越多采用新型微服务架构搭建系统框架[6]，国内外成功代表案例诸如Alibaba、京东、Walmart、Amazon等。众多国内外企业成功案例表明，微服务架构作为一种系统框架在解决如今复杂业务导致的诸多问题上具有极为强大的能力。

文献[7,8]介绍了系统架构的演变及微服务架构的优缺点，文献[9-11]结合实践案例进行分析。本文提出了基于微服务架构的统一应用开发平台，针对该平台的开发可有效提高应用开发效率，降低系统运维难度。

1 微服务架构

2012年3月类似最初版本的微服务架构概念在Agile India中被Fred George描述，在演讲中他描述了2005年～2009年间Fred George团队实践分析一百万行的传统程序代码，最终将其分解为两百余个类似于微服务组件的经历。尽管演讲中并未明确提出微服务架构这一名词概念，但是最初版本的微服务架构概念在Fred George的经历中已现雏形。

微服务架构总的来说是一种特殊的面向服务架构（SOA），是指将复杂应用进程细粒化划分成只具有单一功能的组件，根据组件的各自功能将其封装成离散的、可独立部署的微服务，进而实现服务间的解耦。开发时不同服务可选择不同的开发技术，服务边界明确，不同服务间可以通过直接使用REST/JSON等轻量级通信协议进行协调沟通，避免了使用企业服务总线（ESB）所带来的上限问题。在实际生产中，业务进程由一组服务相互配合而成，开发过程中将相关业务逻辑结合数据组合成独立业务部署单元。

微服务架构本质是由多个服务组合成的分布式系统，基于微服务架构开发框架目的是在不影响其它应用组件的情况下，更快地实现新功能的拓展和老功能的迭代，降低系统运维难度。

现对微服务架构主要特性总结为以下6方面：

1）技术多元：微服务架构下，团队开发服务时可以根据当前技术员技术偏重以及行业发展情况，选择合适的技术栈进行开发。

2）粒度可控：将复杂应用程序分解为应用服务或者可独立部署的组件时，根据划分业务服务的复杂程度可以人为地控制微服务框架的粒度。

3）拓展强大：将服务组合成应用后，将整个应用完整地复制到不同的节点可实现应用进程的横向拓展，每个应用都可以根据实际生产需求进行拓展。

4）去中心化：避免企业服务总线的瓶颈缺点，服务之间通过轻量化通信协议相互协调，且各个服务可独立部署。

5）快速开发：根据应用进程所需业务功能将各个微服务接口连接，可实现快速地开发应用进程。

6）自治应用：服务的边界确定，暴露固定接口，每个微服务可独立封装业务逻辑，以独立进程运行，所以具备可独立开发、测试和部署的能力。平台开发应用高内聚，低耦合，应用间具备一定的自治能力。

2 基于微服务架构的统一应用开发平台

统一应用开发平台构架于国电电力大数据（Hadoop）下的一个应用快速开发平台。此平台在设计过程中总结各方面的应用案例，结合研究人员多年开发经验，推翻了以往的传统架构。在对平台的设计中采用了微服务架构，同时将平台定位为低代码开发平台，极大地提升了开发效率。该应用开发平台全面支持应用监控与追踪、服务治理、配置管理、去中心化的服务组件、负载均衡可靠性保障等多种特性。

2.1 平台介绍

统一应用开发平台微服务架构如图1。平台开发设计定位于后台开发框架和企业级快速开发解决方案，在数字化高速发展的今天，供需两侧程序员数量及质量不对等，需大于供，因此平台的开发方式选用了低代码开发，易于开发设计应用进程。平台支持分布式部署，采用松耦合设计，微内核和插件架构，去中心化管理。平台整体设计与开发遵循了Spring Cloud的技术开发路线，从功能上涵盖了统一身份认证、电子表单、工作流引擎、组态工具等应用开发组件；平台集成了数字化应用商店和工程项目开发的全生命周期的管理。在平台的设计过程中也针对平台的安全方面做了对应设计，例如平台采取统一身份认证，设置密码策略、安全审计、日志收集等众多安全选项，极大地降低了微服务系统架构分布式部署这种模式所带来的安全风险。

图1 统一应用开发平台微服务架构Fig.1 Microservice architecture of unified application development platform

2.2 平台核心功能研究

统一应用开发平台核心功能体现在如下8个方面：

1）低代码开发

平台的低代码开发是基于对象模型驱动的，其中包括了对象建模、权限建模、流程建模、上层表单建模、报表建模、扩展规则建模6种建模能力，通过API接口驱动前后端进行整合，体现出SOA分层架构。低代码开发中在对核心的对象建模驱动完成后，继续向下层生成了数据库表和数据对象，同时向上打开了标准的API接口服务，从而推动上层的自定义和表单建模。在此过程中可以绑定底层对象开放的API接口，也可以集成拓展规则建模能力，在建模结束后提供拓展相应的报表建模能力。

2）流程引擎

流程引擎是低代码开发的核心，是将业务服务按照设定的固定路径进行流转，将服务应用步骤转换成计算机能理解的形式。在开发过程中，通过拖拽进行流程设计，流程服务化，独立部署。通过连接服务节点实现应用链式结构，每个连接节点作为当前链头节点，服务内包含下层连接节点索引，实现应用进程流程可视化。

3）统一认证

统一认证模式通过统一身份认证实现。平台统一身份认证采用层次式结构，将平台统一认证分为三层次的层级结构，分别为数据层、认证通道层、认证接口层。在平台中，统一身份认证的主要功能模块有两种，分别为用于进行统一认证的身份认证模块和应用内进行权限设定的权限管理模块，通过调用两个功能模块隔离异常登录行为，确保平台身份安全。建立自动化的账号同步体系，达到在平台中单点登录后可跨应用认证的账号同步体系，同时在不同业务进程内自行设定权限控制，以实现对用户的权限管理。

4）组态能力

平台中的组态能力是指与硬部件组装类似的，通过在系统中预设封装好的“软部件”，应用中通过拖动对应的2D图像进行对业务框架的一个搭建，搭建好框架后只需设置好软部件参数即可将搭建的程序投入使用。组态能力提供了平台无代码开发的功能，同时组态软件也提供了相应的编程手段，可实现无代码开发与常规代码开发的协调合作。同时平台对接了不同的数据源，在大屏以及监控方面可以实现广泛的应用。

5）定时任务管理

平台在采取基于数据库动态配置的方法对任务实行动态管理。平台对任务进行管理时，摒弃了传统方法中在代码程序明确固定表达式的方法，采用了基于数据库读取定时任务的设定执行时间的方法。在对任务进行修改时，无需对系统进行重启，降低了运维和追踪的难度。平台统一管理定时任务，提供了统一的开发标准，提供了可视化界面，系统在开发应用时的效率得到大幅度提升，相关工作步骤得到有效优化。

6）文档储存组件

平台提供了高性能、分布式的对象储存能力。平台将数据储存在一组分布式独立部署的服务器中，通过独立服务器分担系统数据储存负荷，因此系统结构具备强拓展性。平台通过查询服务器的位置信息定位所需的储存信息，根据不同场所部署相应功能的服务器，再通过软件将服务器连接成高性能逻辑池。平台所使用文件储存架构具备高度可靠性，支持多种储存服务，例如支持Hadoop组件HDFS。

7）工程项目管理

针对平台开发的项目进行项目生命周期管理，制定为国电电力业务软件开发的规范编制。其中包括：应用开发统一规范、应用开发UI设计规范、应用开发编码规范、应用开发数据库设计规范、应用开发集成规范、应用分类标识规范、应用功能与权限标识规范。对业务软件的开发制定出一整套全方位的标准，统一代码风格，提供开发约束，降低服务开发团队间的交流成本。

8）应用商店

平台开发团队通过Html、JavaScript、CSS等技术开发出应用商店体系。通过将平台开发的应用以及公共业务应用等进行收纳，通过统一标准进行管理，形成应用商店体系，方便用户下载使用各类业务应用。应用商店提供给用户统一入口，通过用户统一身份认证可快速接入入口，找到应用后无需再次登入，即用即取。

图2 平台总体服务架构设计Fig.2 Overall service architecture design of the platform

2.3 平台总体架构设计

统一应用开发平台开发设计遵循Spring Cloud的技术开发路线，平台核心功能作为公共组件，可封装组成微服务，组件服务化。

微服务的核心是将进程划分成多个独立服务，并要求服务之间具备松耦合等特性，要求整体架构更彻底地去中心化。Spring Cloud是分布式微服务架构的一站式解决方案[10]，Spring Cloud提供了一套十分通俗易懂、应用方便的编程模型，Spring Cloud在总体架构设计中基于Spring Boot的基础上可以轻松构建微服务。

平台基于Spring Boot提供微服务开发组件，客户端发送Restful风格的Web请求。请求通过Nginx服务端负载均衡器分配节点向网关发送API调用，Spring Cloud Gateway收到调用请求后对信息进行二次处理，完成后向Nacos注册中心查询微服务地址。注册中心返回微服务HTTP地址后，Spring Cloud Gateway对其进行服务调用，根据调用微服务所需数据，从数据总线中获取对应数据。

在去中心化的架构中，对于注册发现还是中心化的。平台通过将注册中心集群化处理，在微服务端设置微服务目录和微服务列表的缓存，避免注册中心宕机后整个微服务调用失败的发生。

平台使用了Spring Boot Admin、Sleuth Zipjkin、Hystrix、Sentinel实现对平台的监控保护：

1）Spring Boot Admin作为当前的主流开源项目，应用程序端的Admin Client通过基于HTTP实现的RESTful协议使用注册中心，或者通过Admin Server注册实现监控管理应用程序的功能。

2）Sleuth Zipjkin通过将分布式请求还原成调用链路，同时在链路上生成Trace ID和Span ID进行日志记录，以达到展现原分布式请求调用信息的目的，并且提供API供客户端查询追踪数据。同时提供UI组件，使客户端便捷实现对请求的搜索跟踪、分析分布式请求，调用链路日志明细等服务。

3）Hystrix（断路器）使用基于异常比率的熔断降级策略，通过线程池或者信号量隔离的隔离策略隔离访问远程系统、服务和第三方库。

4）Sentinel使用基于响应时间、异常比率和异常数的熔断降级策略，通过信号量隔离进行限流功能。

Nacos Config配置中心提供Serve端和Client端，Serve端提供配置文件储存，并通过HTTP向与开发段分离的配置中心提供基于微服务的API。Client端设置在各个微服务端，通过接口接收配置修改数据后，依据接收到的数据初始化对应微服务应用，并向数据库发送修改的配置属性记录。在使用Spring Cloud开发框架引用管控、治理方面内容时，传统的开发方式为在开发阶段就考虑实现相应接口并且组建相应的配置文件，但到服务治理开发阶段时，开发端和服务的管控治理端严重耦合，想要修改就需修改开发源码并对服务重新部署。微服务在开发端的重点为实现微服务必备的业务功能，同时暴露相应接口，对于微服务组件以及API服务接口的管控治理方面的能力应在去中心化的服务治理端实现，与开发端主要职能分离。平台采用运行态的配置模式，可以动态地调整配置参数，对管控治理端的修改也无需再对服务重新部署。

平台通过在微服务组件端下发一个代理，通过对流量的拦截，达到良好的相关管控和治理能力。例如微服务A调用微服务B时，应灵活可配置，通过配置调用过程中相关日志的审计与记录、配置具体熔断规则等方式，达到“访问安全，数据安全”的目标，后期不需要对微服务本身再做修改。

3 结语

本文提出的统一应用开发平台是基于微服务架构相关技术来设计和实现的，旨在解决单体式架构拓展性低，部分开发工作重复严重，运维难度大，代码耦合程度高等问题，可以有效地支撑业务开发团队快速地构建微服务；提出了统一的开发标准，增强了系统的安全与稳定，具有良好的拓展性。