CN110913018A - 一种分布式调控服务系统 - Google Patents

Abstract

本发明公开了一种分布式调控服务系统，包括：接口服务器集群，包括至少两台接口服务器，用于获取客服终端的指标数据；分布式计算服务器集群，包括至少两台计算服务器，用于对所述指标数据进行计算，获得计算结果；应用服务器集群，包括至少两台应用服务器，用于接收对所述指标数据及所述计算结果的访问请求，并返回访问结果；数据库集群，包括至少两台数据库服务器，用于将所述指标数据提供给所述分布式计算服务器集群进行高速访问；其中，所述接口服务器集群、所述分布式计算服务器集群、所述应用服务器集群及所述数据库集群通过网络相连接。

Description

一种分布式调控服务系统

技术领域

本发明涉及系统架构技术领域，特别涉及一种分布式调控服务系统。

背景技术

为了对客户用电进行业务服务，供电公司通常需要对业务服务进行调控。

但是目前通常使用单台机器及人工判断进行调控的方式，造成调控效率较低的问题。

发明内容

有鉴于此，本发明的目的在于提供一种分布式调控服务系统，用以解决现有技术中单台机器调控效率较低的技术问题。

本发明提供了一种分布式调控服务系统，包括：

接口服务器集群，包括至少两台接口服务器，用于获取客服终端的指标数据；

分布式计算服务器集群，包括至少两台计算服务器，用于对所述指标数据进行计算，获得计算结果；

应用服务器集群，包括至少两台应用服务器，用于接收对所述指标数据及所述计算结果的访问请求，并返回访问结果；

数据库集群，包括至少两台数据库服务器，用于将所述指标数据提供给所述分布式计算服务器集群进行高速访问；

其中，所述接口服务器集群、所述分布式计算服务器集群、所述应用服务器集群及所述数据库集群通过网络相连接。

上述系统，优选地，还包括：

负载均衡服务器，分别与所述系统中的每个集群相连接，用于对每个所述集群进行负载均衡。

上述系统，优选地，还包括：

历史服务器集群，与所述接口服务器集群相连接，包括至少两台历史服务器，用于存储历史的指标数据。

上述系统，优选地，还包括：

防火墙服务器，连接在所述客服终端及所述接口服务器集群之间，用于为所述接口服务器集群提供安全策略。

上述系统，优选地，还包括：

报警器，与所述分布式计算服务器集群相连接，用于基于所述计算结果生成报警信息。

上述系统，优选地，所述报警器包括：声音播放器。

上述系统，优选地，所述报警器包括：显示器。

上述系统，优选地，所述报警器包括：通信组件，所述通信组件用于基于所述计算结果将所述报警信息发送给通信终端。

上述系统，优选地，所述数据库服务器为实时数据库。

由上述方案可知，本发明提供的一种分布式调控服务系统中，通过设置分布式计算服务器集群对接口服务器集群所获取到的客服终端的指标数据进行计算，从而得到进行调控的计算结果，再通过应用服务器集群提供给用户进行访问，从而实现实时调控。本发明通过设置分布式计算服务器集群来实现快速的数据计算从而实现快速有效的客服调控，实现本发明目的。

附图说明

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

图1为本发明实施例一提供的一种分布式调控服务系统的系统架构图；

图2为本发明实施例一的另一架构图；

图3～图6分别为本发明实施例的应用示例图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

参考图1，为本发明实施例一提供的一种分布式调控服务系统的系统架构图，该微服务调控系统可以用于对客户用水或用电等相关业务微服务进行集中调控。

在本实施例中，该微服务调控系统可以包括以下结构：

接口服务器集群101，包括至少两台接口服务器，用于获取客服终端的指标数据。

其中，客服终端可以为各种数据源的终端，如电网运营管理系统、桌面监控系统、统计数据发布服务器等，其中，桌面监控系统可以包含有：话务平台终端、互动网站终端及业务支持系统终端等。

需要说明的是，这里的指标数据可以包含：实时类话务数据、座席类数据和业务类数据的指标数据，本实施例中，接口服务器可以通过socket接口获取这些指标数据，还可以通过jdbc接口方式或界面集成方式对指标数据进行同步，并利用webservice接口方式对历史的指标数据进行获取。

分布式计算服务器集群102，包括至少两台计算服务器，用于对所述指标数据进行计算，获得计算结果。

其中，分布式计算服务器集群102中可以利用负载均衡方案将计算任务进行平衡到相应的计算服务器中，计算服务器对指标数据进行预警计算等处理，从而生成包含预警等信息的计算结果。

应用服务器集群103，包括至少两台应用服务器，用于接收对所述指标数据及所述计算结果的访问请求，并返回访问结果。

其中，应用服务器上设置有各种浏览器，用户可以通过浏览器输入对指标数据及计算结果的访问信息，从而在应用服务器上生成访问请求，并对该访问请求进行处理，向用户返回访问结果。

数据库集群104，包括至少两台数据库服务器，用于将所述指标数据提供给所述分布式计算服务器集群进行高速访问。

其中，数据库服务器为分布式计算服务器集群提供指标数据的高速存取服务，从而加快客服调控的速率。

其中，所述接口服务器集群101、所述分布式计算服务器集群102、所述应用服务器集群103及所述数据库集群104通过网络相连接。

需要说明的是，这里的网络可以是通过交换机或者路由器组成的局域网。

负载均衡服务器105，分别与所述系统中的每个集群相连接，用于对每个所述集群进行负载均衡。

其中，负载均衡服务器105与系统中的每个集群中的服务器相连接，采用负载均衡方案稳定各个服务器的可靠性。例如，负载均衡服务器105可以利用轮询法或者加权随机法对各个集群中的服务器的负载进行均衡处理。

历史服务器集群106，与所述接口服务器集群相连接，包括至少两台历史服务器，用于存储历史的指标数据。

其中，历史服务器中可以为与指标数据相同数据结构的数据服务器实现，以提供历史指标数据的存储服务。

防火墙服务器107，连接在所述客服终端及所述接口服务器集群之间，用于为所述接口服务器集群提供安全策略。

其中，在负载均衡服务器与客户服务网络如电力内网之间还可以设置有防火墙，用以保证两侧网络安全。

另外，本实施例中还可以包含：报警器108，与所述分布式计算服务器集群相连接，用于基于所述计算结果生成报警信息。

其中，报警器108可以包括：声音播放器、显示器和通信组件中的一个或多个，所述通信组件用于基于所述计算结果将报警信息发送给通信终端，所述声音播放器将报警信息通过音频进行输出，而显示器是将报警信息显示在屏幕上，从而得到提醒用户的目的，如图2中所示。

以下对本实施例在电网客服中心运营调控中的应用进行举例说明：

在电网业务服务中，本实施例中提供的电网客服中心的微服务器调控系统可以包含以下物理架构，如图3中所示：

其中，至少2台PCServer组成接口服务器集群，负责从其他系统获取指标数据，如从桌面监控系统、基础支撑平台、呼叫平台、业务支持系统及智能互动网站等终端上获取数据。

至少4台PCServer组成分布式计算服务器群组，提供指标数据的实时计算及各预警的实时匹配计算工作。

至少2台PCServer组成应用服务器集群，提供中心、分中心相关岗位人员的web访问服务。

至少2台PCServer组成历史服务器集群，提供历史指标数据的存储服务。

至少2台PCServer组成实时数据库集群，提供指标数据的高速存取服务。

而，系统采用负载均衡服务器来稳定各服务器的可靠性。

而基于图3中所示的物理架构，设计如下软件环境：

在开发环境中，分布式调控服务系统可以采用SG-UAP平台基于J2EE框架采用Java语言进行开发。集成开发环境采用UAPStudio。采用PowerDesigner进行数据库建模。源代码版本管理采用SVN。在测试方面采用LoadRunner对系统整体性能进行压力测试，并通过缺陷管理软件进行缺陷管理。在生产环境中，在展现层通过UAP前段MX框架以及flex、JQuery框架提高展现的用户体验。按照应用集成典型设计，采用消息总线作为应用集成的消息服务平台。采用Weblogic11g作为J2EE应用服务器。

而分布式计算服务器群组中的各服务器基于OpenStack平台构建虚拟机环境为客户提供多种业务的微服务环境。而在微服务环境开发运维方面分为业务微服务开发和一体化集成两个步骤。其中，业务的微服务开发中基于springcloud架构，利用其基于快速应用开发框架(springboot)以及提供大量丰富基础组件(服务注册与发现、访问消费、负载均衡、断路器、智能路由、配置管理等)等特性，降低了开发难度，提高了应用开发效率。而在一体化集成中可以通过使用fabric8框架的编程接口及功能指令，快速整合业务微服务程序，将其转换为一个个由kubemetes(简称K8S)管控运行的POD(封装了1-N个紧密相关的docker容器)。由此，既可以弥补springcloud框架开发的微服务在部署管理方面的弱势，同时又解决了kubemetes在微服务开发框架方面短缺的不足。

以电网分布式调控服务系统为例，业务微服务开发方面，可以有十个微服务，分别为：支撑服务质量分析的工单填写质量分析服务、工单质量监控服务、咨询工单分类识别服务、工单内容分析服务、实时工单分析服务、实时工单查询服务、实时话务查询服务、坐席工效评估服务、工单分类分级服务、实时话务分析服务。本实施例中的微服务调控系统可以用来支撑包括一个统计分析类应用(坐席功效评估)、一个大数据应用(话务服务质量分析)、一个实时展示类的大屏应用(全景话务和实时工单)在内的三种应用场景。

而在一体化集成方面，经过对多种架构的对比分析(开发框架：SpringCloud、Dubbo、Jersey、Swagger等，部署框架：Kubernetes、Mesos和Swarm等)，最终确定一体化集成方案为以Farbic8框架为核心，综合利用Kubernetes，SpringCloud等技术。本实施例中的微服务调控系统可以来管控本期的十个微服务，实现其自动化管控和运维工作，同时为后期。

由此，微服务从包括统计分析类应用、大数据应用、实时大屏展示应用在内的三种不同业务需求场景出发，构建可灵活伸缩、自动化运维的应用程序。在应用开发方面借助微服务的“拆分”思想，进一步深化面“高内聚，低耦合”的思想(面向对象-&gt；面向服务)，解禁程序管控权限(应用开发时固定-&gt；应用开发完成后可变)，因此可根据具体业务繁忙程度，手动或自动增强应用程序的服务能力(扩展程序中某项服务的副本数)；在运维管理方面，借助微服务的容器编排管理技术，提高应用不间断服务的能力，同时降低运维管理成本。

基于以上开发环境，设计电网客服调控系统的技术架构，其中，基础平台：主要集成SG-UAP权限平台、流程引擎平台、任务调度平台、表报平台，图形平台由SG-UAP开发平台及D5000图库一体化配合完成。

实时监控平台：实时监控平台由信息集成组件、消息总线组件、实时库组件、关系库组件、服务总线组件构成。信息集成组件负责从桌面监控系统接入实时数据、从统一数据发布服务系统接入非实时数据，对接入的数据进行合法性校验、对冗余数据进行清洗，最终把数据归纳三类，分别是事件流(话务排队事件)、实时数据流(当前话务量)、非实时数据流(当班坐席)，数据集成组件把事件流路由消息组件，消息组件把事件高效广播给所关注的应用，应用程序快速相应后续处理工作；数据集成组件把实时数据流路由实时库组件，支撑应用的快速访问；数据集成组件把非实时数据流路由关系库组件，支撑应用对静态档案数据及历史数据访问。系统把资源访问、告警识别、调控支撑、系统管理等后台功能纳入服务总线管理，为应用统一提供支撑，服务总线按SOA架构设计，数据资源及底层算法变更时应用程序无需调整。

分布式计算平台:大数据量的统计分析可把数据装载到分布式计算环境，提升计算能力，并支持把计算结果回写给实时监控平台。

而以电网客服调控为例，以下对电网客服业务架构进行举例说明：

其中，运营监控基本业务包括中心、分中心及客服部的话务状态监控、回访监控、工单流转监控、环节超时监控、退单监控、坐席工作状态监控、人员效能监控、服务支撑监控、关键指标监控、供电服务监控、调控管理、环境视屏监控、舆情监控。

运营调控业务从业务运营和现场管控两条线出发，为一线现场管理人员提供区域内部座席状态监控和话务调度，实现现场协同调度、资源调配；为各级现场运营管理人员提供服务运营关键指标监控，展现客服运营状况全貌，实现辅助决策、服务质量、服务效率的提升。监控重点侧重于提升一线的异常事件智能定位、实时预警，以及事件处置的辅助支撑，成为提升运营管理能力的可靠助手。

而本实施例中在进行数据获取时，可以通过外部集成的方式实现数据接收，而外部集成的接口方式可以包括以下几种方式：

socket接口方式：与桌面监控系统采用socket方式获取指标数据，主要针对实时类话务、座席类和业务类指标。根据指标的不同属性，通过座席状态和业务数据两个socket接口实现数据实时同步和推送。

webservice接口方式：根据系统对历史的业务和话务指标的需求，由统一数据发布服务对指标数据进行整合，通过webservice方式对系统提供定制化查询服务。

Jdbc接口方式：针对运管系统涉及到的基础数据(供电单位、座席人员信息、技能信息等)，本实施例中的系统通过jdbc方式，实现与运管系统基础数据实时同步。

界面集成方式：涉及到系统应急管理模块中调控方式-批量调整用户权限，与运营管理系统通过界面集成的方式批量修改座席人员区域技能、座席技能、语种技能信息后，返回修改信息。

基于以上数据集成方式，在本实施例中采用的数据接入服务是通过socket和webservice方式接入桌面监控系统和基础支持平台的实时及历史数据，并将接收及返回的报文内容解析处理后存入实时和历史数据库中，最后根据数据发布接口订阅的数据指标发出相应的更新通知。

预警计算应用向数据发布接口订阅用于预警计算的数据指标，并接受数据发布接口返回的数据结果。根据定义的预警计算模型实时预警计算，当有预警产生时，即时发布并推送该预警信息至前台展示界面。

另外，本实施例中除了设置防火墙以提供安全策略之外，在系统的每个环节上也可以设置安全架构，本实施例中的安全防护设计覆盖系统的每个交互环节，进行应用安全的全方位防护设计，包括对每个防护控制点的防护设计，有效防范对服务器中应用或业务的非法访问，保证服务器的安全。以电网客服调控系统中的安全防护策略设计为例，如表1中所示：

表1

需要说明的是，在本实施例中电网的客服调控系统具体实现中，可以通过以下技术具体实现：

其中，对于数据库服务器即实时库的实现中，实时库可以采用实时数据库采用磁盘文件映射的内存管理机制实现，按类关系库结构化进行组织，实时库为数据库表、域、记录分配编码，并利用分配的表号、域、记录号按照规则生成唯一逻辑号，该逻辑号与内存物理地址映射，数据存取时直接操作指定的内存物理地址，因此能实现数据的快速存取，此外实时数据库结构设计遵循“面向对象、基于CIM、实现关系、重在效率”的设计原则。实时数据库主要功能及特点如下：

支持分布式结构和客户/服务器结构的数据库管理；

提供分布式的访问机制和数据库自动同步机制；

对那些要求高速访问的应用提供面向物理地址的访问机制；

支持数据库的并发访问，保证数据的安全性、一致性和完整性；

系统故障时具备数据库恢复和重新启动功能；

数据库快速拷贝和备份功能；

数据库断面存取及恢复功能；

提供多个计算机结点的多用户支持，并保证实时性；

提供主态、备态、研究态等面向多种应用的数据库，可灵活动态生成实时库子库，并提供相应的管理功能；

提供灵活的数据库编辑器、浏览器和其它工具，用户可在线监视、增减和修改数据库内的各种数据；

提供嵌入SQL语句的标准API接口，用户应用程序可以通过SQL语句访问系统的实时数据库。

而本实施例在系统中进行数据传输时，可以采用消息总线技术实现，例如实现异常事件的高效传递。其中，消息总线是承载事件流的载体，以注册发布的模式实现各个应用间消息高效传输，提高系统实时性。消息总线支持应用程序在节点内和节点间进行消息传递，利用组播技术和点对点技术分别实现一对多、一对一的信息交换。消息总线为单个应用程序分配独享内存，并可动态发明共享内存，这为消息高效传输和内存高利用率提供基础。

其中，消息总线负责应用程序间的实时事件传输，按照实时监控的特殊要求，具备高效实时的特点，为应用程序提供注册、撤销注册、订阅消息、撤销订阅、发布消息、接收消息等功能，为实现高效的数据通信提供可靠和通用的信息交互机制。为解决系统中实时消息在不同应用间的传输问题，消息总线屏蔽繁琐复杂的底层通信细节，通过提供简单、通用的消息原语，支持应用程序在节点内和节点间进行消息传递，并支持一对多、一对多的信息交换场合。消息总线采用订阅/发布模式进行数据传输，消息接收者只有在订阅某个事件集的消息后，才能接受属于该事件集的消息。消息发送者在发送消息时指定事件集，由消息总线将该消息发送给已订阅此事件集的所有消息接收者。消息原语使用场景，如图4所示。

而本实施例中系统的各个服务器中所安装的应用之间可以采用服务的方式进行交互，从而降低应用间耦合度，以及应用层、计算层、资源层间的耦合度；系统把服务在服务总线上进行注册，服务总线对服务进行监管，包括服务启停状态、资源占用情况等，异常时可报警，并做出相应的应急措施，提高系统的稳定性能。

其中，服务总线采用SOA架构，屏蔽实现数据交换所需的底层通信技术和应用处理的具体方法，从传输上支持应用请求信息和响应结果信息的传输，提供典型的服务请求模式，通过提供服务原语实现服务访问、服务响应和服务管理，满足系统对数据交互安全和统一性的要求。为解决系统在数据交互方式统一性的要求，服务总线对服务的信息进行注册管理，将服务的访问和应答请求信息进行内部封装，实现数据交换所需的底层通信技术和应用处理的具体方法，对服务访问与服务应带方式进行抽象，提出两种服务模型框架：请求/响应模型和订阅/发布模型。请求/响应模型提供“拉数据”的服务方式。服务请求者访问服务需发送服务请求，从服务发布者获取服务结果。订阅/发布模型提供“推数据”的服务方式。服务请求者访问服务时发送请求，由服务发布者根据需求向服务请求者主动推送服务结果。应用程序通过服务原语使用服务总线，根据不同的业务需要，采用请求/响应模型或者订阅/发布模型。

而请求/响应模式交互流程如图5中所示，而订阅/发布模式的交互流程如图6中所示。

另外，本实施例中分布式计算服务器在对指标数据进行计算后根据计算结果进行应急调控，关键在于构建预警识别模型、指令推荐模型以及应急调控体系。

其中，预警识别模型中：

系统准实时高效读取实时数据库中的运营指标数据；

综合从生产数据库获取的相关数据以及天气状况、舆情事件等信息；

运用智能预警算法，结合上述数据进行行为及规则匹配分析；

发现预警后，读取预警方式配置，通过大屏切画面，系统闪烁弹窗、悬浮滚动、发声及电话短信等方式多渠道实时通知相关岗位人员；

通过持续的预警识别确认，根据确认结果，持续完善预警模型。

而指令推荐模型中，指令推荐模型的建立为指令的生成提供了信息化的辅助决策手段；模型可根据选取结果及调控有效性的趋势分析结果不断优化。

应急调控体系中，则根据预警识别模型识别预警及发出预警通知；预警确认后，根据预警时业务运行情况，综合各类指标数据，智能化推荐指令；指令通过系统下达到下级接收人，系统根据接收人执行情况自动记录接收情况及指令的执行情况；指令下达人可实时监测多次下达指令的执行情况；预警识别模型后台实时判断是否满足解除预警的条件，满足时，给出提示，是否解除预警；预警整个生命周期都会归档未调控日志，方便事后的追溯。

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

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

Claims (9)

1.一种分布式调控服务系统，其特征在于，包括：

接口服务器集群，包括至少两台接口服务器，用于获取客服终端的指标数据；

分布式计算服务器集群，包括至少两台计算服务器，用于对所述指标数据进行计算，获得计算结果；

应用服务器集群，包括至少两台应用服务器，用于接收对所述指标数据及所述计算结果的访问请求，并返回访问结果；

数据库集群，包括至少两台数据库服务器，用于将所述指标数据提供给所述分布式计算服务器集群进行高速访问；

其中，所述接口服务器集群、所述分布式计算服务器集群、所述应用服务器集群及所述数据库集群通过网络相连接。

2.根据权利要求1所述的系统，其特征在于，还包括：

负载均衡服务器，分别与所述系统中的每个集群相连接，用于对每个所述集群进行负载均衡。

3.根据权利要求1或2所述的系统，其特征在于，还包括：

历史服务器集群，与所述接口服务器集群相连接，包括至少两台历史服务器，用于存储历史的指标数据。

4.根据权利要求1或2所述的系统，其特征在于，还包括：

防火墙服务器，连接在所述客服终端及所述接口服务器集群之间，用于为所述接口服务器集群提供安全策略。

5.根据权利要求1或2所述的系统，其特征在于，还包括：

报警器，与所述分布式计算服务器集群相连接，用于基于所述计算结果生成报警信息。

6.根据权利要求5所述的系统，其特征在于，所述报警器包括：声音播放器。

7.根据权利要求5所述的系统，其特征在于，所述报警器包括：显示器。

8.根据权利要求5所述的系统，其特征在于，所述报警器包括：通信组件，所述通信组件用于基于所述计算结果将所述报警信息发送给通信终端。

9.根据权利要求1或2所述的系统，其特征在于，所述数据库服务器为实时数据库。

Images