微服务在95598全渠道统一接入中的应用

王明珠 张晓慧 宋鹏飞 张伟 王翠

摘 要：基于Java EE规范的单体架构已经很难满足渠道不断拓展、线上业务量持续增加的电子渠道统一接入服務的需求，因此对原服务平台进行技术改造，提出了基于微服务设计思想实现95598全渠道统一接入平台。比较了单体架构与微服务架构的设计思想，并提出了微服务架构的优势;对95598全渠道统一接入平台系统架构中涉及到的关键步骤进行了描述;结合基于Spring Boot开发的Spring Cloud微服务框架的解决方案详细阐述了在开发过程中解决的进程间通信、服务治理等关键技术点。

关键词：微服务架构;95598全渠道统一接入平台;Spring Boot;Spring Cloud

Abstract：Monolithic architecture based on Java EE is hard to meet the requirement of the electronic channel unified access service whose channels continue expanding and the quantity of online business continues increasing. Therefore， this paper intends to reform 95598 full channel unified access platform based on microservices architecture. By comparing the design idea of monolithic architecture and microservices architecture， it is analyzed the advantages of the microservices architecture. Furthermore， committed steps of constructing 95598 full channel unified access platform are mentioned. Ultimately， the paper puts forward key technical points such as IPC and service governance by combining Spring Cloud based on Spring Boot.

Key words：microservices architecture;95598 full channel unified access platform;Spring Boot;Spring Cloud

0 引言

近年来，随着社会主义市场经济的发展和电力体制改革的逐渐推进，用电客户的消费习惯和消费需求也在不断变化，为适应互联网时代移动式、碎片化、智能型、互动化的客户消费需求，落实公司“互联网+”电力营销服务理念，构建线上业务渗透率高、服务信息充分融合与共享的电子渠道一体化运营体系势在必行[1]。

本文提出一种基于微架构95598全渠道统一接入服务，将95598智能互动网站、95598手机wap、移动App等多种电子渠道进行一体化整合，积极拓展渠道线上服务业务内容，健全优化渠道业务受理功能，向客户提供信息查询、业务办理、充值缴费等用电服务，并且实现了电子渠道间的互通互联，有效减少客户临柜次数。然而，如此庞大、复杂的应用程序为敏捷开发和持续交付带来了挑战。传统的单体架构有很大的局限性，随着电子渠道的不断拓展和线上业务量的持续增加，单体架构会变得越来越臃肿，这不可避免地会引起逻辑复杂、版本迭代效率低下、可伸缩性差等问题。而基于微服务的方式在实施敏捷开发和企业应用持续交付方面有着明显的优势。

1 微服务架构

“微服务架构”是一种独立部署的软件应用设计方式，最早由Martin Fowler和James Lewis在自己的博客中提出：“微服务是将一个独立的应用程序拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，并通过轻量级的通信协议保持通信。这些服务要基于业务场景，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制”[2]。与单体架构相比，微服务可以满足快速高效的软件交付方式。

传统的95598全渠道系统采用的单体架构，如图1所示。

由数据层、业务应用层、页面展示层三层架构组成。这种方式的弊端是应用程序是紧耦合的，所有功能都在一个进程中，基于整个系统扩展。微服务的设计思想，如图2所示。

各个微服务之间是松耦合的，功能在不同的进程中，单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序，各个服务按需扩展。

本文将基于单体架构的系统构建成图2中所示的基于微服务的方式，这种设计思想的优势在于[3]：

1） 迭代速度快

在业务需求快速发展的模式下，研发过程中开发人员不需要费时协调其他应用对其应用的影响，为持续集成和快速交付提供基础性技术支撑。

2） 容错性高

故障的影响可以控制在单个应用中，不会对其他服务造成影响，而且微服务中有多种故障保护机制可以保证系统运行的稳定性。

3） 扩展性好

整体微服务架构内部有成熟的软路由、负载均衡、容错机制，容易水平扩展。同时每个微服务独立，可根据压力情况，灵活选择扩展，可节省硬件成本。

2 基于微服务的95598全渠道统一接入服务

基于微服务的95598全渠道统一接入服务系统架构，如图3所示。

该架构将业务应用的前端和后端进行分离，按拆分原则拆分成多个独立运行的微应用和微服务，由接入层门户提供统一前端集成。95598全渠道统一接入服务在逻辑上分为接入层、应用层、服务层和持久层，主要包括以下几个关键步骤：

1） 95598全渠道统一接入

将95598智能互动网站、95598手机wap、移动app等多种电子渠道一体化整合到95598全渠道统一接入服务，由门户提供统一集成，为用电客户提供用电、停电等信息查询，新装、增容、暂停、减容等业务办理，充值缴费等用电服务。

2） 服务访问

95598全渠道统一接入服务注册至网上国网共享服务中心，通过网上国网共享服务中心实现内外网数据交互，与各省电力公司业务系统交互。网上国网共享服务中心由微服务、注册中心、配置中心、服务网关和服务监控组成，通过分布式总线将业务请求准确分发至具体微服务。微服务提供业务逻辑处理;注册中心提供微服务信息储存，实现微服务间解耦;配置中心提供分布式环境下统一动态配置管理;服务网关为微服务提供统一访问入口;服务监控提供微服务状态和调用链路监控。

3） 微应用和微服务拆分

微服务微应用如何拆分是微服务架构业务应用建设过程中的难点和重点，需要对业务、技术、数据等特征进行全面综合分析。在以下拆分原则基础之上，结合实际应用场景，进行一步完善修正，形成相关业务应用的最终拆分原则。

a） 微应用拆分原则

完整单一的业务逻辑单元可以拆分为独立微应用。该单元建议为二级或二级以下应用功能。

建议业务应用包含的微应用数量是二级应用功能的1/3倍到3倍。

b） 微服务拆分原则

业务完整、职责单一的应用功能单元应当拆分为独立微服务。该单元建议为三级或三级以下应用功能。

建议业务应用包含的微服务数量是三级应用功能的1/3倍到5倍。

具有重用性特点的公共功能应当拆分为独立微服务。

访问量较大、资源消耗较大、耗时较长的功能，应拆分为独立微服务。

一组强关联的数据对象的所有增删改操作，不要拆分到多个微服务中。

耦合性强、事务强一致性的业务，不要拆分到多个微服务内，尽可能避免分布式事务。

4） 数据库维护

95598全渠道统一接入服务的数据由全业务统一数据中心进行维护，主数据库采用Oracle，缓存数据库使用的是Redis，通过调用一個或多个微服务实现业务逻辑和数据库访问，而不是应用层直接访问，因此模块间数据库表无紧密耦合关系。

3 关键技术点

95598全渠道统一接入服务的技术改造是采用Spring Cloud微服务框架实现的。Spring Cloud是一个基于Spting Boot的微服务架构实施综合性解决方案[4]。Spring Cloud将基础组件Zuul、Ribbon、Hystrix、Eureka都集成在Netflix中。

Netflix的几个重要工具在微服务架构中的总体应用情况，如图4所示。

结合Spring Cloud的解决方案，下面的内容介绍了基于微服务架构的95598全渠道统一接入系统中的关键技术点，包括进程间通信、服务治理机制、负载均衡机制以及容错保护机制。

3.1 进程间通信

在单体应用程序中，组件之间是通过语言级别的方法或者函数相互调用的方式进行通信，但是基于微服务架构的应用程序是一个运行在多台机器上的分布式系统，因此，服务必须使用进程间通信（IPC）机制进行交互[6]。在设计服务间通信时主要需要考虑两个问题：使用什么通信协议构建服务体系和如何为服务定义API调用接口。下面对这两方面的问题进行详细介绍。

1） IPC通信机制

基于微服务的应用支持更简单、轻量级的协议，RESTful和RPC是微服务架构中最常用的通信机制，这两种机制在应用上各有优势。

以Apache Thrift为代表的RPC采用二进制协议，支持多种语言，性能高，节省宽带，但是这种协议的最大缺点是无法穿透防火墙。以Spring Cloud为代表所支持的RESTful协议，优势在于使用方便，语言无关，基本支持各种开发语言实现的系统，另一个优点在于它能够穿透防火墙。但是与RPC相比其性能和宽带占用上有劣势。各大互联网公司在微服务实践中多采用RPC方式[7]，本文介绍的系统也采用支持RESTful协议的Spring Cloud Netflix中的 Zuul网关组件来实现此种通信机制。

2） 为服务定义API调用接口

API网关是系统的单点入口，是一个更为智能的应用服务器。各个服务之间的通信首先要通过一个称为API 网关（API Gateway）的中介，然后API 通过路由将请求分发到到适当的服务，如图5所示。

API是服务和客户端之间的契约，因此，无论选择何种IPC机制，使用接口定义语言严格定义服务API都是很有必要的，而定义API调用接口的方式取决于应用程序使用何种IPC机制，如采用HTTP协议，则API由URL、请求和响应格式组成。

3.2 服务治理机制

服务治理可以说是微服务架构中最核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现[8]。在95598全渠道统一接入系统中，微服务的服务注册与服务发现机制的实现过程，如图6所示。

服务实例通过POST请求将自己的网络位置（IP地址与端口）注册于服务注册中心（可用服务实例的数据库），客户端从服务注册中心查询可用的网络地址并利用负载均衡算法选择一个合适的服务实例进行调用。

本文采用Spring Cloud核心组件Netflix中的服务治理组件Eureka来实现服务注册与服务发现机制。Eureka既包含服务端组件也包含客户端组件，Eureka服务端也称为服务注册中心，它提供了一个用于注册和查询服务实例的REST API。Eureka客户端主要处理服务的注册与发现，服务实例负责在服务注册中心进行自己注册和注销，在必要的情况下，服务实例会发送心跳请求来防止其注册信息过期。

3.3 负载均衡机制

为了扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性，基于微服务的95598全渠道统一接入服务体系中采用了负载均衡机制[9]。

负载均衡分为服务端负载均衡和客户端负载均衡，本文中服务端负载均衡采用了高性能的HTTP和反向代理服务器Nginx，通过Nginx进行负载均衡，先发送请求，然后通过负载均衡算法在多个服务器之间选择一个进行访问。客户端负载均衡采用基于Netflix Ribbon实现的客户端负载均衡工具。在客户端负载均衡中，每一个客户端节点都维护着要访问来自于服务注册中心的服务端清单。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。Ribbon不像服务注册中心、配置中心、API网关那样需要独立部署，但它几乎存在于每一个微服务和基础设施中，因为服务间的调用，API网关的请求转发等内容实际上都是通过Ribbon实现的。

3.4 容错保护机制

在微服务架构中，应用程序由多个服务单元构成，这样的架构相较传统架构更加不稳定。因为若一个服务单元出现故障，很容易因依赖关系而引发故障的蔓延，最终甚至导致整个系统瘫痪。为避免出现这样的技术故障，本文采用基于Spring Cloud Hystrix实现的容错保护技术。Hystrix实现了断路器、依赖隔离等一系列的服务保护机制，具备服务降级、服务熔断、线程和信号隔离、请求缓存等强大功能。

1） 断路器保护机制

断路器的工作逻辑，如图7所示。

正常情况下，断路器关闭，可正常请求依赖的服务;

当一段时间内，请求失败率达到一定阀值，断路器就会打开，此时，不会再去请求依赖的服务;

断路器打开一段时间后，会自动进入“半开”状态。此时，断路器可允许一个请求访问依赖的服务。如果该请求能够调用成功则关闭断路器，否则继续保持打开状態。

2） 依赖隔离

在95598全渠道统一接入服务体系中，需要用到很多依赖，在访问并发量很高的情况下，这些依赖的稳定性可能直接影响着系统的健壮性。当依赖阻塞大时，大多数服务器的线程池就会出现阻塞，影响整个线上服务的稳定性，高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。为了防范这个风险，Hystrix采用隔离线程池的机制来对依赖进行隔离[10]。

Hystrix实会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的依赖服务。

4 总结

本文在基于单体架构实现渠道不断拓展、线上业务量持续增加的电子渠道统一接入服务平台时具有开发效率低、迭代速度慢、难于扩展、容错性差等缺点的背景下，采用微服务的设计思想对95598全渠道统一接入平台进行了技术改造。

改造后的95598全渠道服务后台具备支持微服务拆分设计后的高内聚、低耦合服务的管理及调度，并可依托云环境进行服务发现、服务弹性伸缩、服务异步协同，增强网站服务后台的可靠性及服务部署的灵活性;平台使用了科学有效的容错保护机制，有效提升了容忍技术故障的能力以及系统的健壮性。改造后的95598全渠道统一接入平台能够满足公司持续开展95598全渠道功能优化工作以及互联网时代移动式、碎片化、智能型、互动化的客户消费需求，落实公司“互联网+”营销服务模式的决策部署，提升了公司服务效能和服务水平。

参考文献

[1] 韩硕辰，白雪，董世安.“互联网+电力营销”电子渠道一体化运营体系构建[J].通信技术，2018，35 （1）：101-103.

[2] Fowler M，Lewis J. Microservices-a definition of this new architectural term[EB/OL]. （2014-03-25）， [2017-06-18]. http：∥martinfowler.com/articles/ microservices. html.

[3] 李红健.微服务架构和容器技术应用分析[J].无线互联科技，2018（8）：134-135.

[4] 马雄.基于微服务架构的系统设计与开发[D].南京：南京邮电大学，2017.

[5] Sourabh Sharma. Java微服务[M].卢涛， 译.北京：电子工业出版社，2017.

[6] Richardson C，Smith F，著.微服务：从设计到部署[M].Oopsguy.译，2017.

[7] 作者？.微服务在电力交易系统中的应用研究[J] .电网技术，2018，42（2） ：441-446.

[8] T，Johannes.Microservies，IEEE Trans， on Software. 2015，32（1）：1-116.

[9] 负载均衡：百度百科，https：//www.zhihu.com/question/61783920.

[10] 翟永超. Spring Cloud微服务实战[M].北京：电子工业出版社，2017.

（收稿日期：2019.08.25）