国网盘锦供电公司 辽宁盘锦 124010
摘要：随着电力企业内部精细化管理的推进，现场作业应用越来越多，且业务多有重叠现象，不同业务应用之间流程独立、数据独立、人员权限独立，但实际工作中业务执行人员一致，管理单位一致，二者之间的矛盾不断突出，难以满足末端业务融合和“企业数字化转型”带来的新要求。本文在此基础上提出一种新的基于微服务架构的电力客户服务应用构建方法，为将来业务创新发展提供有力支撑。
关键词：微服务架构；电力客户服务；应用构建
1微服务概念及其演变
微服务架构不是凭空产生，而是一步步发展而来。所有软件系统的发展都经历了从简单到复杂、从集中到分散的过程。在这个过程中，开发人员在系统构建初期，倾向于构建整体内聚、全功能集中的系统，因为这样便于快速的实现系统功能，满足当前业务需求，从而有利于企业快速盈利。但随着系统的不断演化，业务快速发展，为了满足业务功能，新的需求不断增加，系统逐渐变得庞大起来。与此同时，系统复杂度也不断上升，软件架构越发臃肿，使得系统重构难度大大增加，到了后期，集中化的系统甚至变得不能承受任何改变，此时也意味着软件系统的寿命终止。旧的系统被推到，开发人员开始构建新的系统，又因为集中化系统的弊端已经暴露无遗，所以分而治之、功能拆分和服务化的思想自然而然的就被引入了进来。微服务架构便是经由单体应用架构—SOA架构—MSA架构这样的脉络演变而来。
2微服务架构的电力客户服务应用构建研究
建设一套满足电力信息化需要的多元渠道受理与统一维护的客户服务系统己经纳入了议事日程。在此背景下，采用分布式部署的微服务的架构是改造电力系统平台建设的首要之选。微服务架构解决了传统架构接口多、耦合紧密、快速扩展难、软件复用成本低、运营沟通成本高的问题，与之相对的微服务架构因各个服务单独部署和发布，复杂的电力客户服务系统应用程序拆分为一个个独立的且代码体量小的服务，由服务治理系统统一进行管理，每个微服务为一个进程，满足了电力客户服务系统对交互性能以及高扩展运维性的业务需求。
2.1电力客户服务应用架构方案
2.1.1微服务架构设计方案
基于总体业务规划，为实现系统灵活可扩展，业务中台采用技术先进、成熟的基于Spring Cloud的微服务架构，由微应用、微服务、注册中心、配置中心、服务网关和服务监控组成。微应用提供人机交互界面，专注于用户体验；微服务为微应用提供服务，专注于业务逻辑处理；注册中心提供微服务注册信息储存，实现微服务间解耦；配置中心提供分布式环境下统一动态配置管理；服务网关为微服务提供统一访问入口；服务监控提供微服务状态和调用链路监控。
2.1.2总体架构设计
基于微服务架构，电力客户服务应用总体架构划分为界面展示层、服务接入层、服务层、数据存储层、业务系统层和基础资源层，通过各层次系统组件间服务的承载关系，实现系统功能。界面展示层：包括PC端的业务中台和终端设备上的APP。服务接入层：提供服务请求的统一接入、协议转换、界面资源、负载均衡等服务。应用服务层：主要包括业务中台服务。技术服务层：主要包括服务注册/发现、服务网关、服务调度、服务配置、熔断管理、服务监控、加密解密。数据存储层：提供结构化数据、非结构化数据、缓存数据的存储及服务，可以按需供应服务及横向扩展。业务系统层：主要包括相关业务处理系统，如营销业务应用、用电信息采集系统、生产管理系统(PMS)等。基础资源层：主要包括计算资源、存储资源、网络资源等。
2.2微服务设计
2.2.1服务划分
大数据分析平台按照业务将主要的功能划分为了5个微服务。本文将用户管理独立为了用户服务。将数据源管理、数据拉取管理、数据文件管理等三个和数据有关的模块划分到了数据服务中。而分析服务中则包含了和算法分析有关的5个模块，分析项目模块、实验管理模块、模型管理模块、算法服务管理模块和算法介绍管理模块。可视化服务包含了用于数据可视化的可视化管理模块。任务消息管理模块划分到了用于执行异步任务的任务服务中，当异步任务执行完毕之后直接调用任务消息将任务执行完毕的消息告知给用户。
2.2.2服务治理
对于服务的治理是设计和实现微服务架构中极其重要的一环。而在服务治理的设计和实现的过程中，最为重要的部分又是注册中心的设计和实现。目前在市面上，最为人熟知就是Zookeeper和Eureka这两种解决方案，这两者又因为设计和实现的不同，导致了应用场景不同。Zookeeper的设计原则则是进行了一个取舍，选择了CAP中的CP，保证了数据的强一致性和分区的容错性，但是放弃了可用性，一旦出现网络波动，可能会导致Zookeeper变成不可用的状态。与Zookeeper设计原则不同的是，选择了AP，Eureka选择了放弃数据的强一致性。大数据分析平台在综合考虑后则选择使用了Eureka组件用于管理服务注册和发现，很好将各个服务管理起来。Eureka Server是注册中心的服务端(Eureka Server是以组件的形式组装到Spring Cloud的工程中)，用于管理和维护所有注册的服务端中的服务，将它们放到一个服务列表中。Eureka Client是注册中心的客户端(用于描述所有其他向服务端中注册的应用)，凡是注册到Eureka服务列表中的应用都是客户端。
2.2.3服务通信
在微服务架构中我们常常通过网络通信技术来完成服务之间的信息互通。最常用的方式是RPC和HTTP。Spring Cloud本身选择HTTP协议来完成各个微服务的通信，目前实现方式有两种，一种是Rest Template，一种是Feign。当场景比较复杂时需要产生复杂的服务调用时，可能需要涉及到Rest Template更深级别更底层的API时，可能更加倾向于Rest Template而不能使用Feign的方式。其他情况的话，更加倾向于更加方便的Feign。Feign为开发者提供了请求模板，只需要编写相应的接口并且采用对应的注解完善服务接口需要的网络请求参数、请求的格式、请求服务对应的IP等信息。大数据分析平台采用的是Feign的形式进行服务之间的通信。
2.2.4服务网关
Spring Cloud中有一个Zuul组件可以为大数据分析平台实现反向代理的功能，Zuul会将外部请求转发到对应的服务上，同时Zuul中还可以存放公共的处理代码。Filter是Zuul组件最为重要的部分，正是因为有了它Zuul才能够实现对外来请求的管理。Filter的整个生命周期包含了Pre，Routing，Post，Error四部分。Pre，通常可使用Pre来实现身份的验证等功能，会在外部请求被Zuul路由到具体的服务之前被调用。Routing，将外部请求路由到具体能够处理该请求的服务中。Post，在外部请求路由到具体的服务处理完请求之后被执行，可以用来为服务器响应请求添加需要的信息。Error:在剩阶段发生错误时会被执行。
2.2.5负载均衡
Ribbon是Spring Cloud中一个基于HTTP和TCP客户端的实现负载均衡的一个组件。在Spring Cloud的Eureka，Feign，Zuul等组件内部实现时默认都使用了Ribbon实现了负载均衡的功能。
2.2.6服务接口
大数据分析平台的服务接口采用了RESTful的设计风格进行的设计。REST意为表述性状态转换，是目前开发中比较流行的Web API的设计规则，给使用者提供了一种方便理解的API，是一种通用的设计规范。使用HTTP的method代替传统接口设计中的动词，API中URL只保留了资源的名词而使用请求方式来区分动作。以分析服务的模型模块为例。当需要添加时，使用POST方法，删除模型时，用DELETE方法，当需要要查询时，使用GET方法，当更新模型信息时，使用PUT方法。而URL并不包含任何动词，仅仅包含代表模型资源的名词。
3结束语
在“用什么，建什么”的传统建设思想上，本文提出一种新的基于微服务架构的电力客户服务应用构建方法，通过构建终端应用及业务中台，灵活响应外部业务需求变化，当出现新的业务需求时，可复用基础功能，独立开发新的微应用，实现流程互通，数据共享。
参考文献
[1]刘俊玲,杨维,朱平飞,等.电力营销多渠道微服务架构设计[J].供用电,2019,36(6):79-84+72.
[2]赵冠东,张才俊,欧阳红,等.基于业务中台的全渠道运营支撑平台架构设计研究[J].供用电,2019,36(6):67-71+61.