智慧企业运行管理平台总体规划设计

智慧企业运行管理平台总体规划设计

目录

1需求概述 (4)

1.1项目建设背景 (4)

1.2项目建设目标 (4)

2方案总体规划 (6)

2.1平台总体建设规划 (6)

2.2平台总体功能架构 (7)

2.3平台分期建设规划 (8)

2.4平台关键技术路线 (9)

2.4.1高性能分布式采集架构 (9)

2.4.2高可靠集群部署架构 (10)

2.4.3高吞吐数据存储引擎 (11)

2.4.4端对端应用全面监视 (12)

2.4.5自动化运维操作控制 (12)

2.4.6智能化运维预案响应 (13)

2.4.7全景化指挥调度展示 (13)

2.4.8灵活自定义展示设计 (14)

2.5非功能性设计方案 (14)

2.5.1系统性能设计 (14)

2.5.2可扩展性设计 (18)

2.5.3开放性设计 (20)

2.5.4易用性设计 (21)

2.5.5安全性设计 (21)

1需求概述

1.1项目建设背景

XX公司联合所属单位共同出资成立的高科技互联网企业，以“信息互通、资源共享、能力协同、开放合作、互利共赢”为核心理念，以“互联网+智能制造”为发展方向，以提供覆盖产业链全过程和全要素的生产性服务为主线，以技术创新、商业模式创新和管理创新为重要战略举措，依托集团雄厚的科技创新和制造资源，开放整合社会资源，构建以“制造与服务相结合、线上与线下相结合、创新与创业相结合”为特征，适应互联网经济业态与新型工业体系的云生态系统。

随着云数据中心业务的发展，IT规模激剧扩展，云网面临的运维压力，因此迫切需要一套一体化、自动化的运维管理平台来支持云数据中心的运行保障工作，提升运维管理效率、降低运维管理风险。

1.2项目建设目标

通过运维管理平台的建设，能够让用户在网络、业务系统的运行监控管理的基础上，实现统一运行维护工作，最终达到如下目标：

一、梳理资产配置，构建精确、统一的资产配置管理库

构建符合实际管理需求的资产配置模型，对资产配置信息进行梳理，实现资产配置的全生命周期管理，并实现资产配置的可视化展现。

二、强化主动监控，构建内控体系，实现集中管理

通过部署集中监控系统，实现网络、IT资源、业务应用的集中监控和统一操作，主动、

及时地发现问题，解决被动救火的局面。

三、建设自动化能力，提高运维效率，降低操作风险

参照互联网成功经验，建立自动化操作平台，实现对应用软件安装、系统巡检、合规检查、故障自愈等运维操作的自动化，提升运维效率、降低人工操作风险，同时为下一步走向智能化运维打下基础。

四、规范运行流程管理，促进有序高效协作

参照ITIL 规范，对运维管理工作进行优化，对服务管理进行改善，根据相关制度进行，对内完善流程，使运维人员具备更高的工作效率；同时把运维过程中产生的丰富经验进行积累和总结，形成有效的知识库，建立知识的共享机制。

五、全方位数据展现，实现统计分析和决策支持

通过提供各类性能分析报表、资源统计报表和运维分析报表，从各个侧面、各个角度反映系统的运行情况、性能情况和人员工作情况，为系统升级、改造、扩容提供科学依据；也为员工的绩效考核提供电子依据。

2方案总体规划

2.1平台总体建设规划

信息化建设是一个持续过程，业务、技术、管理都在持续发展，这些都要求运维工作也必须是一个持续建设、持续改进的过程，运维项目的建设不能着眼于当前的管理需求，还要充分考虑未来3~5年的发展规划，从而确保项目建设成果具备一定的扩展性和延伸性，能够满足或通过升级、扩展的方式逐步满足未来对运维工作的要求。

根据本项目建设需求，运维管理平台的建设也遵循分阶段、分步的建设策略，逐步完成运维平台“一体化、自动化、智能化”三个阶段的建设目标。

附图1. 运维平台三步走建设策略

我方建议综合运维平台的分阶段建设目标如下：

1)一期：平台搭建，建立一体化运维管理平台

建设一体化运维管理平台，实现基础设施全面监控，针对关键应用系统应用性能监控、用户体验监控、集中告警管理及集中监控展示等监控管理能力，同时构建配置管理库（CMDB）构建资产运维管理档案库，建立运维服务流程，实现运维工作规范化管理。

2)二期：优化完善，提升运维自动化与对外服务交付能力

建立运维自动化基础能力，实现环境准备自动化、应用安装自动化、巡检自动化等，提升运维效率、降低运维操作风险。全面覆盖同时深化CMDB与运维流程建设，提供对外服务交付能力。完善运维服务流程，实现资源自动化交付，提升对外服务交付能力。

3)三期：深化应用、持续提升，建立运维智能化控制及分析能力

基于二期建设成果，并应用深度监控与运维自动化能力，强化运维智能化分析与控制能力，提升故障分析与处置能力。

2.2平台总体功能架构

智慧企业运行管理平台（以下简称运行管理平台）是支撑一体化、自动化、智能化运维管理的技术平台，基于统一运维技术标准和管理规范构建，由信息采集层、信息分析处理层、综合业务功能层、业务用户层组成，具备面向业务的监控管理、操作管理、配置管理、服务管理、度量管理和运维门户等功能，支撑综合监视、运维控制、运维服务三大业务需求。

附图2. 运行管理平台技术架构

平台按分层架进行设计，包括：

1.业务用户层：对多种运维用户角色提供综合监视、集中告警、运维控制和运营服务

能力。

2.综合业务功能层：通过监控管理、操作管理、配置管理、流程管理、度量管理、运

维门户六大功能模块支撑业务目标

3.信息分析处理层：通过开放接口汇聚，实现信息汇聚、信息分析与处理、信息分析，

结合云计算大数据技术来分析处理存储。

4.信息采集层：对数据中心各类资源（动力环境网络系统、设备存储、虚拟化资源、

系统资源、业务系统、应用体验等）直接采集或通过现有系统集成监控。

2.3平台分期建设规划

根据平台总体建设规划，运维管理平台的建设遵循分阶段、分步的建设策略，逐步完成运维平台“一体化、自动化、智能化”三个阶段的建设目标。各阶段具体建设划分如下：

其中：黄色区块为一期项目建设内容，绿色区块为二期项目建设内容，蓝色区域为三期项目建设内容。

2.4平台关键技术路线

2.4.1高性能分布式采集架构

在大规模监控环境中，数据最终会上报到监控服务端，但如果直接上报到服务器端，会导致服务端连接压力过大、数据无法及时处理的情况，所以应采用分布式汇聚技术，根据压力分摊原则，在服务端与Agent、Probe之间，按需增加汇聚代理（以下称为Proxy），如下图如示：

附图3. 分布式采集汇聚示意图

通过汇聚代理Proxy，可以获得以下优势：

1.分散服务端处理压力，利用Proxy主机计算能力分担，做一些数据转译预处

理处理；

2.分布式采集汇聚，允许Agent、Probe通过Proxy间接上报数据连接，适用

于数据中心异地采集、复杂网络安全环境采集等情况。

2.4.2高可靠集群部署架构

系统部署架构设计时充分考虑了可扩展性，可以根据管理资源规模的增长横向进行扩展，包括：

1）在系统服务端架构，按微服务架构设计，所有的业务服务进程设计为无状态服务，可以不断水平扩展增加计算分析能力。

附图4. 服务端水平扩展部署

2）针对存储方面有状态类服务，则按存储类型的特点，设计多种不同的扩展结构：关系型数据库实现业务分库与主从读写分离、NoSQL数据库则通过架构本身的数据水库与冗余，实现水平扩展。

附图5. 服务端数据库水平扩展部署

2.4.3高吞吐数据存储引擎

在指标阈值分析时，以及用户界面的仪表盘操作时，都需要高频的访问最近24小时等

热点数据。为了避免不必要的数据库IO与网络请求，本系统引入Redis内存缓存，对一些热点数据进行内存数据存储，实现高效的数据查询服务。通过这种方式，将数据访问的50ms 周期下降到5ms以下，在高并发的情况下，能大幅度减少数据库压力，提高数据处理时效性。

2.4.4端对端应用全面监视

基于网络的数据侦听监测是唯一一种对生产系统“零”影响的应用系统性能监控方案，收到了数据中心应用性能监测（APM）领域的青睐，但设计过程中主要将面临以下挑战：

1)需要在业务流经的环节网络布点，如何实现大流量下的7层业务协议获取，

将是一个挑战；

2)如何实现全样本实时监控，如何实现分钟甚至秒级的实时展现与告警；

3)以XML业务数据协议为例，不同开发商应用层协议会存在较大差异，如何实

现快速的协议层数据提取。

设计时采用了以下技术来满足上述高性能、全样本、灵活性的挑战。

2.4.5自动化运维操作控制

自动化运维的核心关键是任务调度引擎，引擎的设计需要解决以下问题：

1)满足大规模、多组合网络环境的业务应用集中管理；

2)支持环境准备、应用软件安装、补丁升级、自动化巡检、合规检查、远程控制、故

障自愈等自动化运维场景。

3)可以根据运维场景的要求编排任务调度流程, 确保任务调度的实时性和顺序性；

4)操作能力要易于扩展，可根据不同运维场景和人员技能储备使用相应的脚本语言实

现运维操作。

5)提供多种任务调度触发方式，可以定时、手工、事件或异常条件触发。

自动化任务调度引擎在设计时就定位在大型互联网应用和大型数据中心的运维环境，针对以上问题都已经进行了充分的考虑和设计。

2.4.6智能化运维预案响应

自动化运维工具除了能够实现各项任务的自动操作外，还需要能够结合场景实现智能化的预案处理，能够按照预先设定好的预案实现对各项事务的相应，系统设计时考虑到多运维工具组合使用的场景，引擎内置定时调度器、人工交互执行界面和开放简洁的API，支持多种触发方式。

智能化运维预案响应包括：应用服务自动化恢复、集群组件弹性伸缩、应用主备切换、表空间自动扩展等。

2.4.7全景化指挥调度展示

基于全网系统的全面实施，系统形成了监控管理、配置管理、自动化管理、运维服务等多个主题数据，基于这些数据可以实现全面的运维量化分析，并能够建立一系列的可视化展示视图，为运行值勤保障、指挥调度分析、运行态势分析提供数据支撑，提升运维质量与决策水平。

2.4.8灵活自定义展示设计

以监控数据库、资源设备资源管理库以及其他多源数据库为数据源，对运行展现数据进行可视化的视图设计和展现，能够实现各类设备、网络、应用、机房等视图设计，为运维管理员提供了灵动在线可视化建模设计器。

通过可视化视图定义能够帮助用户全方位地了解IT基础资源的运行情况，涵盖了网络、服务器、业务应用、机房环境等IT资源的连通性、健康性、可用性等指标，并且以直观的圆饼图加以显示。

2.5非功能性设计方案

2.5.1系统性能设计

平台将利用当前先进的软硬件技术、数据库系统技术，提供较高的实时性能、处理性能、存储效率、用户并发访问能力。系统着力于占用较少的资源和网络带宽，不影响对目标源的正常运行干扰，确保所建平台对用户各种操作的响应时间在合理的时间范围内。具体来说，本项目采取以下性能设计方案。

2.5.1.1并发访问性能设计

系统设计将根据系统业务量、数据量的要求和估算结果，采用并发处理机制、多级存储机制，有效保证系统访问的并发性有效满足项目建设要求和实际业务需要。

（一）并发处理机制

系统采用多线程、多任务并发处理和执行机制，通过服务请求缓存队列，有效管理系统访问的用户总量、并发响应规模。系统从表示层、应用逻辑层、数据层提供了相应的并发容

量、并发响应的处理机制和逻辑组件。

（二）并发扩展能力

当用户的并发访问量扩展、数据收集广度精度扩展时，系统的模块提供了水平扩展能力。在表示层可通过虚拟IP技术、负载均衡设备、Nginx反向代理技术，实现WEB层面的并发扩展；在业务层主要通过无状态业务处理，通过基础模块（缓存服务、消息总线、认证服务）本身来保持状态共享，通过无状态可以便捷的水平复制，提高业务层面的并发能力；在数据层通过数据库的集群、数据的读写实时复制技术大大提供读并发的能力，并在关键数据写入中采用大数据NO-SQL的技术，提高写入的并发能力。

（二）并发性能指标

通常情况下，系统可以达到的并发性能指标如下：

1)平台可以满足1000个用户同时在线，可以通过优化软件、扩容硬件进一步提高

在线用户；

2)平台可以满足500个用户同时并发，即对同一功能调用，可以满足200个用户来

同时提交事务，并可通过优化软件、扩容硬件进一步提高；

3)服务端单节点接入需保证3000个指标/秒的吞吐量，以支持1000个以上服务器

或虚机；

4)服务端接入可实现水平扩展，通过多种负载均衡措施，充分利用集群扩展能力，

让接入吞吐量不断增加，以满足监控规模的不断扩展。

2.5.1.2响应时间性能设计

从用户体验的角度，需要在系统功能页面的打开、显示、常规操作的响应时间控制在较

短的时间范围以内。而对于大批量数据处理与检索、统计分析数据转换、数据汇总报表生成等复杂处理，需要将系统响应时间控制在合理的范围内。

为了保障面向用户的响应时间，我们通过表示层、应用层、数据层三层来保障系统响应时间，以满足项目建设要求和实际业务需要。

（一）表示层响应设计

在表示层通过Struts、Portlet 等封装框架的方式，结合前端MVC、Ajax、Flex、HTML5等技术简化复杂逻辑，提高异步响应处理，并通过对页面动作的数据表示、迁移控制、处理流程的合理安排，获从获得快速的表示层响应处理效果。

（二）业务层响应设计

通过统一封装业务逻辑构件、分布式缓存、消息异步处理等方式，将系统的并发用户数、资源利用率等性能指标控制在合理的范围内，从而提高业务数据提取逻辑的响应速度。

在应用逻辑层对特定的业务应用逻辑，按照业务主题进行逻辑部件规划，采用SOA的体系设计，从服务代理、服务定位、服务处理的层次设计响应处理逻辑，容易进行水平扩展，来保障更好的并发性能。

（二）数据层响应设计

采用多种数据存储的设计，提供临时性的缓存持久化、关系型数据库、NO-SQL数据库的搭配，采用一定的反范式设计，优化数据存取性能，通过适当的索引、固化视图、存储过程，优化数据取逻辑，提高数据访问响应性能。

对于分析型的数据，采用ETL实现数据导入到数据仓库中，数据仓库采用星型主题模

型，实现对分析型数据的进一步加工和长期保存，避免和短期事务性数据较差，导致系统性能下降。

（三）响应时间技术指标

在并发的容许范围内，通常情况下系统可以达到如下响应时间标准：

1)一般页面平均响应时间为小于3秒，配置库的平均业务响应时间小于2秒；

2)各类管理流程对配置库、知识库的相关操作响应时间小于3秒；

3)需要下载较多内容和图片的交互性页面响应时间小于5 秒钟；

4)统计类业务的页面平均响应时间小于5秒；

5)较为复杂的统计类业务页面平均响应时间小于40秒。

2.5.1.3数据处理吞吐性能设计

对数据批处理和传输性能影响较大的业务接口，在对数据的导入导出、批处理作业、流式数据处理过程中，通过设计合理的接口、通信处理逻辑、并行处理机制，可将数据内部处理、与外部系统进行数据交换的时间和吞吐能力控制在合理范围内，以满足批量快速处理和传输的要求。

（一）实时数据吞吐性能设计

对于实时数据的处理方面，系统采用了实时计算、并行处理的大数据技术，通过分布式的、容错的实时流式计算系统，对数据进行连续计算和处理，将结果以流的形式输出，主要用于性能指标、事件处理、配置发现等关键业务实时或准实时计算。

（二）批量数据吞吐性能设计

对于业务数据的批处理方面，系统主要采用ETL的处理机制，并且融入了多进程、分布式的并发模式，加快批处理的能力，实现数据的提取、转换和加载，过程中对数据进行加工、清洗，融合大数据的批处理技术进行处理，降低对传统关系型数据库的依赖。

批量数据处理主要用于对数据的归并、分析，将实时和短期数据转换和加工为存放长期数据的数据仓库。

（三）数据处理吞吐性能指标

1)监控指标库实时性能指标存储周期至少支持3个月，小时粒度数据存储周期

至少支持1年，天粒度归并数据至少支持3年, 月粒度归并数据至少支持5

年；

集中监控汇聚支持最高4000条/秒的监控指标接入能力，支持平均800条/秒的性能处理能力；

2)集中支持最高1000条/秒的告警事件峰值接入能力，支持平均100条/秒的告

警事件处理能力；

3)配置发现收集模块支持平均50个/秒配置项的收集处理能力。

2.5.2可扩展性设计

平台采用互联网微服务MicroService架构设计，具备优秀的模块开发扩展性，采用Rest风格的OpenAPI接口，是目前最流行的WebService服务接口，便于系统功能和第三方对接。同时微服务架构的另外一个优势是水平扩展性，相比传统的多层单一架构，微服务通过分层化、分布式、无状态等设计思路，确保了系统在运行部署时的弹性扩展能力。

其次，系统采用分布式架构设计，确保系统性能的平滑扩张，当被管资源增加、系统数据量扩大或访问量增大而系统当前性能不能满足要求或出现性能瓶颈时，能够通过水平扩展的方式来实现系统性能提升，从能够适应规模增加对系统的性能的压力和要求。

第三，应具备数据采集的平滑扩展，当随着信息化不断发展，被管对象或系统逐步增加时，在数据采集层能够通过配置、协议扩展或脚本扩展等方式来实现被管对象或系统的接入。

最后，应指标具体监控指标的随需增加，当被管资源增加，或者需要对某项资源进行更加详细的监控时，能够通过界面配置即可完成具体监视指标的增加。

附图6. 微服务架构可扩展性设计图

（1）服务管理节点：主要提供对整个计算机集群的管理，以及对微服务的注册和发布，控制节点本身不需要进行复杂的业务计算，可使用冗余部署方式组成控制节点集群即可。

（2）无状态节点：主要包含服务请求节点和服务计算节点，前者完成服务的预处理和再分发，后者完成复杂计算和分析，无状态节点节点本身不存储全局数据，只保留计算过程中临时数据，可以随时启停，易于水平扩展。

（3）有状态存储节点：主要用于保存全局数据，可以采用高性能内存缓存和NOSQL 数据库，这些系统本身即可组成多个局部数据集群，并根据其部署系统的特点进行相应的水平扩展。

随着业务规模和逻辑的变化趋势，微服务架构可以借助各个模块服务接口进行交互调整和扩展开发，从而为系统提供了优秀的可集成能力和开发扩展能力。

同时还支持通过配置即可实现监视指标的增加，以及接入系统的增加。

2.5.3开放性设计

系统采用Restful、WebService、Java、Python、MQ、SOA、HTML5等开放技术，底层技术以开源软件作为基础并深度优化，业务模块采用微服务设计并严格测试，形成了开放性的运维管理平台。

系统的OpenAPI接口，优先采用互联网RestfulWebService服务接口，辅助于MQ 等数据传输接口，可以有效的兼容异构系统的集成对接，从而满足系统开发性的要求，具体请参考系统集成方案章节。