华为云用户手册

资源分类管理 数据管理员根据业务主题和业务实体（分类及名称可根据需求定义），实现对数据库、大数据、Web服务、文件资源的分类管理。其主要功能包括： 业务主题管理，包括业务主题的新增，修改，删除功能； 业务实体管理，包括业务实体的新增，修改，删除功能； 业务实体资源分配和资源查看，其中资源分配要求可实现数据库、文件、接口和大数据的关联； 支持分类资源的检索； 业务实体已分配的资源，支持快速的服务发布。 图5 资源分类管理

文件资源管理 数据管理员和开发人员可以通过数据服务共享平台注册、修改、删除源区、前置区、共享区、消费方的文件资源，文件资源可以配置Agent，用以文件传输。其主要功能包括： 文件资源管理，包括文件资源的注册、修改、删除等； 文件资源注册页面自动关联信息和用户的输入校验； 文件资源与数据服务开发功能的交互； 文件传输Agent，目录授权和目录关联到Agent； 支持文件资源的检索。 图3 文件资源管理

安装与配置 创建“DSPGatherClient”目录。 解压安装包到 “DSPGatherClient”目录中。 Linux #tar -xvf Primeton_DSP_7.0_GatherClient_Linux_64.tar -C DSPGatherClient Windows 用解压工具将 “Primeton_DSP_7.0_GatherClient_Windows_64.zip” 解压至 “DSPGatherClient” 目录 将数据库驱动包复制到“DSPGatherClient\lib”目录下。 打开“DSPGatherClient\startup.conf”文件，按照如下说明配置。 DEVICEID=mydevice SERVERIP=127.0.0.1 SERVERPORT=8000 参数 说明 DEVICEID 设备ID，和服务引擎管理中注册的物理设备“名称”一致， 也就是3.4.1.1 物理设备管理中添加的物理设备的“名称”。 注册设备时名称不能为中文，否则监测不到。 SERVERIP 采集客户端连接采集服务器的IP地址，集成在DSP Governor中。 SERVERPORT 采集客户端连接采集服务器的端口号。需要与“DSPGovernor\governor\apache-tomcat-8.5.51\webapps\dsp\WEB-INF\cl asses\META-INF\_srv\config\user-config.xml ”中的采集服务器的端口号8000保持一致。 在需要进行引擎监控的服务启动脚本的“-classpath”参数前添加jvm参数DengineId和DengineType。启动脚本中参数说明如下所示。 表1 参数说明 参数 说明 DengineId 和“服务引擎管理”中注册的各个服务引擎的名称一致，也就是3.4.1.2 作业服务器、3.4.1.3 代理服务器、3.4.1.4 调度服务器、3.4.1.5 文件传输服务器、3.4.1.6 文件传输节点中的“引擎名称”。注册服务引擎名称不能为中文，否则 监测不到。 DengineType 服务引擎类型，与业务字典中DSP_DEVICE_RESOURCE_TYPE一致，各个服务器引擎类型如下表格第四列所示。

安装 将申请到的许可证“primetonlicense.xml”文件复制到对应产品组件的license存放位置，分别如下 Governor：{DSP Governor 安装目录}/governor/apache-tomcat-8.5.51/webapps/dsp/WEB-INF/classes/META-INF/_srv 后续如果替换许可请放置：(/governor/apps_config/DSP/license路径下) Server：{DSP Server安装目录}/dspserver DataRelease：{DSP DataRelease安装目录}/apache-tomcat-8.5.51/webapps/datarelease/WEB-INF/classes Agent：{DSP Agent安装目录}/dspagent 启动应用程序即可。

环境要求 表3 环境要求 项目 说明 CPU 主频2.0GHz以上 内存 8GB以上 硬盘 临时目录空间：20GB以上 安装目录空间：20GB以上 操作系统 Windows 10 CentOS 7.2 银河麒麟 4/10 数据库 MySQL 5.5.4/5.6.33/5.7.20 Oracle 11g/12.1.0.2.0/12.2.0.1 SQL Server 2016 PostgreSql 9.6 DM7/8 应用服务器 Tomcat 8.5.51 AppServer 7 浏览器 Chrome 84 Firefox 78 IE 11

申请 开发永久许可版：软件包自带，自带的License满足如下控制项条件 表2 开发永久许可版 模块 控制项 key 默认值 Governor 并发访问数 concurrency 10 Server 作业并行执行数 jobconcurrency 2 文件传输Agent登录数 agentconcurrentcy 3 DataRelease 并发访问数 serviceconcurrentcy 3 Agent 作业并行执行数 jobconcurrency 2 正式版：如果自带的License不满足实际需求，需要申请正式许可证，请联系普元销售人员，申请正式版许可证文件

标签制作-标签创建 标签制作-标签创建页面，对应的主体下面，新建目录 图1 标签创建1 填写目录名称，设置访问权限(即在对应主体有权限访问的基础下，对目录进行权限设置。 图2 标签创建2 选择新建的目录，单击标签创建，在新建标签页面 基础信息sheet页，填写标签名称，选择标签类型，单击下一步 图3 标签创建3 标签类型是从标签生成方式的维度对标签进行划分的一种类型，选择后，标签逻辑配置页面不同，可根据选择的标签类型不同，进行配置不同的标签逻辑 标签逻辑配置sheet页，根据选择的标签类型不同，进行配置不同的标签逻辑，单击下一步 图4 标签创建4 规则标签：是指通过简单规则运算而生成的标签。规则标签分为可视化和 SQL 模式两种规则标签。可视化规则标签，是直接通过拖拽的方式将某些字段拉入逻辑框中，进行基本字段的条件过滤来筛选数据；SQL 模式规则标签，是通过直接写出 SQL 语句来筛选数据。 图5 标签创建5 组合标签：是在现有的标签基础上，标签跟标签或标签跟字段或先标签跟标签然后再跟字段进行的运算，组合成新的标签 图6 标签创建6 手工标签：是指业务系统数据无法支撑标签规则运算，但具有业务应用价值，需以人为标记方式生成的标签 更新配置sheet页，选择标签的更新周期 图7 标签创建7 权重配置sheet页，可默认，单击下一步 图8 标签创建8 提交审批sheet页，当前主体配置的流程配置sheet页发布操作不需要审批时，则此处无流程，直接单击提交。标签创建成功，状态为启动状态 图9 标签创建9 父主题： 数据标签库管理操作流程

方案优势 数据标签库管理方案优势 潜在投诉风险预警，提升客户服务质量 通过分析 95598 呼叫行为数据、客户档案数据、实时数据等信息，建立潜在投诉倾向模型，输出“潜在投诉高风险”、“同一事件频繁投诉”、“倾向复电不准时投诉”等标签，依据客户标签推荐差异化服务策略，提升客户服务品质。 图10 潜在投诉风险预警 精准预测电费回收风险，缩短电费回收周期 通过分析客户信用、用电趋势、行业前景信息和突发事件，构建电费回收风险模型，并将分析成果通过标签的形式固化至普元标签产品，并依据用户风险级别标签等特征采取精准化风险防控策略，从而达到缩短电费回收周期的目的。 图11 精准预测电费回收风险 准确定位电能替代潜力客户，提高市场开拓效率 从已实现电能替代的客户的画像特征出发，通过分析企业行业类别、用电趋势、行业景气度和用电负荷等数据，构建电能替代模型，准确预估企业电能替代潜力，根据不同潜力等级客户及其特征设计相应推广策略，提高市场开拓效率。 图12 准确定位电能替代潜力客户 精细化设备管控策略，提升运维效率 根据设备名称、归属地、年龄、资产价值、运行状态等特征属性以及缺陷敏感度、负载强度、事故风险等业务表现特征，构建多层次、多维度、多视角的设备标签体系，形成全景设备画像。并在标签设计的应用环节，充分考虑了采集异常生成、远程处理、派工、现场处理和运维反馈全流程环节，并结合每个流程业务的特点，将特定的标签应用于相应流程进行计算分析。同时基于产品策略配置能力，通过作业项目、作业周期、作业优先级、标签反馈等类型策略内容配置，支撑一线运维人员通过高效识别和管理设备特征信息，针对性的开展设备运维工作。 图13 精细化设备管控策略

约束与限制 数据标签库管理约束与限制 支持的运行环境操作系统 Windows server 2008/Windows server 2008 R2/Windows server 2012/Windows server 2012R2/Windows server 2016； Red Hat Enterprise Linux 6 或以上； CentOS 6 或以上； Ubuntu 14 或以上。 支持的数据库 Oracle 10g/11g/12c； GBase 8a 或以上； Mysql 5.6 或以上； Hadoop 大数据平台-CDH 5.7 或以上； 华为 Gauss DB 100/200； 星环大数据平台-TDH 5.1 或以上； Pivotal Greenplum 5 或以上； SAP HANA 2.0 或以上； PostgreSQL 9 或以上。 支持的浏览器 IE 10 或以上； Chrome 54 或以上； Firefox 61 或以上； Safari 11 或以上。

应用场景 场景1：数据标签库应用场景 通过标签管理分析与预测，企业提升服务质量、效率、回馈。 客户的痛点： 潜在投诉风险预警：热线渠道是电网企业的主要服务渠道，随着业务的不断发展，人工话务强度逐步增高，但精准服务能力低。如何在有限人力资源条件下，准确识别客户诉求、提高人工精准服务和精细化服务水平、降低人工话务工作压力、成为客户服务方面亟需解决的问题。 电费回收风险： 近年来社会经济发展趋缓，电力公司电费回收压力日益增大，电费回收风险防控难度不断增加，同时，由于缺乏对优劣客户的科学评价方法，电力公司无法为客户提供差别化服务，不利于供电企业权益的维护。 如何识别替代潜力客户：我国环保形势严峻，党和政府高度重视节能减排工作和大气污染治理，大力推进能源消费革命和供给侧结构性改革，在终端能源消费环节使用电能替代散烧煤、燃油的能源消费方式，有利于提高环保水平 缺乏精细化策略与运维： 目前设备状态精细化管控工作，仍没有相关的信息系统支撑，开展电网设备状态评价和运维工作时，主要基于各系统直接量测和录入的数据作为状态评价和运维决策条件，缺少基于设备综合信息的支撑方法 通过本方案实现的业务效果： 客户对于停电通知服务满意度提高，停电报修、咨询话务量大幅下降，停电投诉量大幅减少。 采用数据建模方式综合识别停电敏感客户，实现对停电敏感度的量化分析，减少了人工主观因素，提升对停电敏感客户的识别精度； 基于投诉敏感标签，实现对敏感客户的精准服务，提升了客户服务质量，减少人员维系成本。 企业平均回款时长和逾期缴费率显著下降。 促使电费风险管控工作从定性主观判断转向定量精准分析，从事后处理走向提前防控，提高了风险防控工作的效率和效益； 根据客户的不同特征制定差异化防控策略，促使策略与客户特征更加匹配，策略的执行更加有效，节省了催费的人力物力消耗，降低了企业经营成本。 提高潜力客户的识别准确率，相比于人工普查准效率提高近 20 倍。 将全面普查转变为针对性排查，从而将有限的企业资源用到高潜力客户上，大幅提工作效率，高效拓展终端市场； 依据电能替代潜力标签，结合用户信用、资金实力等标签，针对性地解决用户电能改造中面临的资金投入、生产回报等问题，推动企业落实电能改造工作。 支撑企业对设备特征进行标签化提炼，构建了多维度、多层次、多视角的设备标签体系，帮助企业全面深入了解设备特征，使得企业对设备的认知更系统化、明朗化，提高管理效率，降低管理成本。同时将标签融合到采集运维工作的各处理环节中，实现支撑差异化运维策略，使得设备生产运维业务经验得到沉淀、固化、共享。

方案架构 数据标签库管理方案架构 功能架构 图1 功能架构 主体配置：支持多个标签主体的创建与维护，可满足对客户、设备、数据、员工、商品等不同主体对象的标签建设需求。 标签体系管理：提供多层级的标签分类管理功能，支撑对标签的体系化管理，满足各种标签体系建设需求。 标签创建：提供多种标签生成方式，比如规则标签、手工标签、组合标签等，以满足不同特性的标签创建需求。 标签管理：支持标签创建、审核、发布、评估、停用、优化下线的生命周期管理流程，实现标签的全生命周期管理，保证标签的运行状态清晰、有序、可控。 标签调度：支持自定义标签调度更新时间，实现静态标签与动态标签的创建，满足不同的时效性的数据标签更新需求。 画像展现：支持通过精准搜索与模糊搜索进行目标对象画像查询，并支持通过以词云或列式的方式展现标签，直观地将业务对象特征信息进行展现。 群体圈选：支持基于标签和宽表字段进行业务对象筛选功能，灵活快速定位目标群体。 标签服务：支持将标签成果以服务的形式对外发布，并支持对标签服务调用情况进行监测 数据逻辑架构 产品分为配置库与运算库，配置库主要存储系统配置数据需要支持事务性的关系型数据库，运算库按照标签数据量进行选型，默认设置下配置库与运算库会存放于一起 图2 数据逻辑架构 逻辑部署架构 标签画像负载均衡采用华为云平台负载均衡服务，标签画像分接口服务与应用服务进行部署，数据库、缓存等服务直接采用华为云数据服务 图3 逻辑部署架构 物理部署架构 产品支持线性扩展部署，通过灵活地扩展服务器数量提升系统处理能力，满足不同的标签处理与应用需求 单机方式部署请情况下，标签接口服务、标签画像应用服务共同部署在一台服务器中即可，且不需要Redis缓存服务。 集群情况下，通常由2台服务器部署接口服务组成标签接口服务集群，由2台服务器部署标签画像应用服务组成应用集群，且必须使用Redis缓存服务共享会话及应用热数据 图4 物理部署架构 部署架构与资源建议 产品支持线性扩展部署，通过灵活地扩展服务器数量提升系统处理能力，满足不同的标签处理与应用需求 图5 部署架构与资源建议 数据共享交换管理方案架构 应用架构 数据服务共享平台包括资源目录管理、数据使用、数据服务开发、服务控制、调度管理、运行监控、运行维护和数据分析与信息展现，应用架构如下图所示： 图6 应用架构 资源目录管理：是可交换数据元数据的结构化展现，需支持数据库、大数据、文件、Web 服务等多类型数据资源技术元数据的采集和业务元数据的维护能力；支持面向消费者业务视图（比如按主题的划分） 的创建；提供资源注册、维护和搜索等基本功能； 数据使用：主要面向消费方，是消费者如何通过平台申请数据资源及数据管理方审批处理的过程；消费方可通过注册功能自行在平台注册，支持消费方浏览数据资源后提交资源申请（拉）和订阅（推）的方式；消费方可查看所有申请的状态及历史记录，可查看申请的汇总情况；支持单个或批量申请； 数据服务开发：主要面向开发人员，提供在线和离线两种开发方式。对于如全量开发同步、数据库到文件同步等的作业，开发人员可在 Web 页面中进行简单配置完成在线作业开发；对于复杂模型，可通过离线方式开发。数据服务开发提供作业目录管理、作业流的可视化配置等； 服务控制：平台提供用户对数据服务过程中的权限控制，包含 IP 白名单、服务状态、调用关系管理等； 调度管理：作业运行的指挥中心，可通过调度管理配置任务的调度策略，配置任务运行的优先级及触发方式等； 运行监控：对整个平台运行过程中的状态进行监控，包括物理资源、服务引擎、传输监控、故障告警、消费方等，同时提供对日志和历史记录的查看功能。 运维维护：为方便平台使用的功能，支持资源目录、作业模板、服务接口的导入导出； 数据分析与展现：针对平台作业、数据交换总量、文件传输、消费方等进行统计分析。 数据架构 数据架构反映平台中，各种类型数据的分布及流转情况。在数据服务共享平台中，数据可分为业务数据、元数据（含资源目录）、质量数据、作业模板及运行监控数据、统计分析数据等。 业务数据：指承载业务含义（大多来源于企业内部各业务系统及少量外部数据），由各总部及各分子公司业务部门（数据提供方）提供，转移至前置区（数据准备）后，经过相应的处理和扩展，提供给消费方。具备数据提供、数据获取、数据准备、数据处理及服务化开发、数据共享发布和数据消费的完善数据交换过程。业务数据一般存储于 ODS 区，也可直接提供点对点的方式，业务数据在平台中不存储； 元数据（资源目录）：业务数据交换的整个过程，都是以元数据（资源目录）为驱动。元数据可分为技术元数据和业务元数据两种，在数据交换过程中，通过手动和自动的方式进行管理；元数据存储于平台数据库中； 质量数据：针对业务数据所开展质量评估后产生的数据，一般包括质量检核规则和检查结果数据；质量数据存储于平台数据库中，也可将结果数据生成文档后发送给业务系统主责部门； 模型及运行监控数据：平台运行过程中，各类作业的模型（模板）及配置信息，作业运行过程中的告警、监控信息和日志信息等，作业运行过程中的调度策略及调度信息；模型及运行监控数据存储于平台数据库中； 统计分析数据：针对作业、数据交换量、消费方等进行的统计分析；部分数据直接取自模型及运行监控数据，部分数据直接存储于平台数据库。 部署架构 数据服务共享平台部署机构如下所示： 图7 部署架构 数据服务共享平台适应于单级或多级的部署方式： 单级部署：当企业没有上级单位、平级单位、下级单位数据共享需求时可以采用单级部署方式，单级部署时依据生产环境实际情况，部署 DSP产品所有组件于物理服务器（建议服务器数量最少为二台及以上）中，其中 SSM 与 DataRelease 组件必须关联部署在同一台服务器中，当数据交换的作业量较大时，可以对 Server 组件进行集群部署，当数据服务（RESTful）的访问量大时，可以对 SSM 与 DataRelease 组件进行集群部署。 多级部署：当企业对上级单位、平级单位、下级单位有数据共享需求时可以采用多级部署方式，多级部署时将 Agent 和 GatherClient 部署于有数据共享需求的上级单位、平级单位、下级单位的物理服务器中，其他产品组件部署于企业内部服务器中，其中 SSM 与 DataRelease 组件必须关联部署在同一台服务器中，当数据交换的作业量较大时，可以对 Server组件进行集群部署，当数据服务（RESTful）的访问量大时，可以对 SSM与 DataRelease 组件进行集群部署。 技术架构 技术视图 数据服务共享平台整体技术框架及各过程所采用技术如下图所示： 图8 技术架构 数据服务共享平台通过多种数据（结构化数据、非结构化数据、文件数据）、协议（Http、JDBC、Socket）接入方式将已有的业务数据接入 DSP 平台，在平台中通过数据转换、加工计算等逻辑操作，发布为数据服务，通过数据共享区对外提供多种类型的数据服务。 图9 技术实现 资源层：支持对主流关系型数据库（Oracle、MySQL、SQLServer、PostgreSQL、MongoDB、Gauss100、DM），大数据（HBase、Hive）、文件等多种类型数据资源技术元数据的采集和业务元数据的维护。 平台访问层：基于 JDBC、HTTP、RPC 等通信协议实现与底层数据和文件间的访问交互，基于 Socket 通信实现平台各组件间的数据通信，确保平台中数据间交互与通讯高效、安全、可靠。 平台逻辑层：平台逻辑层依托于各类适配器、组件、引擎保证平台的安全稳定运行，适配器有数据库（DBAdapter）、HBase（HBaseAdapter）、Hive（HiveAdapter）、文件（FileAdapter）等类型；组件包含安全、监控、Redis 缓存、日志等组件；引擎包含实时服务引擎、批量服务引擎、监控引擎、日志引擎等。 服务提供层：服务提供层采用轻量级的 Web Service 架构（RESTful），其实现和操作比 SOAP 和 XML-RPC 更为简洁，可以完全通过 HTTP 协议实现对外部应用提供统一的 RESTful Web 服务。 平台展示层：平台展示层使用 VUE+ElementUI 框架，结合 CSS 、AJAX 等业界前沿技术实现丰富的界面展示效果，提升使用者的交互体验。

产品安装 安装环境 表1 安装环境 操作系统 32位和64位的Windows、Linux、Mac OS。 说明：Linux的操作系统包括CentOS、Red Hat、Ubuntu、中科方德、统信、万里红、中标麒麟、银河麒麟、华为欧拉。 浏览器 支持市面上的主流浏览器：chrome、火狐、IE等，推荐chrome。 JDK JDK1.9及以上，推荐JDK11。 安装步骤 远程登录弹性云服务区，按照下面步骤安装到云服务器的数据盘里。 使用非root权限的yhuser用户上传获取到的产品安装包到服务器目录“/home/yhuser/BI”。 进入产品安装包所在目录“/home/yhuser/BI”，执行chmod +x "Yonghong Z-Suite V10.0.sh"为产品添加可执行权限。 图1 添加可执行权限 执行 sh "Yonghong Z-Suite V10.0.sh" 脚本，开始安装产品。 图2 开始安装 设置产品使用的语言，输入1。 图3 设置语言 确认将产品安装到您的计算机上，输入o。 图4 确认安装 将产品安装到新目录，输入2。 图5 安装目录 查看产品的许可协议，并接受协议，输入1。 图6 查看许可协议并接受 输入产品安装密钥（必填）和license server（非必填）。 图7 填写安装密码 产品在license校验时会上报后台数据到永洪服务器，不会有其他任何形式的数据上报。 后台数据格式如下：http://www.yonghongtech.com:8089/bi/validLicense?license=xxx&ip=xxx&mac=xxx，其中license即永洪提供给您的license号，ip是您的服务器地址，mac是您的服务器的物理地址。 设置产品的安装路径。安装路径默认为之前安装过的路径 ,用户可以自定义安装路径，此处设置为“ /home/yhuser/product ”。 图8 设置安装路径 设置程序服务器启动端口号、停止端口号。 启动端口号默认为 8080 ，用户可以自定义端口号，此处设置为“8097”。 停止端口号默认为 8005 ，用户可以自定义端口号，此处采用默认，按下enter即可。 图9 设置端口号 设置系统所需的Java环境的JDK、JRE路径，两者路径相同。产品适用JDK9（含）以上的版本，优先推荐JDK11 图10 设置JDK、JRE路径 设置系统运行所需的最大内存，此处设置为“1024”。 图11 设置内存 设置admin账号初始密码。密码需包括大小写字母和数字，且密码长度为8~32位。用户可根据实际情况设置希望的密码，此处设置为Admin1234。 图12 设置初始密码 等待产品安装完成。 图13 等待安装完成 启动产品 进入产品安装包所在目录，如“/home/yhuser/Yonghong Z-Suite/tomcat/bin/”“cd /home/yhuser/Yonghong Z-Suite/tomcat/bin/” 启动产品 sh startup.sh 登录产品 输入admin，安装时设置的密码，单击登录。 图14 登录

PostgreSQL数据库重启操作 纷享销客专属云中部署了4套PostgreSQL数据库，分别承担不同的用途，每套数据库由一个主节点及一个从节点组成，通过主节点上的VIP对外提供服务。 这些PostgreSQL数据库的信息如下： 10.19.71.39 PaaS PG主库 10.19.71.40 PaaS PG从库 10.19.71.41 BI PG主库 10.19.71.42 BI PG从库 10.19.71.43 资源回收 PG主库 10.19.71.44 资源回收 PG从库 10.19.71.45 全局 PG主库 10.19.71.46 全局 PG从库 可使用root登录到相应的节点执行下列命令来重启postgresql服务： systemctl restart postgresql-12.service 可使用root登录到相应的从库节点执行下列命令来执行主从切换： sh /var/lib/pgsql/pgswitchover.sh -h jtltc-paaspg-s02 (从库节点)

MySQL/MHA服务重启操作 纷享销客专属云中部署了1套MySQL服务器，由主从两个节点组成： 10.19.71.35 Master 10.19.71.36 Slave 纷享销客专属云中部署了2台MHA服务器，一台负责MySQL的高可用切换，另外一台用于备用： 10.19.71.37 主用 10.19.71.38 备用 可使用root登录到相应的节点执行下列命令来重启MySQL服务： systemctl restart mysqld

备份服务器重启操作 纷享销客专属云中部署了1台集中备份服务器，这台服务器是： 10.19.71.76 这台备份服务器承担了如下备份功能： 4套生产用途的PostgreSQL主库、从库的备份 Zabbix数据库的备份 MySQL主库、从库的备份 MongoDB从库的备份 Nginx访问日志的备份 ZooKeeper数据的快照 Etcd数据的备份 数据备份均通过各种的备份脚本自动完成，这些备份脚本均配置到了crontab中，该服务器日常无需维护，如果有备份失败等情况，一般直接重启服务器即可。

Zookeeper服务重启操作 纷享销客专属云中包含1套ZooKeeper集群，部署在K8S中的部分服务使用了dubbo框架，这些服务依赖ZooKeeper进行服务注册和发现。 10.19.71.62 10.19.71.63 10.19.71.64 ZooKeeper集群允许失败一个节点，当超过一个节点不可用时，ZooKeeper集群将失败，正常情况下，3个节点中有一个leader及两个follower，服务重启时可能导致leader重新选举。 图4 Zookeeper服务重启操作 可使用root登录到相应节点执行下列命令来重启ZooKeeper服务： systemctl restart zookeeper.service

Zabbix Proxy/agent重启操作 纷享销客专属云中部署了1台Zabbix Proxy，用于系统监控，Zabbix Proxy的服务器是： 10.19.71.90。由于Zabbix Proxy需要数据库支持，因此在该服务器同时也部署了MySQL数据库，仅用于临时监控数据的存储。 纷享销客专属云中所有服务器（包括Zabbix Proxy服务器）上均部署了Zabbix Agent，将监控数据汇报至Zabbix Proxy。 可使用root登录到相应节点执行下列命令来重启对应的服务： 在10.19.71.90上重启zabbix proxy服务： systemctl restart zabbix-proxy.service 在服务器上重启Zabbix Agent服务： systemctl restart zabbix-agent2.service

pgbouncer重启操作 纷享销客专属云中包含2台pgbouncer服务器，作为后端PostgreSQL的连接池工具，在这2台pgbouncer服务器前面有一组LVS用作四层代理，这两台pgbouncer服务器在同时提供服务，可以容忍其中一台服务器终止。 2台pgbouncer服务器的信息如下： 10.19.71.85 10.19.71.86 可使用root登录到相应的节点执行下列命令来重启pgbouncer服务： systemctl restart pgbouncer.service

freeipa重启操作 纷享销客专属云中包含2台freeipa服务器，互为副本；目前这两台freeipa服务器仅对专属云中的服务器资源提供DNS解析服务和时间服务。 2台freeipa服务器的信息如下： 10.19.71.87 10.19.71.88 正常情况下可通过下列命令查看freeipa的服务状态： ipactl status 图5 freeipa重启操作 可使用root登录到相应的节点执行下列命令来重启freeipa服务: ipactl restart

LVS/keepalived重启操作 纷享销客专属云中一共包含4台LVS服务器，如下： 10.19.71.77与10.19.71.78一组用于转发 K8S Node/Port。 10.19.71.83与10.19.71.84一组用于转发数据库连接至后端的PGBouncer。 每一组LVS通过Keepalived来管理VIP，并在节点异常时通过keepalived实现VIP自动切换。 正常情况下，VIP只会运行在其中一个节点上，出现极端情况（如脑裂）时，可使用root登录到2个节点执行下列命令来解决脑裂异常。 systemctl restart keepalived.service 同时，LVS的服务器上均配置了计划任务用于脑裂或异常检测，如下图： 图3 检测

Nginx服务重启操作 纷享销客专属云中一共包含4台Nginx服务器，如下： 10.19.71.81 和 10.19.71.82两台用于云间业务调用、业务发版拉取WAR包等用途，同时，这两台服务器上部署了keepalived，用于维护VIP（云间业务调用、业务发版拉取war包访问的均为该VIP地址）。 10.19.71.79 和 10.19.71.80两台为用户接入Nginx，在这两台服务器的前面接入了内网F5，向后转发至纷享销客各种业务。 可使用root登录到相应节点执行下列命令来重启Nginx服务： systemctl restart openresty.service

ElasticSearch重启操作 纷享销客专属云中包含2套ElasticSearch集群： 其中一套用于存放业务数据： 10.19.71.47 10.19.71.48 10.19.71.49 一套用于存放服务错误日志，该套集群的节点上同时部署了Kafka以及其依赖的组件。 10.19.71.50 10.19.71.51 10.19.71.52 ElasticSearch采用docker进行部署，系统重启后，容器会自动拉起。 在运维的过程中，有时候会碰到某个节点负载高或挂起的情况，这个时候需要根据监控数据来判断负载高的节点，然后直接重启服务器。

RocketMQ重启操作 纷享销客专属云中包含1套RockeMQ集群，由2台name server，4台 broker server组成，这4台broker server又分为两组，每组由一台master broker和一台slave broker组成，具体的IP信息如下： 10.19.71.53 name server 10.19.71.54 name server 10.19.71.55 master broker server (第一组) 10.19.71.56 slave broker server (第一组) 10.19.71.57 master broker server (第二组) 10.19.71.58 slave broker server (第二组) 需要说明的是，Rocket MQ的broker server主从无法切换，这是配置两组Broker的原因，同时也是RocketMQ的标准部署。 可使用root登录到相应的name server节点执行下列命令来重启RocketMQ name server服务： systemctl restart rockermq_namesrv.service 可使用root登录到相应的broker server节点执行下列命令来重启RocketMQ broker server服务： systemctl restart rockermq_broker.service

SaltStack重启操作 纷享销客专属云中部署了1台SaltStack Proxy，用于配置管理，该服务器上同时运行 salt-master, salt-minion和salt-syndic 3个服务。SaltStack Proxy的服务器是： 10.19.71.89 纷享销客专属云中其它服务器上均部署了SaltStack minion，这些服务器上只运行 salt-minion 服务。 可使用root登录到相应节点执行下列命令来重启对应的服务： 在10.19.71.89上重启salt相关的3个服务： systemctl restart salt-master.service systemctl restart salt-syndic.service systemctl restart salt-minion.service 在其它服务器上重启salt-minion服务： systemctl restart salt-minion.service

MongoDB服务重启操作 纷享销客专属云中部署了1套MongoDB数据库，这套数据库由3台服务器组成，如下： 10.19.71.32 MongoDB Arbiter 10.19.71.33 MongoDB Primary 10.19.71.34 MongoDB Secondary MongoDB Arbiter终止，服务不受影响；MongoDB Primary终止，MongoDB将发生主从切换。 可使用root登录到相应的节点执行下列命令来重启MongoDB服务： systemctl restart mongod

frr重启操作 纷享销客相关的服务器上均部署了FRRrouting，该组件必须处于启动状态，用于在服务器之间构建BGP网络，10.33.0.0/16网络需要依赖FRRrouting进行通讯。 一般情况下，当frr相关的进程异常时，watchrfrr会负责自动重启相关的进程。 图2 frr重启操作 当确认问题是由于 frr进程导致时，该服务器所提供的服务也将失效，此时zabbix会发送告警。 可通过下列方式使用root用户手工启动frr服务： systemctl restart frr.service

方案架构 北京易动纷享客户管理解决方案架构 图1 业务架构 纷享销客CRM系统采用Java语言开发，整个系统基于微服务架构，整合了华为云和主流的开源框架产品，提供大型互联网应用所需的各类基础服务。 图2 部署架构 架构描述： 方案由华为云E CS 等计算，存储和网络资源为基础，容器化的部署应用平台； 方案采用了华为云RDS for PostgreSQL和RDS for MySQL两种数据库作为数据分析和存储的数据库； 方案使用了DDS和redis等华为云中间件服务； 方式使用了OBS作为数据和应用的常规备份以及异地备份； 方案在华为云的基础上，提供了CRM基础功能平台，以及其他数字化行业应用，比如营销通，订货通，代理通，服务通等； 方案针对制造，高科技和快消三大场景还提供行业化专业能力，共包括54个细分行业场景，为千行百业的客户提供具有行业属性的CRM； 方案同时还能够与客户已有ERP，OA等应用系统的集成，打破数据孤岛；

方案优势 方案主要由 华为云计算 底座+华为云数据库等PaaS平台+纷享销客CRM产品形成面向制造、快消、高科技等行业全流程的营销服一体化解决方案，构建从市场到线索，线索到回款，问题到解决、伙伴协同闭环解决方案，实现客户管理精细化，销售过程标准化，服务过程便捷化，直营渠道一体化，促进企业数字化、智能化水平，为企业以客户为中心的经营决策支撑提供数据基础。 客户管理全景化：建立从目标到结果的数字化的管理、实现客户的分级分类经营、准确定义客户画像及客户潜力， 实现客户资源企业化、覆盖范围数据化、跟进策略标准化、拜访记录透明化、业务往来沉淀化、分层数据关联化。 销售过程精细化：建立标准化、规范、流程化、赋能化的销售过程管理，针对项目报备、拜访、方案验证、投标等售前过程及行为进行精细化管理，缩短销售周期，提升赢单率。建立项目运作体系，通过可复制的标准化流程，提升工作协同效率，降低成本，可控交期。 业务价值链群化：将上游企业与下游经销商的业务连接起来，实现客户报备、联合跟进、销售预测、费用管理、培训赋能等业务经营，实现合作共赢。

应用场景 纷享销客连接型CRM通过深入行业场景，助力细分行业数字化转型在三大行业及其下包括54个细分类目中打磨服务于行业典型场景的专属CRM解决方案 高科技行业场景 客户痛点： 市场营销难：市场部门花费了大量的品牌和市场费用，但缺乏对线索到商机到订单的ROI分析和关键断点的诊断； 销售/渠道冲突：直销和生态渠道经常出现项目冲突，互相收集证据的问题，没有客观评判的依据，造成了大量的资源和成本的浪费； 销售管理难：不知道销售每天是否在跟进应该跟进的客户，以及客户跟进到何种状态； 方案价值： 营销管理：落地全渠道获客、潜客识别评估、线索培育转化、渠道ROI与数据驾驶舱等能力，助力企业营销推广获客，溯源转化效果，驱动业绩增长 伙伴管理：将上游企业与下游经销商的业务连接起来，完成客户报备、联合跟进、销售预测、费用管理、培训赋能等业务经营，实现合作共赢。 销售管理：对线索的精细化管理、构建客户360°画像、落地标准化商机销售流程与预测，快速报价、销售预测与评价，实现线索到现金的完整业绩闭环； 制造业客户场景 客户痛点： 获客效率低：传统广告和推销效果越来越差，获客成本越来越高。 客户管理粗放：客户分级不准确，与资源投入和服务响应不对等。 报价效率低：产品种类多、参数型号复杂，选型配置报价难。 方案价值： 数字化全渠道获客：全渠道获客数据归集，建立企业线索库、私域流量池。通过智能线索评分、自动化线索培育转化、自定义营销漏斗及多维度数据报表，全面洞察营销效果，科学助力企业营销决策。 全景化客户管理：实现客户资源企业化（终端客户、系统集成商、经销商等）、客户分级分类，，客户资源匹配规范化（报备、分配、回收机制）、客户风险预警等，形成客户360°全景视图。 快速报价能力：满足复杂BOM结构，基于CPQ【配置、 定价 、报价】能力，灵活选配并快速、准确的报价，并与后端ERP进行数据交互。 快消农牧行业场景： 客户痛点： 工具无法支持业务：销售人员市场业务与个人能力有关，工具应用与实际业务不贴合； 促销导购难：市场扩展、终端动销与收集复查成本较高，管理意图（堆头，促销，新品推广等）无法有效直达终端 缺乏统一有效的数据支持与运营管理平台：客户信息、客户资信、客户联系人、行业信息库等数据不完整。面向客户需求与经营全过程的服务能力欠缺。工作报告数据难以形成沉淀 方案价值： 提供作战工具：帮助业务人员高效完成车销、引单等快消渠道精耕过程中的关键动作； 促销导购管理：提供促销活动管理、导购入转调离、导购员排班、活动数据上报等关键能力； 建立自有客户信息平台：提供依据营销组织内部运营数据所得出的客户数据画像和模型以及评级体系，利用真实、准确、适合各业务版块运营的工具实现数据对各业务组织的内部服务和外部链接

业务描述 本方案涵盖了多个业务模块，下面以财务自助分析模块为例，进行业务说明： 在企业的日常业务中，会形成各种各样的财务和业务数据，根据不同业务需要，企业管理人员或者财务业务人员需要查看有关的报表，以便于对企业的情况有更清晰认知和理解。通过账表设计，可以根据不同业务的数据模型，设计各种样式的管理报表，满足用户的各种账表查询需求。 图1 财务自助分析业务图 企业在日常业务中形成了多种业务和财务数据。 企业管理人员和财务人员想要查看业务或者财务数据的统计表。 可由报表设计人员根据业务人员的需求设计报表样式。 企业管理人员和财务人员根据设计好的报表查询财务业务报表数据。