CN112968943B - 一种电力协同平台 - Google Patents

Abstract

本申请提供了一种电力协同平台，包括：网关、注册配置中心集群和微服务集群，其中，电力协同平台采用微服务架构生成；微服务集群从注册配置中心集群获取配置信息；依据配置信息，启动微服务；并将启动的微服务注册到注册配置中心集群；注册配置中心集群依据注册的微服务，确定微服务列表；网关在接收到用于访问微服务的http请求的情况下，对http请求进行鉴权；在鉴权通过后，从注册配置中心集群获取微服务列表；网关将http请求发送到微服务集群中微服务列表包含的微服务。由于微服务间的代码耦合度低，使得本申请的电力协同平台在任何局部功能修改的情况下，都无需重新编译和部署，进而，相对于现有技术，可以提高处理效率低。

Description

一种电力协同平台

技术领域

本申请涉及电力领域，尤其涉及一种电力协同平台。

背景技术

随着互联网时代的来临，客户的需求变化越来越快，应用系统的规模以及复杂度也在不断的增长，用户对获得优质、便捷、多元化的服务需求日趋上升。

受制于传统IT技术的制约和思想观念的束缚，目前，企业平台的架构设计模式包括：三层架构、单体架构和SOA架构。

但是，目前的架构体系会出现在任何局部功能的修改造成单体应用重新编译和部署，进而，导致处理效率低。

发明内容

本申请提供了一种电力协同平台，目的在于解决处理效率低的问题。

为了实现上述目的，本申请提供了以下技术方案：

本申请提供了一种电力协同平台，包括：网关、注册配置中心集群和微服务集群，其中，所述电力协同平台采用微服务架构生成；

所述微服务集群，用于从所述注册配置中心集群获取配置信息；依据所述配置信息，启动微服务；并将启动的微服务注册到所述注册配置中心集群；

所述注册配置中心集群，用于依据注册的微服务，确定微服务列表；所述微服务列表由所述注册的微服务中的可用微服务构成；

所述网关，用于在接收到用于访问微服务的http请求的情况下，对所述http请求进行鉴权；

所述网关，还用于在鉴权通过后，从所述注册配置中心集群获取所述微服务列表；

所述网关，还用于将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务。

可选的，所述网关，还用于将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务，包括：

所述网关，具体用于通过负载均衡将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务。

可选的，还包括：断路器；

所述断路器，用于对所述网关调用微服务过程中出现的超时和错误进行处理。

可选的，所述微服务集群，还用于从所述注册配置中心集群获取所述微服务列表。

可选的，还包括：服务监控组件；

所述服务监控组件，用于监控所述注册配置中心集群中的应用程序。

可选的，还包括：性能监控平台和日志系统；

所述性能监控平台，用于收集预设资源对象；

所述日志系统，用于对所述微服务集群中的微服务进行日志收集。

可选的，所述电力协同平台的前后端分离；其中，前端通过Http/Https协议调用所述网关。

可选的，所述注册配置中心集群、所述网关和所述微服务集群分别部署多个应用；其中，所述多个应用之间通过负载均衡的方式对外提供服务。

可选的，所述微服务集群包括两个微服务容器集群；所述两个微服务容器集群间的微服务通过预设框架进行调用。

可选的，在功能架构上包括：服务开放模块和客户服务模块；其中，

所述服务开放模块，用于提供服务接入和服务管理；

所述客户服务模块，用于提供预设的服务；所述服务包括：工单服务、用户服务、账单服务、消息服务和交费服务。

本申请所述的电力协同平台，包括：网关、注册配置中心集群和微服务集群，其中，微服务集群从注册配置中心集群获取配置信息，依据配置信息，启动微服务，将启动的微服务注册到注册配置中心集群。注册配置中心集群依据注册的微服务，确定微服务列表。其中，微服务列表由注册的微服务中的可用微服务构成。网关在接收到用于访问微服务的http请求的情况下，对http请求进行鉴权，在鉴权通过后，从注册配置中心集群获取微服务列表，并将http请求发送到微服务集群中微服务列表包含的微服务。即本申请在微服务架构的基础上，实现对http请求的响应。

在本申请中，由于电力协同平台采用微服务架构生成，并且，微服务架构具有每个微服务可独立运行在自己的进程里，以及每个服务为独立的业务开发，一个微服务只关注某个特定的功能的特点，即微服务间的代码耦合度低，使得本申请的电力协同平台在任何局部功能修改的情况下，都无需重新编译和部署，进而，相对于现有技术，可以提高处理效率低。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种电力协同平台的结构示意图；

图2为本申请实施例公开的电力协同平台中微服务的启动、对http请求的响应过程示意图；

图3为本申请实施例公开的又一种电力协同平台的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

发明人在研究中发现，现有的架构体系在任何局部功能的修改都会造成单体应用重新编译和部署，进而，导致处理效率低的原因包括：随着用户需求的个性化，一部分企业的业务场景变得越来越复杂。在有些场景下采用传统的系统架构，会使得业务应用变得越来越庞大，代码逻辑越来越复杂，代码之间、模块之间耦合度越来越高，因此，导致任何局部功能的修改都会造成单体应用重新编译和部署。

图1为本申请实施例提供的一种电力协同平台，其中，电力协同平台采用微服务架构生成。基于微服务架构，本申请实施例提供的电力协同平台前后端分离。其中，前端通过Http/Https协议调用网关。

该电力协同平台可以包括：网关、注册配置中心集群、微服务集群、断路器、服务监控组件、性能监控平台和日志系统。需要说明的是，在实际中，断路器、服务监控组件、性能监控平台和日志系统都是可选的。其中，性能监控平台具体可以为APM系统。

其中，微服务集群中的微服务启动、向注册配置中心集群注册微服务，以及网关在接收到http后，对微服务的访问过程如图2所示。具体可以包括以下步骤：

S201、微服务集群从注册配置中心集群获取配置信息。

在本实施例中，微服务集群可以包括两个微服务容器集群和容器集群管理。其中，每个微服务容器集群部署有多个用于负载均衡的微服务。并且，两个微服务容器集群通过容器集群管理进行管理。其中，容器集群管理可以为K8S。当然，在实际中，容器集群管理还可以为其他形式，本实施例不对容器集群管理的具体形式作限定。

S202、微服务集群依据配置信息，启动微服务。

在本实施例中，可以通过容器集群管理的图像化界面，启动全部的微服务镜像。其中，具体的启动过程为现有技术，这里不再赘述。

S203、微服务集群将启动的微服务注册到注册配置中心集群。

S204、注册配置中心集群依据注册的微服务，确定微服务列表。

在本实施例中，微服务列表由注册的微服务中的可用微服务构成。

在本实施例中，注册配置中心集群具有对各微服务进行统一参数配置以及版本管理的功能。因此，在本实施例中，注册配置中心集群还可以对注册的微服务进行统一修改配置，其中，修改的配置及时生效。

S205、微服务集群从注册配置中心集群获取微服务列表。

S206、网关在接收到用于访问微服务的http请求的情况下，对http请求进行鉴权。

在本实施例中，客户端在登录电力协同平台后，可以向电力协同平台发送http请求，网关接收到该http请求。

在本实施例中，网关可以为API路由网关。该网关具有统一鉴权功能和网关服务功能。在本步骤中，网关对接收到的http请求进行鉴权，其中，鉴权的具体实现过程为现有技术，这里不再赘述。

S207、网关在鉴权通过后，从注册配置中心集群获取微服务列表。

在本实施例中，网关从注册配置中心集群获取到微服务列表，就获取到微服务列表包含的可用微服务。

在本步骤中，网关从注册配置中心集群获取到微服务列表的实现方式可以包括：网关可以向注册配置中心集群发送服务请求，注册配置中心集群在收到服务请求的情况下，将微服务列表发送给网关。

S208、网关将http请求发送到微服务集群中微服务列表包含的微服务。

在本步骤中，网关将http请求发送到微服务集群中微服务列表包含的微服务上。

可选的，网关通过负载均衡将http请求发送到微服务集群中微服务列表包含的微服务。

S209、断路器对网关调用微服务过程中出现的超时和错误进行处理。

在服务之间进行调用时，由于各种原因会导致远程服务不可用或压力过载等异常导致的故障蔓延，此时需要有一种机制进行保护处理。网关服务通过Netflix的Hystrix组件实现熔断和降级处理解决此问题。

断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施，网关服务通过Netflix的Hystrix组件提供断路器、资源隔离与自我修复功能。即在本步骤中，断路器用于对网关调用微服务过程中出现的超时和错误进行处理。

在本实施例中，电力协同平台还可以包括服务监控组件，该服务监控组件用于监控注册配置中心集群中的应用程序。具体的，可以使用服务断路器(Hystrix)组件进行服务的监控，并使用服务监控(Nagios)进行服务器等资源的监控。其中，优点可以包括：①Hystrix，监控和断路器。只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。②由于监控面板(Hystrix Dashboard)提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

在本实施例中，电力协同平台还可以包括：关系型数据库集群和缓存集群。其中，关系型数据库集群和缓存集群分别与微服务集群连接。其中，缓存集群可以为Redis缓存集群，Redis是一种配置服务器，用于内存缓存。其中，关系型数据库集群可以包括多个数据库，具体可以包括主库、从库和备库。其中，主库、从库和备库之间的数据是同步的。Redis缓存集群用于缓存数据。

在本实施例中，性能监控平台用于收集预设的资源对象。其中，预设的资源对象可以为k8s集群中的一个资源对象，可以简称为EndPoint。

在本实施例中，电力协同平台还可以包括日志系统。其中，日志系统用于对微服务集群中的微服务进行日志收集。

在实际中，不同的微服务可以部署在不同节点上，因此，需要登录每个节点查看日志，进而比较麻烦，同时，对于需要关联多个微服务日志联合查看分析的情况，将更加麻烦。但是，伴随节点数量的增加，如果没有合适的管理机制与工具，定位问题、发现问题的复杂性将越来越大，将成指数级增长，因此需要建立统一的日志管理规范，开发并使用统一的日志组件，为全部微服务提供统一的日志服务，建立统一的日志中心，使得全部日志写入日志中心。

因此，在本实施例中，电力协同平台包括日志系统，用于对微服务集群中的微服务及进行日志收集。

在本实施例中，注册配置中心集群、网关和微服务集群分别可以部署多个应用。其中，多个应用之间通过负载均衡的方式对外提供服务。协同平台的具体结构示意图可以如图3所示。在图3中，注册配置中心可以包括三个注册配置组件，网关中可以部署三个网关服务，微服务集群中可以部署两个微服务容器集群。其中，三个注册配置组件、三个网关服务和两个微服务容器集群之间可以通过负载均衡的方式，对外提供服务。

在本实施例中，微服务集群由两个微服务容器集群构成。其中，两个微服务容器集群间的微服务通过预设框架进行调用。其中，预设框架可以为feign(一个http请求调用的轻量级框架)。采用feign调用可以减少项目中的相互依赖。比如现在有项目a调用项目b，项目b调用项目c...一直到h，是一个调用链，那么项目上线的时候需要先更新最底层的h再更新g...更新c更新b最后是更新项目a。这只是这一个调用链，在复杂的业务中有非常多的调用，如果要记住每一个调用链对开发运维人员来说就是灾难。有这样一个好办法可以尽量的减少项目的相互依赖，就是服务编排，一个核心的业务处理项目，负责和各个微服务打交道。比如之前是a调用b，b掉用c，c调用d，现在统一在一个核心项目W中来处理，W服务使用a的时候去调用b，使用b的时候W去调用c。

在本实施例中，基于微服务架构的电力协同平台具有以下特点：

(1)把电力协同平台根据业务拆分成若干个中心(例如，注册配置中心集群)、子系统(例如，网关)和微服务(例如，微服务集群)。

(2)每个子系统可以部署多个应用，多个应用之间使用负载均衡。

(3)包括配置注册中心集群，全部的服务都在配置注册中心集群注册。

(4)全部的客户端都可以通过同一个网关地址访问电力协同平台的服务，通过路由配置网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候使用负载均衡。

(5)服务之间采用feign进行调用。

(6)使用断路器可以及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。

(7)每个微服务独立执行持续集成。

在实际中，随着信息化建设的不断发展，用户对获得优质、便捷、多元化的服务需求日趋上升，采用传统的系统架构会出现迭代周期变长的趋势，不利于频繁部署，从而导致整个业务应用灵活度差、持续交付能力弱、维护困难，出现线上用户高并发、大流量的集中式访问、运行负载增加、各渠道独立运行，服务资源孤立分散，资源利用率偏低等现状，造成客户服务体验存在差异的服务瓶颈。在本实施例中，电力协同平台采用微服务架构，从而，可以克服现有技术中系统架构出现的迭代周期长的问题，从而，可以避免整个业务应用灵活度差，持续交付能力弱，维护困难等问题，从而，避免出现客户服务体验存在差异的服务瓶颈。

本申请实施例提供的电力协同平台采用微服务架构生成，并且，在微服务架构基础上，电力协同平台的功能架构可以包括：服务开放模块和客户服务模块。其中，服务开放模块，用于提供服务接入和服务管理。客户服务模块，用于提供预设的服务。其中，预设的服务可以包括：工单服务、用户服务、账单服务、消息服务和交费服务。

其中，服务开放模块的实现过程可以包括：第一，基于微服务分布式架构设计，通过研究外网手机端用户上传的数据与信息内网的交互方式，完成内外网穿透服务的封装开发。第二，用以沉淀企业级客户服务能力，协同管理电力营销APP、微信公众号、支付宝生活号等多渠道的统一运营，实现对本地渠道客户诉求的统一接入，对接客户服务模块的业务服务。第三，提供支撑服务渠道微应用的资源容器服务。第四，建立支撑微服务架构的技术平台，承载服务开放模块中各项业务的微服务，对微服务进行统一接入、调度、管理。第五，根据服务开放模块的运营战略，研发建设线上服务开放模块，规范服务接入标准，支撑业务能力复用和前端应用快速创新。

在本实施例中，服务开放模块的功能可以包括：

第一，通过研发建设线上服务开放模块，可以集成统一日志、统一监控、统一配置的能力。第二，为线下营业厅、区域客户、政府公共服务等第三方应用渠道提供客户服务能力标准化接入，集成服务调度、服务认证、服务加密等功能，并对接入安全性、接入流量以及调用过程均可控。第三，集成运维和监控工具，对第三方应用提供标准、安全、可控的客户服务能力标准化输出。第四，集成服务鉴权、服务监控等功能，对外提供服务接入和服务治理能力，提升电力协同平台的扩展性及可维护性。

在本实施例中，线上服务开放模块的研发与建设，完成了对本地渠道架构的优化改造，对现有的微信公众号及支付宝生活号按照微服务技术体系进行重构编排，并且从管理和技术上建立统一标准，完成与电力营销APP接口互调，第三方应用集成接入，实现各渠道协同管理，推动了客户服务模块的业务应用。

在本实施例中，客户服务模块需要达到以下功能：

第一，围绕电力营销用户融合与业务融通的战略目标，实现全渠道客户服务能力。第二，通过建设客户服务模块，完成渠道存量用户向上迁移，聚合用户注册、登录、绑定、认证、解绑等数据，建立渠道间的用户关联。第三，实现单渠道办理缴费、工单业务，全渠道查询缴费记录、工单办理进度，各渠道体验统一的业务目标。第四，完成对线上客户渠道的替代和各渠道之间的协同管理。第五，实现跨部门、跨专业的资源共享、业务协同、能力复用。

在本实施例中，客户服务模块可以提供工单服务、用户服务、账单服务、消息服务、交费服务。

其中，工单服务主要可以包括：业扩工单受理、客服服务工单受理、业扩工单审核、客户服务工单审核等其他类型工单的派发、查询、聚合等业务。为支撑电力协同平台实现全渠道客服服务目标，基于规则引擎理念建设智能应答系统，通过人机互问的方式处理常规的线上渠道服务诉求，采用智能机器人、语义分析、应答等技术，以大数据分析平台为依托，转变服务模式，实现用户对答案的智能化、自动化、主动化获取，降低人工客服坐席接待工作量。

通过工单服务中心，聚合业扩办电、客户服务等各项业务工单，形成集中统一的工单池，实现全业务、全渠道、跨层级工单的统一生成、聚合、审核、派发、处理、查询及全过程监控。聚合渠道工单，支撑全渠道工单数据进行分析统计。

其中，用户服务主要可以包括：用户注册、用户信息管理、用户户号管理、客户档案信息查询、用户实名认证、用户渠道管理、用户户号绑定等业务。为建立适用于多个渠道的用户模型，以全渠道互联网账户信息、用户基础档案信息及用户行为特征信息为基础建立统一用户信息库，以用户手机号作为账户统一标识，建立用户账户体系。其中，客户实体对应自然人，账户对应手机号，多个手机号码认为是多个账户。用户体系的设计需要满足准确定义、精准识别不同自然人用户、平台账户及用电客户的特征信息，理清不同用户之间的区别和联系的原则。通过构建以手机号为标识的用户体系，实现了用户一次登录，全渠道应用的业务诉求以及本地渠道的迁移聚合，节省了线上渠道重复推广成本，提高了多渠道用户的唯一性识别能力，规避后续运营活动权益发放的用户账号风险，完成了本地渠道与营销app用户的注册、登录、绑定、认证、解绑等业务一致性融合，实现了全渠道用户融合的服务目标，满足电力协同平台以客户为中心的价值创新要求。

为提升用户的活跃度，增强用户黏性，基于用户体系架构设计建立用户积分体系，激励用户参与分享、拉新、促进电费回收等运营活动，引导用户完善个人信息和身份认证，并基于用户积分体系，设计积分任务等创新功能，进一步提升用户的参与感和成就感，提升整个线上服务渠道的用户体验。

其中，账单服务主要可以包括：电量账单、电费账单、抄表账单、电子发票的数据接入，账单融合，电子发票开具，电子账单订阅等业务。账单服务是用户能源消费信息汇聚、电子账单生成及管理的中心，满足用户电费、业务费及补贴等统一账单在线查询、下载、推送、订阅和打印需求，并为客户提供电量电费信息实时查询、推送、订阅等服务，满足不同客户的账单服务需求。

其中，消息服务主要可以包括：在线消息、短信消息、停电信息、营销信息等全渠道消息的统一发送、接收和保存以及消息模板、消息渠道管理等业务。通过用户行为分析对用户消息、策略规则、消息推送进行个性化统一管理，满足全渠道消息统一接入、监控、推送等要求，具备每日千万级的推送能力。其中，消息类型支持文本、语音、富媒体等多种类型格式。消息中心通过微信模板消息触达用户手机端，推动营销类业务短信替代工作，由线上渠道发送电费提醒、催费通知、停电通知、费控短信等通知类消息，节约短信发送成本。

其中，交费服务主要可以包括交费订单生成、积分订单生成、交费订单查询、积分订单查询、交费对账、电费充值、交费全记录接入等业务。通过对交费服务的建设，实现对用户全渠道交费服务统一管理，支撑用户对交费业务实现统一处理、统一查询。

本申请实施例以微服务架构为总体技术路线，按照领域模型，合理划分客户服务能力，模块化、低耦合地实现微服务应用，秉承以客户为中心的全渠道运营管理战略原则，建设电力协同平台，完成全渠道服务资源规范化融合，实现全渠道客户服务的统一接入、统一服务和统一管理，确保用户体验的一致性，提高客户用电获得感。

本申请实施例提出了一种电力协同平台。其基本思路分为三步：第一步，采用网关服务、服务监控等微服务组件，构建微服务分布式架构，集成链路监控、注册配置中心,利用分布式存储技术，建立可弹性拓展的应用服务集群；第二步，基于电力营销多渠道并行现状，按照分布式技术标准，采用微服务架构+领域模型的开发模式，规划设计功能模块结构，打造以能力建设为中心的全渠道协同管理平台。第三步，围绕电力营销用户融合与业务融通的战略目标，将电力营销全渠道协同管理平台分为两大模块，分别是服务开放模块、客户服务模块。其中服务开放模块提供服务接入、服务管理能力，客户服务模块提供具体业务服务能力。

需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，本说明书中各实施例中记载的特征可以相互替换或者组合，使本领域专业技术人员能够实现或使用本申请。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种电力协同平台，其特征在于，包括：网关、断路器、服务监控组件、注册配置中心集群和微服务集群，其中，所述电力协同平台采用微服务架构生成；

所述微服务集群，用于从所述注册配置中心集群获取配置信息；依据所述配置信息，启动微服务；并将启动的微服务注册到所述注册配置中心集群；

所述注册配置中心集群，用于依据注册的微服务，确定微服务列表；所述微服务列表由所述注册的微服务中的可用微服务构成；

所述网关，用于在接收到用于访问微服务的http请求的情况下，对所述http请求进行鉴权；

所述网关，还用于在鉴权通过后，从所述注册配置中心集群获取所述微服务列表；

所述网关，还用于将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务；

所述断路器，用于对所述网关调用微服务过程中出现的超时和错误进行处理；

所述服务监控组件，用于监控所述注册配置中心集群中的应用程序。

2.根据权利要求1所述的电力协同平台，其特征在于，所述网关，还用于将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务，包括：

所述网关，具体用于通过负载均衡将所述http请求发送到所述微服务集群中所述微服务列表包含的微服务。

3.根据权利要求1所述的电力协同平台，其特征在于，

所述微服务集群，还用于从所述注册配置中心集群获取所述微服务列表。

4.根据权利要求1所述的电力协同平台，其特征在于，还包括：性能监控平台和日志系统；

所述性能监控平台，用于收集预设资源对象；

所述日志系统，用于对所述微服务集群中的微服务进行日志收集。

5.根据权利要求1所述的电力协同平台，其特征在于，所述电力协同平台的前后端分离；其中，前端通过Http/Https协议调用所述网关。

6.根据权利要求1所述的电力协同平台，其特征在于，所述注册配置中心集群、所述网关和所述微服务集群分别部署多个应用；其中，所述多个应用之间通过负载均衡的方式对外提供服务。

7.根据权利要求6所述的电力协同平台，其特征在于，所述微服务集群包括两个微服务容器集群；所述两个微服务容器集群间的微服务通过预设框架进行调用。

8.根据权利要求1所述的电力协同平台，其特征在于，在功能架构上包括：服务开放模块和客户服务模块；其中，

所述服务开放模块，用于提供服务接入和服务管理；

所述客户服务模块，用于提供预设的服务；所述服务包括：工单服务、用户服务、账单服务、消息服务和交费服务。

Images