CN110502641A - 一种实现数据中心监控系统的知识建模方法 - Google Patents

Abstract

本发明公开了一种实现数据中心监控系统的知识建模方法，包括：从不同层次对数据中心运维监控系统进行战略建模、战术建模和业务最小集集成；所述战略建模包括领域业务语言的确立、领域和子域的划分、业务最小集的划分与最小集映射图的绘制；所述战术建模包括领域聚合、领域服务和领域事件的创建；所述业务最小集集成包括最小集通信机制的确定和系统总体架构图的设计；从而构建出完整的领域知识模型。本知识建模方法使得领域对象封装了数据和行为，通过知识、抽象、分治能够有效地解决数据中心运维监控这种场景下的大规模复杂应用的模型构建问题。

Description

一种实现数据中心监控系统的知识建模方法

技术领域

本发明涉及数据中心监控技术领域，具体涉及一种实现数据中心监控系统的知识建模方法。

背景技术

运维监控是数据中心非常重要的一项工作，是信息系统服务有关各项管理工作的总称。为了有效提供符合要求的信息系统服务，需要对各项监控管理对象进行系统的规划、组织、协调与控制。这些对象可分为三大类，机房动力环境基础设施部分(动环)、IT服务资源设施部分(网管)、人员与平台管理部分(用户管理)。为了高效、经济、稳定地服务于数据中心的运维工作，运维监控软件平台不可或缺。

在传统的运维监控软件开发方式中，针对Web应用使用分层架构是解决企业级软件产品研发的主要方案。基于这种方案，建模通常围绕着数据库展开，并以数据库ER设计作驱动，随后形成相应的分层架构，而整体的系统架构自然就由这种分层的技术架构所决定。搭建这种分层架构的过程，其实就是针对数据的移动、处理和实现，所以当设计开发人员习惯了J2EE平台的开发模式(例如基于控制层/业务层/持久层的分层模式)以后，会很自然地写出过程式(结构化)的代码，导致出现系统偏离需求、过分依赖数据库等弊病，而且面向对象编程的相关理论和优势也难以运用与呈现。

而以领域知识为核心的领域驱动设计方法，首要考虑的是业务语言而不是数据，能够较好地传达领域专家的思维模式并予以实现，是目前解决复杂中大型软件的一套行之有效的方法。通过建立一个反映领域知识的模型，并使用大量模式指导模型的设计与开发，实现将业务架构映射到系统架构的领域驱动设计思想，可以更好地处理运维监控领域相关具有较高复杂度的业务。

不过，国内对类似方法了解的技术人员不多。这是由于软件的需求通常跟随用户，业务往往非常复杂，不同领域的知识体系相差很大，而领域驱动设计方法自身却具有一定的开放性，导致没有一种简单而标准的分析方法能够有效落地到实际的项目中，所以开发团队需要在前期投入较多的时间和精力去考虑如何建模，如果缺乏相关专家的指导，那么业务模型就难以确定。

发明内容

针对本领域存在的不足之处，本发明提供了一种实现数据中心监控系统的知识建模方法，能够有效解决传统Web的分层架构中过分依赖数据库建模，进而造成技术架构决定系统架构，开发人员难以轻易、安全地跟随需求更改和拓展软件产品的问题。通过将生产环境中运维监控的领域语言转换成领域的知识，划分问题空间与解决方案空间，进而在领域专家、产品人员、技术人员的多方参与下转换为软件系统中的类型以及类型的属性与行为，最后完成该领域的知识建模。

一种实现数据中心监控系统的知识建模方法，包括：从不同层次对数据中心运维监控系统进行战略建模、战术建模和业务最小集集成；

所述战略建模包括领域业务语言的确立、领域和子域的划分、业务最小集的划分与最小集映射图的绘制；

所述战术建模包括领域聚合、领域服务和领域事件的创建；

所述业务最小集集成包括业务最小集通信机制的确定和系统总体架构图的设计。

本发明提出的实现数据中心监控系统的知识建模方法，以领域驱动为核心，有助于解决传统建模方法所存在的问题，并可以应用于其他不同领域。

所述战略建模具体包括步骤：

(1-1)进行业务分析，与运维监控领域专家沟通，在产品人员的协同下建立通用的业务语言，明确业务的知识体系与核心诉求，从而发现要在模型中使用的主要的领域概念。

(1-2)划分领域和子域，明确领域边界。

(1-3)分析可显示限定边界的特定职责，划分业务最小集。

(1-4)绘制最小集映射图，实现业务最小集之间的集成关系。

所述战略建模侧重于从高层次、宏观上去划分和业务最小集。

步骤(1-1)中，所述领域业务语言是数据中心运维领域专家将领域知识传递给开发者、产品人员的交流方式，具体表现为业务生命周期描述和概念术语的同步。

领域业务语言可以作为一种便于领域专家、设计人员、开发人员理解的语言和相互交流的工具，当用之于团队进行共享知识和推敲模型时可以有效消除沟通障碍、保持一致的表达方式，并有利于团队在交流的过程中发现领域概念。例如，把机房动力环境基础设施简称动环，把IT服务资源设施简称网管，把人员与平台管理简称用户管理，并用IDC代称数据中心，此外，还包括协议解析、采集轮询、告警分发等活动术语。

步骤(1-2)划分领域和子域，不带任何技术考量，从去用户中心化的角度出发，对上述步骤(1-1)的业务知识进行抽象，挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律。作为优选，通过业务的抽象将领域划分为监控子域、资源采集子域、用户管理子域和安全风控子域，然后通过递归在各子域内继续进行划分，最终得到完整的领域分解。

步骤(1-3)的划分根据步骤(1-1)中产生的领域业务语言，从运维监控知识体系中提取出术语作为概念对象，寻找它们之间的联系，其中从本领域知识体系中可提取的概念有：预采集信息、动环采集管理、网管采集管理、采集日志、健康度、采集命令、动环预轮询信息、局站、房间、设备、动环告警、实时信号、主机凭据等。或者，从需求中提取出不同的词性，观察它们之间的关系，在有一定的区分之后，将紧耦合的概念对象圈在一起，观察它们的内在联系，形成对应的业务最小集。

步骤(1-4)中的最小集映射图应考虑团队的组织结构与沟通结构，对于业务最小集之间发生的交互，团队应该与其保持一致性，具体表征为能够保证明确对接的团队和依赖的上下游。

所述战术建模具体包括步骤：

(2-1)对业务最小集中的领域模型分解成数据字典和行为模式，把具有系列个性特征且身份唯一的数据与行为集成在一起形成实体。

(2-2)对步骤(2-1)中不具备身份唯一特征且可变的领域概念集成在一起形成值对象。

(2-3)将步骤(2-1)、(2-2)在一致性边界之内产生的实体与值对象组合形成领域聚合。

(2-4)将步骤(2-1)中的无法归类在实体中完成的逻辑处理与行为划分为领域服务。

(2-5)将步骤(2-1)、(2-4)中所发生的活动根据运维业务的实际需要进行建模，对活动建立的模型形成领域事件。

(2-6)对步骤(1-3)中划分的业务，结合以上步骤进行领域知识建模，通过领域聚合控制行为。

所述战术建模关注的是业务最小集内部的组织关系。所述业务最小集是一个显式的边界，领域模型存在于该边界内，业务最小集是充满语义的，领域模型准确反映领域业务语言。业务最小集在工程中往往对应一个模块或者组件、项目，在理想的状态下，业务最小集与各自的所对应的子领域形成一对一的关系，在实际的复杂业务中由于业务交互的原因可能存在一定的最小集与子领域交叉的现象。

步骤(2-1)的实体与计算机面向对象编程语言中对象的关系是当一个对象由其标识(而不是属性)区分时，该对象称为实体。除了同计算机面向对象编程语言中对象一样含有的属性外，所述实体还包含行为和动作，在整个生命周期中具有连续性，以确保其行为更清楚且可预测，它所拥有的一些对用户来说有益的状态不是由属性决定的，此外应当注意的是定义一种区分每个对象的方式，这种方式应该与其形式和历史无关。

步骤(2-2)的值对象与计算机面向对象编程语言中对象的关系是当一个对象用于事物描述而没有唯一标识时，它被称之为值对象，具体定义的归类方法是判别该对象是否具有不变性、相等性和可替换性，是则为值对象。与计算机面向对象编程语言中的对象概念一样只需要关心一个模型元素的属性时，可以定义为值对象，使其能够表示出其属性的意义，并为它提供相关功能，值对象一般是不可变的，确保共享和引用传递的安全性。

步骤(2-3)的领域聚合具体定义方法为，组合步骤(2-1)、(2-2)中的相关对象，观察该组合是否可以作为一个整体被外界访问，是则可以定义为领域聚合。所述领域聚合中处在根节点位置的实体定义为聚合根。所述领域聚合是一个组合概念，作为一个整体被外界访问，包含在一致性边界之内产生的实体与值对象。

步骤(2-4)中领域服务定义方法为，若一个操作不属于实体或值对象，则该操作的逻辑形成领域服务，具体表征为：

(a)执行一个显著的业务操作过程；

(b)对领域对象进行转换；

(c)以多个领域对象作为输入进行计算，结果产生一个值对象。

领域服务表示一个无状态的操作，它用于实现特定于某个领域的任务，当某个操作不属于领域聚合时，便产生领域服务，与传统控制层/业务层/持久层分层架构中的服务相比，领域服务更加具有抽象意义。

步骤(2-5)中领域事件是本领域知识体系中关于系列活动的建模，具体界定方法为根据步骤(1-1)中领域业务语言描述的语句，尤其是业务生命周期中出现的时序性描述，如“当…”、“如果发生…”、“当…通知…”等活动可以构成一个事件。领域事件是对各种活动行为本身的建模，用来捕获发生的领域中的事件，建模行为是一种带有逻辑性的表征，这与传统软件中的事件有所区别

步骤(2-6)的具体流程为对步骤(1-2)划分的各子域中的业务最小集分别建模，模型包含各领域概念，领域聚合控制一组相关对象，建模中表达不同对象之间关联，也表达当前最小集对上下游最小集的一些映射。

所述业务最小集集成具体包括步骤：

(3-1)业务最小集通信机制的确定：根据最小集映射图中所映射的业务模块关系分析最小集间的依赖，设计最小集集成方式，即根据步骤(1-4)中所映射的最小集依赖关系分析最小集间的通信需求，设计最小集集成方式。

(3-2)根据以上步骤绘制系统总体架构图。

步骤(3-1)中，所述最小集集成方式在本领域中具体表现为开放HTTP服务和开放领域服务接口，以及各最小集之间的交互拓扑。

步骤(3-2)中，所述系统总体架构图是基于领域驱动设计理论在本领域下的技术架构模型。

所述系统总体架构图中的系统架构包括用户接入层、应用服务层、核心领域层、基础设施层；

所述用户接入层负责暴露服务接口，向用户显示信息和解释用户指令；

所述应用服务层定义了应用将要完成的任务，并指挥表达领域概念的相关聚合来解决领域问题；

所述核心领域层负责表达业务概念，业务状态信息以及业务规则；

所述基础设施层负责为其它各层提供通用的技术能力，包括仓储服务和数据通信服务。

本发明与现有技术相比，主要优点包括：基于领域驱动设计理论对数据中心运维监控做了知识建模，有效地消除了在传统Web开发中以数据库ER为核心驱动、技术架构优先而造成的业务与架构不匹配、面向对象编程理论难以运用、重构困难等弊病。本发明通过知识体系建模将数据和行为封装在一起，将业务架构映射到系统架构，以抽象、分治与知识的方法高效的解决了复杂和大规模软件系统的设计问题。同时本发明是领域驱动设计理论的生产实践，有助于推动该方法在不同领域的应用和推广。

附图说明

图1为实施例的运维监控领域划分图；

图2为实施例的资源采集领域业务最小集划分图；

图3为实施例的业务最小集之间的映射关系图；

图4为实施例的采集最小集建模图；

图5为实施例的动环轮询最小集建模图；

图6为实施例的网管轮询最小集建模图；

图7为实施例的概念语言流程图；

图8为实施例的系统技术架构图。

具体实施方式

下面结合附图及具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。下列实施例中未注明具体条件的操作方法，通常按照常规条件，或按照软件开发所建议的条件。

本行业技术人员应理解，除非特意声明，以下所提“领域”均代表当前语义中的问题空间，而非代表广义上的行业概念。进一步可以理解的是，以下所提“某领域”代表具体的某个领域而非限定在当前语义。应明确，本实施例选择资源采集子领域为主要建模案例，详细阐述如何基于领域驱动设计建立知识模型，建模方法不用于限制在资源采集领域的范围。

本实施例的实现数据中心监控系统的知识建模方法的语言流程如图7所示,系统整体架构如图8所示。可阐述项包括：

(1)数据中心运维监控整体作为一个问题空间，并寻求该领域的专家帮助理解业务本身，需要在使用上述的通用业务语言来了解核心业务挖掘业务价值，消除领域专家与技术人员之间的关于概念和术语的歧义。所述问题空间具体概述为数据中心运维监控业务是通过不间断实时采集IT资源数据和机房动力环境基础设施部分数据来提供监控数据查看、告警分发、报表统计等功能、软件平台还提供如用户和风控权限等管理业务。所述领域业务语言具体定义为机房动力环境基础设施简称动环，IT服务资源设施简称网管，人员与平台管理简称用户管理，数据中心代称IDC，部分活动术语具体包括协议解析、采集轮询、告警分发等。

(2)如图1所示，领域划分具体概述为监控子域、资源采集子域、用户管理子域、安全风控子域，针对各子领域可进一步重复划分的方法再形成子域，本子领域选取资源采集领域为建模对象，下文不再赘述，如图2所示，资源采集领域根据划分原则可进一步划分为采集子域、动环轮询子域、网管轮询子域、计数子域，其中采集子域为核心域，动环和网管轮询子域为支撑域，计数子域为通用域。

(3)从各子领域中提取出相关术语为概念对象，寻求他们之间的联系，从本领域知识体系中可提取的概念包括：预采集信息、动环采集管理、网管采集管理、采集日志、健康度、采集命令，动环预轮询信息、局站、房间、设备、动环告警、实时信号、主机凭据等，以上所述概念根据业务上的集成关系，可将紧密耦合的领域概念圈在一起形成一个业务最小集，具体定义为采集最小集、动环轮询最小集、网管轮询最小集、计数最小集。

(4)如图3所示，根据上述创建好的业务最小集绘制最小集间的映射图，考虑各最小集之间的映射关系，具体映射为：采集最小集与网管轮询最小集、动环轮询最小集互为合作关系；采集最小集与计数最小集为合作关系，反之为遵奉者关系；外部鉴权最小集与采集最小集为开放主机服务关系，反之为防腐层关系；上述映射关系皆为后者作为上游，前者为下游。

(5)在业务最小集中分解出数据字典和行为模式，根据身份是否唯一及可变等特性划分实体和值对象。具体划分如下：

采集最小集内部模型如图4，其中，Gather(采集)，聚合根；GtStatus(采集状态)，值对象；HostAuthenticate(采集主机认证信息)，值对象；GatherContext(采集信息最小集)，值对象；GatherLog(采集日志)，实体；NetworkManagement(网管)，聚合根；PowerEnvironment(动环)，聚合根；Health(健康度)，值对象；Command(指令)，值对象；采集Schema，仓储；

动环轮询最小集内部模型如图5，其中，PowerEnvironmentPoll(动环轮询)，聚合根；HostAuthentication(主机授权)，值对象；PEDominate(动环调度)，值对象；PowerEnvironmentContext(动环信息最小集)，值对象；Station(局站)，实体；Room(房间)，实体；Device(设备)，实体；RealTime(实时信号)，实体；PowerAlarm(动环告警)，实体；Unit(单位)，值对象；Signal(信号)，值对象；动环轮询Schema，仓储；

网管轮询最小集内部模型如图6，其中，NetworkManagementPoll(网管轮询)，聚合根；HostCredential(主机凭据)，值对象；NMDominate(网管调度)，值对象；NetWorkManagementContext(网管信息最小集)，值对象；Resource(资源)，实体；Performance(性能)，实体；Alarm(告警)，实体；Application(应用)，实体；网管轮询Schema，仓储；

(6)上述步骤中，实体和值对象共同形成聚合，具体归类为：采集聚合，资源数据采集的主要领域聚合，用于接收管理员调度、发布采集命令等；网管聚合，IT资源数据采集子领域聚合，用于网管采集主机的轮询、数据处理；动环聚合，机房动力环境基础设施数据采集子领域聚合，用于动环采集主机的轮询、数据处理。

不属于实体或值对象的概念创建为领域服务，对活动建模创建为领域事件，如图4、5、6，具体定义为：InitializeDatabase(初始化数据库)，领域服务；GatherLogService(采集日志服务)，领域服务；GtStatusChangeEvent(采集状态变化事件)，领域事件；RootSourceModifyEvent(资源变更事件)，领域事件；

(7)综上所述，通过聚合控制行为，进行知识领域建模，具体各领域最小集建模如图4、5、6。

(8)系统的集成方式考虑复杂软件的持续集成与交付，本实施例采用开放HTTP服务和开放领域服务接口，如计数最小集，对资源采集领域的几个子域提供了通用的访问接口，而还可以理解的是，监控子领域获取数据将通过采集子领域提供的HTTP服务进行通信。

(9)以上所述领域概念的语言导航图如图7，领域通过实体、值对象和服务来表达模型，通过分层架构来隔离不同领域，通过聚合来维护实体的完整性，同时值对象参与聚合完善实体功能，仓储作为各领域的基础支持，而工厂用来封装产生一个实体。

(10)各领域最小集之间集成后构成整个系统架构的领域层，整个系统的架构如图8，具体包含用户接入层、应用服务层、领域层、基础设施层。用户接入层负责向用户显示信息和解释用户指令；应用服务层定义软件要完成的任务，并指挥表达领域概念的对象来解决问题；核心领域层负责表达业务概念，业务状态信息以及业务规则；基础设施层负责为上面各层提供通用的技术能力。

本发明的实现数据中心运维监控系统的知识建模方法，其中包括战略建模、战术建模、最小集集成等步骤。战略建模从高层次、宏观上完成领域业务语言的确立，并把领域划分为监控核心子域、资源采集子域、用户管理子域、安全风控子域，然后对各子领域划分业务最小集与绘制最小集映射图；战术建模从各子领域中提取出概念对象，完成领域聚合(实体和值对象的组合)、领域服务和领域事件的创建，形成最小集模型；最小集集成阶段完成通信机制的确定和系统总体架构的设计(包括用户接入层、应用服务层、核心领域层、基础设施层)，据此构建出完整的领域知识模型。本知识建模方法使得领域对象封装了数据和行为，通过知识、抽象、分治能够有效地解决数据中心运维监控这种场景下的大规模复杂应用的模型构建问题。

此外应理解，在阅读了本发明的上述描述内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。

Claims (9)

1.一种实现数据中心监控系统的知识建模方法，其特征在于，包括：从不同层次对数据中心运维监控系统进行战略建模、战术建模和业务最小集集成；

所述战略建模包括领域业务语言的确立、领域和子域的划分、业务最小集的划分与最小集映射图的绘制；

所述战术建模包括领域聚合、领域服务和领域事件的创建；

所述业务最小集集成包括业务最小集通信机制的确定和系统总体架构图的设计。

2.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述战略建模中，通过业务的抽象将领域划分为监控子域、资源采集子域、用户管理子域和安全风控子域，然后通过递归在各子域内继续进行划分，最终得到完整的领域分解。

3.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述业务最小集通信机制的确定具体为：根据最小集映射图中所映射的业务模块关系分析最小集间的依赖，设计最小集集成方式；

所述最小集集成方式具体表现为开放HTTP服务和开放领域服务接口，以及各最小集之间的交互拓扑。

4.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述业务最小集是一个显式的边界，领域模型存在于该边界内，业务最小集是充满语义的，领域模型准确反映领域业务语言。

5.根据权利要求4所述的实现数据中心监控系统的知识建模方法，其特征在于，对业务最小集中的领域模型分解成数据字典和行为模式，将具有系列个性特征且身份唯一的数据与行为集成在一起形成实体，将不具备身份唯一特征且可变的领域概念集成在一起形成值对象；

所述领域聚合作为一个整体被外界访问，包含在一致性边界之内产生的实体与值对象。

6.根据权利要求5所述的实现数据中心监控系统的知识建模方法，其特征在于，除了同计算机面向对象编程语言中对象一样含有的属性外，所述实体还包含行为和动作，在整个生命周期中具有连续性。

7.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述领域服务表示一个无状态的操作，用于实现特定于某个领域的任务，当某个操作不属于领域聚合时，便产生领域服务。

8.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述领域事件是对各种活动行为本身的建模，用来捕获发生的领域中的事件。

9.根据权利要求1所述的实现数据中心监控系统的知识建模方法，其特征在于，所述系统总体架构图中的系统架构包括用户接入层、应用服务层、核心领域层、基础设施层；

所述用户接入层负责暴露服务接口，向用户显示信息和解释用户指令；

所述应用服务层定义了应用将要完成的任务，并指挥表达领域概念的相关聚合来解决领域问题；

所述核心领域层负责表达业务概念，业务状态信息以及业务规则；

所述基础设施层负责为其它各层提供通用的技术能力，包括仓储服务和数据通信服务。