5G 时代是云和网相互融合的时代，涵盖云、网、端的“云网产品融合，云网一体化运营体系”。采集平台定位于中国电信新一代云网运营系统（OSS3.0)和中国移动 5+2+N 网管中台（OSS4.0）的技术底座，提供全网全专业的采集控制服务，对接范围包括各专业网管 EMS/OMC、各网元实体、DPI 数据平台等。

面临的挑战

对于采集来说，各运营商的要求和各厂商的架构演进，都在向“框架+服务/插件”模式演进。采集框架负责生成和调度任务，服务负责执行任务，两者间难点和压力也有较大不同。

可见出采集产品的难点、重点主要在服务/插件层面。其面临的挑战主要体现在：

业务差异性：

• 采集流程环节差异性：不同专业的数据消费方对原始数据的处理要求不同，比如同一份无线性能数据，给网优系统只需要把数据解析后按文本文件提供，而给性能分析系统则要求进行归一化后通过文本文件和 HDFS 提供；其次是内部处理不同，比如文件类的采集和解析是两个不同环节，而网元指令类采集，为提效会将采集和归一化合并在同一个环节中。

• 采集方式差异性：专业不同，采集协议存在多种，主流包括 CLI、TL1、SNMP、FTP/SFTP、Http、Socket、Telemetry 等。

• 解析方式差异性：采集源提供的原始文件包括 XML 文件、CSV 文件、JSON 文件、消息流、指令结果等，不同的数据解析方式不一。

• 输出方式差异性：按照数据的分类，性能数据入文件系统或 HDFS、配置数据需同时入文件系统和数据库、告警消息入消息队列或文件。

上述各种差异需要在具体项目落地的时候按业务需求分析来实现，这对产品的扩展性提出了较高的要求：敏捷、高内聚、低耦合、高配置性。

工作可靠性：

采集是上层网管系统的底座，底座的可靠性对上层系统的应用效果有着决定性的影响。比如告警采集出现丢失、中断，会影响故障系统的故障生成的完整度和根因分析的准确度；配置采集出现丢失，影响设备资源入库入网，进而影响业务开通无对应资源使用或资源分配错误。

处理高效性：

设备告警的产生具有不可预知的因素，可能在某个时间突增甚至是形成告警风暴，风暴产生时候的流量会比平时提升 1~2 个数量级，但同时告警处理时延要求并不能降低（必须要保证 3 秒内的时延），否则出现阻塞会影响端到端故障的生成时延。再比如配置数据采集处理延时会影响前端操作感知，试想下装维人员在现场给设备加电通网后还得等几分钟才能在系统上看到设备这会是什么样的体验。

透明化：

单次采集过程的时间跨度从 1 秒钟到 2 分钟不等，期间的处理过程属于纯后台计算，如果我们只提供任务出入时的信息，过程中黑盒运行会让用户缺乏安全感，谁知道是运行中还是宕机了呢。同时采集数量巨大，在采集过程中我们也不太可能靠人力去分析每笔采集任务的完成质量，我们该如何用一种简洁的模式来判断采集完成的质量呢。

低成本：

熟悉运营商 OSS 圈子的同学们都知道，近年来甲方在单系统/项目上的投资逐年减少，另一方面乙方又要求提升利润率/端到端人效，这相互间的矛盾该如何解决？降低产品的交付和运维难度成本是一个非常重要的方向。

架构思路

前面我们也谈到，采集产品的难点、重点主要在服务/插件层面，接下来我们就针对“服务/插件”的架构进行设计思路的简要分析。

1 容器+N 组件

对于高扩展性要求的挑战，我们借鉴了电脑/网络设备主机的架构思路，主机至少会有一个标准化架构的主板，用户可以根据自己的需求在上面灵活安插各种功能规格的板卡。主板负责提供电力和数据交互，各种功能板卡实现业务功能，比如显卡、声卡、网卡、存储卡等。

在前面我们也分析了采集场景的多样化，按主机架构思路，我们将各种采集过程中要直接用到的各种功能通过差异化的组件来实现，每个组件只关注各自范围内的功能，不重叠，高内聚化。同时我们还提供一个采集服务容器，负责接收反馈采集任务和心跳状态上报（外部交互），负责调度各组件的工作顺序以及之间的子任务数据交换（内部交互）。组件只需实现标准的接口即可在容器中运行，这样 N 种组件可编排出远大于 N 种采集流程。

在实际实现的时候，我们还会对这种容器+组件的架构模式进行升级。对于同一种采集源会将所用到的组件都封装在一个线程组内，组件根据采集流程模板进行多线程实例化。

通过这种组件按需组合的模式，可广泛敏捷适应不同业务场景，用户就像拼乐高一样，只需掌握每个组件的特性，即可实现所需的采集场景，解决业务扩展的敏捷度问题。我们前面在采集流程差异化分析时候所举例的场景，即可通过这种模式解决，如下图所示。不同场景采集流程的环节是不同的，甚至还会有分支的情况。

组件关系树

曾经有幸与一位友商架构师聊过采集架构的设计，他说他们之前也做过类似的架构，但最终却无法在生产上的落地，究其原因，是由于组件数量过于庞大，其采集产品提供了 200+以上的组件，实施交付时开发人员对存量组件无法了解这些存量组件而选择直接开发新组件，导致继续膨胀。

各专业数据采集的过程其实是有个大致的步骤：采集-解析-标准化-分发-通知。我们遵从 OO 设计模式，严格设计组件继承关系，控制组件规模数量，降低实际应用复杂度。

根组件 AbstractComponent 衍生出 6 类抽象组件，再衍生出具体可用的功能组件。这样需求开发人员只需在树形结构中设计好每种组件的位置，只关注组件的开发（无需关注容器），尽可能继承父类功能，最大限度的代码复用，减少新功能组件的开发难度和时间，解决业务扩展敏捷和成本的问题。

环节组件异步任务调度

在容器中各组件是相互独立且并行工作的，它们就像工厂流水线的工位，只负责完成各自工位上的工作内容，那么就会涉及工件在各工位上的传递。为避免组件任务的前后等待导致的阻塞，我们采用了异步任务调度模式。采集组件间要传递的内容。我们将其分成两类：工作半成品/成品和任务消息通知。

对于半成品/成品，如果颗粒度较大，我们会采用本地文件的方式（搭配高速固态硬盘）；如果颗粒度较小，我们会采用 REDIS 方式；如果颗粒度非常小甚至可以合并到消息队列中。对于消息可以采用 MQ/KAFKA，甚至是 JVM 中的内存队列（搭配任务补偿和消息补采机制应对小概率的异常中断情况）。

这种异步任务调度模式，可有效缩短单笔采集任务的执行耗时，提升整体采集效率。在后面的大文件采集分析里面，我们会基于这种方式对采集组件进一步的升级。

可视化流程设计器

为了让采集功能组件更加容易编排设计出采集流程，我们提供了一个可视化采集流程设计器，在设计器中对已注册的组件分类管理，用户可以将这些组件拖拉拽到设计区形成采集环节，并加入环节连线来确定各个组件的工作顺序，对环节关联的组件按业务需要设置各种扩展参数。设计器的参考实现如下图所示：

在实际应用中，采集流程大部分是可复用的，我们会针对常用的消息采集（告警或性能主动推送)、文件采集（OMC/网元已提前生成数据文件）、指令采集（实时调用 OMC/网元查询指令实时获取实时指标值）这些场景，再结合各采集源提供的接口类型，提前设计十几种常用流程模板，用户遇到特殊场景（如需要多分支处理、需要持久化等）可基于这些流程模板通过复制功能生成新流程模板后简单修改即可。

标准化日志

前面说过采集任务的执行时间从 1~+∞秒，过程如黑盒运行对用户来说是非常可怕的，这要求在采集服务执行过程中要不断地输出事件日志。这些事件不仅需要覆盖全，还要易于理解，降低使用过程中项目一线和研发后端的沟通成本，就像 ORCLE 在使用的时候我们只要说出 ORA-00001 就知道该怎么处理。

因此我们整理了一套系统事件规格，将其作为开发规范（特别是组件），在容器和组件实现的时候埋点，如出现异常级别的事件可根据不同的事件类型（错误码）提供不同的自动或手动的处理工具。事件规格表的部分实现参考如下表。

通过这种方式，给项目一线规范了运维操作，在前线和后端建立了标准的“行话”，后续再结合 WOODY 自动化运维工具，同时解决了透明化和低成本运维的问题。

异常处理

采集平台属于后台静默运行的系统，最佳运行状态就是没人感知到它的存在，这要求其运行具有相当的稳定性，能自动处理各种异常情况。这些异常情况我们从来源方面可大致分成三类：业务功能类，软件架构类（非业务功能）和运行环境类（IAAS、PAAS 和网络等）。

业务功能类的异常处理需要在组件实现的时候根据业务分析，上面只是我们 FTP 组件的样例，在其它的组件中都需要独立分析实现，结合标准化日志将信息抛向前端。这种能力是随着组件的扩展在不断的扩展，由于我们组件是基于 OO 模式可继承扩展的，因此其业务异常处理能力也在不断的积累。

对于软件架构类的异常情况，我们将多个服务实例（容器）组合成一个抽象服务，在实例心跳中断或任务超时的情况下，可转移至其它节点执行（具体可见部署部分）。但这里需要注意的是，消息类采集任务转移或重启后，可能存在消息丢失，需要在组件上实现补偿功能。

对于运行环境类问题，由于 PAAS 平台和 IAAS 服务已云化，基本是基础设施部门统一提供和问题处理，不在这里详细分析。

规范流程上线

组件研发到流程设计到加载应用遵循以下步骤：

• 组件需求分析：根据需求设计流程，分析是否要开发新组件以及新组件的位置。

• 组件开发实现：重写或复用父类的 init（初始化），实现 dealMessag（实现新的功能逻辑）、dealDataIn（获取输入）、dealDataFinish（输出完成）、judgeDataOut（判断是否完成）方法。

• 组件注册：完成组件开发后，打包部署到环境。运维人员在组件管理中进行新组件注册，填写配置组件编码/名称、组件类型、类路径、组件扩展参数等。

• 采集流程设计：运维人员设计采集流程，配置采集环节关联功能组件，配置组件参数。

• 采集绑定类型：设置流程应用范围包括网元厂商型号版本。

典型场景

文件采集

通过 FTP 采集文件是最常见的采集场景之一，一般情况下单个文件大小在 M 之内，使用上述架构方案处理只需要单环节的组件支持多实例多线程即可，采集和计算转换处理时长也会在 10 秒内完成。但在采集无线专业的性能文件会碰到一种超大文件采集场景，单文件在 100M 左右，文件内包含 10W 行（基站小区）记录，性能指标 1K 左右，如果常规处理 JVM 内存占用将近 1G 处理时长在 10 分钟左右，在多 OMC 采集会造成内存溢出错误，错峰采集处理又会造成无线性能指标输出延时，影响最终的网优性能分析及时率。

对超大大文件的处理，我们利用磁盘内存，将大文件化整为零，全程处理使用文件碎片，最后按序进行结果合并，类似于 TCP 报文分拆成多个 IP 报文同时传送，能降低了服务内存占用且保证了服务处理的性能。

文件切割解析的逻辑是，当源文件超过一定大小时，将源文件切割成多个小文件进行处理，存入磁盘；同一时间只读入并处理两个小文件，以此降低服务内存的使用。

消息采集

消息采集属于常驻类任务，任务单会触发服务（可能是服务端或客户端）向采集源订阅消息，然后接收源主动推送过来的消息，这里最常见的消息采集就是告警采集。

在告警采集流程中，由于组件间处理的告警消息颗粒度很小，其任务通知消息和处理成品我们都通过 KAFKA 进行传递。此外告警采集需要保证不丢失和风暴出现时可平稳、有序的处理，两者缺一不可。在现有的告警处理流程中，我们通过风暴识别拦截、提取告警级别、延迟派发过程进行告警风暴的处理；通过活动告警同步、历史告警同步保证告警连续性。

告警风暴：在告警正常的处理过程中，如果上 1 分钟内告警量达到风暴值，后续告警消息处理时，会先提取出高级别告警进行处理和派发，其它告警消息写入 FQ 缓存延迟派发操作。如果高级别告警输出流量小于阀值，按 FIFO 原则从 FQ 提取处理直到整体输出流量达到阀值。

告警连续性：每次告警输出都需进行告警流水号的比对，从而判断告警是否连续，当告警出现不连续时，可通过活动告警同步、历史告警同步，进行告警数据的二次处理，获取丢失的告警数据，并进行正常的告警处理。

部署方案

前面主要分析了整个服务/插件的架构设计，基于这样的架构思路会非常方便实际生产应用的部署。我们可以将服务部署模式分成以下几类，每类搭配上特定的硬件要求，让这种架构优势能充分发挥出来：

• 超大/大颗粒度文件采集：高速固态硬盘

• 密集型文件采集/告警采集：高速网络（与 REDIS 及消息中间件高频交互）

• 复杂指令型采集：多 CPU

在实际应用中，我们不仅会按上述情况来选择搭配服务/插件的部署环境，还会将不同专业的服务部署进行隔离，避免网络连接的安全隐患。同时多个采集实例会组合成一个采集服务，不仅是任务均衡分担，当出现实例异常情况将任务转移到正常实例中，当任务超时时可重新派发执行任务，保障业务采集高可靠性。

应用成效

2020 年移动某省的统一采集项目是新架构版本的第一个实践项目，共涉及 3 大专业（无线、核心网、传输）6 个厂商共计 219 个 OMC，按采集场景归类 90+。通过“容器+组件”架构，快速配置出各场景采集流程，成功解决了业务扩展的流程差异、采集方式差异、解析方式差异和输出差异问题，整个项目实施不到 60 天就完成全部专业采集加载上线。

通过组件多实例及异步任务调度技术，单采集源的告警类消息采集具备 6K 笔消息/秒，时延<1 秒的采集能力，如果是多采集源则一台 8C 虚机的吞吐量能达到 3W 笔消息/秒，性能比原有采集系统提升了 10 倍；配置/性能类文件采集处理输出达到 36G/小时，效率比原有采集系统提升了 5 倍，4G 无线性能 60M 大文件采集耗时 2 分钟，效率比原系统提升了 3 倍。

项目上线运行几个月的时间，实现稳定的静默运行，用户日常只关注系统提供了每日数据质量报告。由于系统运行稳定，运维简单且自动，运维投入人员只需 0.5 人。

在移动另一个省的多云管理项目中，该架构继续大放光彩，虽然从采集模式、数据处理和输出上有较大差别，但仅通过多云组件扩展就实现了复杂的多云采集业务处理，服务容器保持稳定不变。多云采集业务实现较为复杂，受限篇幅这里就不展开详细分析，我们将在后续的采控产品文章中再做设计分享。