ONAP 架构概述（中文）

1. 概述

随着电信运营商、有线运营商、云服务提供商以及他们的方案提供商对通用自动化平台需求的增加，ONAP项目应时而生，并致力于在充分利用现有投资的前提下，提供差异化的、按需定制的、有竞争力的网络服务。

在ONAP诞生之前，通信运营商为了提供新的业务，在从安装新的数据中心设备到（某些情况下）升级客户现场设备等一系列工作中，需要执行大量的人工调整工作。这种人工模式的规模和成本均对运营商提出了重大的挑战。许多运营商都在寻求利用SDN和NFV技术，提高业务创新速度，简化设备的互操作性和集成难度，降低整体的资产投入和运营成本。另外，目前碎片化的管理场景也使得端到端级别的业务质量难以得到监控和保障。截止当前ONAP已准备发布第三个版本，这些挑战在现网依然存在。

ONAP通过为物理和虚拟网络设备提供全局的和大规模（多站点和多VIM）的自动化功能来解决这些挑战。它通过支持可以快速定义资源的TOSCA数据模型，提供一套通用的、开放的、可互操作的北向REST接口，以及支持YANG和TOSCA数据模型来提高业务敏捷性。ONAP的模块化和分层特性有助于提高互操作性并简化集成过程，它能够与多个VIM、VNFM、SDN控制器甚至传统网络设备的集成来支持多VNF的环境。ONAP对VNF的整体要求发布将助力符合ONAP标准的VNF的商业部署。这样既可以帮助网络和云业务运营商优化他们的物理和虚拟基础设施，以降低成本、提高性能；同时，ONAP采用标准模型，降低了异构设备的集成和部署成本，同时最大限度地减少了管理的碎片化。

在ONAP平台上，终端用户/组织和他们的网络/云业务提供商可以在一个动态、闭环过程中进行协作，实例化网络设备和业务，并对操作类事件进行实时响应。为了设计、实施、规划、计费和保障这些动态业务，主要有三方面的要求：

一个健壮的设计框架，可以在各方面对业务进行规范，包括：对组成业务的各类资源和关系进行建模，制定指导业务行为的策略规则，制定业务弹性管理所需的应用、分析和闭环事件。一个流程/策略驱动的编排和控制框架（业务编排器和控制器），在必要时提供自动的业务实例化，并能够弹性管理业务需求。一个分析框架，可以根据指定的设计、分析和策略，密切监控整个业务生命周期中的行为，实现控制框架所要求的响应，从而可以对从设备自愈到根据需求变化对资源进行扩缩容调整等各种情况进行处理。为此，ONAP将特定业务和技术细节从通用信息模型、核心编排平台和通用管理引擎（用于发现、配置和保障等）中分离出来。此外，它将DevOps/NetOps方法的效率和模式与运营商引入新业务和技术所需求的正式模型和过程相结合。它利用包括Kubernetes在内的云原生技术来管理和快速部署ONAP平台及相关组件。传统的OSS/管理软件平台架构会对业务和技术进行硬编码，在整合变化时需要很长的软件开发和集成周期，ONAP与之形成鲜明的对比。

ONAP平台根据以下基本原则，支持产品/业务的独立的设计、创建和生命周期管理：

在不需要平台软件新版本和影响现有业务的情况下，可以发布新业务，并对新技术动态进行全生命周期编排（包括设计、配置和运营）和业务API部署；电信级的可扩展性，包括横向扩展（线性扩容）和分发，以支持大量的业务和大规模网络；元数据驱动和策略驱动的架构，以确保使用和发布功能的灵活性和自动化；架构足够灵活，可采用最好的组件；通用功能只需要一次开发，多次复用；核心功能支持多种不同的业务和基础设施；随着需求增长或收缩，架构应支持弹性扩展。2. ONAP架构

ONAP平台提供了构建特定行为所需的通用功能（例如：数据采集、闭环控制、元数据流程创建、策略/流程分发等）。

当创建一项业务或运营能力时，需要在ONAP设计框架界面上设计业务/运营特定的业务定义、数据采集、分析方法和策略（包括纠正/补救措施的流程）。

图1展示的是ONAP架构和基于微服务的平台组件的概要设计视图。

下文的图2提供了ONAP架构的简化功能视图，突出部分关键组件的作用：

设计态环境用于往ONAP上线业务和资源，并基于它们设计新业务。对外API组件为ONAP平台的北向接口提供了互操作性，同时Multi-VIM/CLOUD模块支持ONAP系统负荷在云间的互操作。OOM提供了Kubernetes托管云环境下云原生安装和部署的能力ONAP的通用服务可以管理更加复杂和优化的拓扑。MUSIC允许ONAP扩展到多站点环境，以支持全局规模的基础架构需求。OOF提供一种声明性的、策略驱动的方法用于创建和优化应用，如归属/位置、变更管理调度优化等。信息模型和框架实用程序持续演进，以协同众多标准化组织的拓扑、工作流和策略模型，包括ETSI NFV MANO、TM Forum SID、ONF Core、OASIS TOSCA、IETF和MEF等。

卡萨布兰卡版本在设计态和运行态领域、ONAP安装和S3P具有许多重要的新功能。

设计态：ONAP的SDC项目增加两个新的仪表盘——DCAE design studio和SO Workflow Designer，用于帮助设计人员、产品经理、运维人员和VNF的所有者在一个统一设计平台上创建产品。

运行态：业务编排和生命周期管理项目具有支持物理网络功能（PNF）、横向扩展、重启、流量迁移、扩展的硬件平台感知（HPA），归属优化服务，地理冗余和边缘云部署等新功能。 这将扩展生命周期管理工具包的操作集，提高性能和可用性，并解锁边缘自动化和5G用例。通过支持ETSI NFV-SOL003，可以让ONAP兼容集成VNFM。

在监控、分析和服务保障方面ONAP在DCAE中提供对Linux Foundation PNDA项目的支持，为需要类似API的用户提供CDAP的替代方案。另外，数据采集框架现在可以通过高容量采集器采集实时消息，处理PNF并支持SNMP和文件数据采集器。Policy项目引擎支持新的卡萨布兰卡蓝图，而且可通过SDC中的策略设计功能分发策略，从而简化设计过程。另外，Holmes告警关联引擎具有新的GUI，并通过脚本提供更丰富的功能，再次简化告警关联规则的开发。

此外，A&AI具有新的能力，可通过提供历史数据来支持审计功能。通过在MSB中集成Istio，ONAP服务可以访问多种服务网格功能，从而提高可靠性、可观察性和性能。ONAP的北向API持续与标准API对齐，包括TMForum（聚焦ServiceOrder）和MEF API（参考Legato和Interlude API），以简化ONAP与OSS / BSS的集成。VID and UUI operations GUI项目可通过简单的点击界面支持更多的生命周期管理操作，使操作员可以轻松执行更多任务。此外，CLAMP项目提供了一个新的仪表板，可用于在设计和运行期间观测DMaaP和其它事件，以简化控制环自动化的调试。

ONAP安装：ONAP Operations Manager（OOM）通过利用Kubernetes（Docker和Helm Chart技术）进一步简化ONAP的安装。在卡萨布兰卡版本中，OOM支持包括GlusterFS在内的可插拔的持久化存储，为用户提供更多的存储选项。在多节点部署中，在可用资源和节点的选择上，OOM可以对业务部署进行更多的控制。最后，OOM现在支持整套k8s部署的备份/恢复，从而引入数据保护。

卡萨布兰卡版本引入了控制器设计工作室，将其作为控制器框架的一部分。它为ONAP控制器如何控制网络资源以支持业务提供了模型驱动方法。

可部署性：卡萨布兰卡版本延续了之前北京版本的7维指标体系（稳定性、安全性、可扩展性、性能，以及弹性、可管理性和可用性）。新的日志项目——Post Orchestration Model Based Audit（POMBA）可以检查设计模型和运行实例数据的偏差，从而提高网络业务的可靠性。包括Logging、SO、VFC、A&AI、Portal、Policy、CLAMP和MSB在内的许多其他项目，在性能、可用性、日志记录、迁移到云原生架构、身份验证、稳定性、安全性和代码质量等方面都有所改进。最后，集成在ONAP中的OpenDaylight和Kafka版本都更新到Oxygen和v0.11版本，分别提供P4和数据路由等新功能。

3. 微服务支持

作为由大量业务组成的云原生应用，ONAP的初始部署和运营管理十分复杂

ONAP的部署方法应足够灵活，以适应各种运营环境的不同场景和目标。用户可能希望只选择部分ONAP组件集成到他们自己的系统中。同时，ONAP平台应该是高可靠、可扩展、安全且易于管理的。为了实现这些目标，ONAP被设计为服务化的系统，其所有组件都通过Docker容器发布。

OOM负责协调端到端的生命周期管理和ONAP组件的监控。 OOM通过Kubernetes来提高CPU利用率并提供平台部署方法。另外，通过增强其管理组件的可扩展性和弹性，OOM有助于提升ONAP平台的成熟度。

OOM是ONAP平台的生命周期管理器，它利用Kubernetes容器管理系统和Consul提供以下功能：

部署 - 内置组件的依赖管理（包括多集群，跨站点的联合部署和反亲和性规则）配置 - 所有ONAP组件的统一配置监控 - 实时的健康监控，将监控的数据提供给Consul GUI和Kubernetes重启 - 启动失败的ONAP组件将自动重启集群和扩展 - 集群化的ONAP业务可实现无缝扩展升级 - 在轻微或不影响业务的情况下更换容器或配置删除 - 清除单个容器或整套部署OOM支持大量云基础架构，以满足您的个性化需求。

微服务总线（MSB）提供基础的微服务支持，包括服务注册/发现、外部API网关、内部API网关、客户端软件开发工具包（SDK）和Swagger SDK。MSB同时支持OpenStack（Heat）和裸机部署。当与OOM集成时，MSB有一个Kube2MSB注册器，它可以从k8s元文件中获取服务信息，并自动注册ONAP组件的服务。

4. Portal

基于用户角色，ONAP可以在设计态和运行态两种环境下提供统一一致的用户体验。在单个ONAP实例中可以对角色进行修改定制。

ONAP的Portal对用户体验进行管理，它通过共享的、基于角色的菜单或仪表盘，提了设计、分析和运营控制/管理功能的操作入口。Portal架构提供了基于Web的各种能力，包括应用的上线和管理、基于AAF的集中访问控制、仪表盘和托管应用程序小部件等。

Portal提供了SDK，可以使多个开发团队利用内置模块（服务/API/UI控件）、工具和技术满足其一致的UI开发需求。ONAP也为部分操作人员提供所需（例如：当他们需要与他们的脚本环境集成时）的命令行界面（CLI）。ONAP SDKs可以使运营/安全、第三方（例如：供应商和顾问）和其它领域的专家不断地定义/优化新的采集、分析方法和策略（包括纠正和补救行为的策略），他们通过使用ONAP设计框架的Portal就可以完成这些工作。

5. 设计态框架

设计态框架是一个全面的开发环境，它包括了各种工具、技术以及定义/描述资源、服务和产品的资源库。设计态框架有助于模型复用，随着可用模型规模的增大，可以更进一步地提高效率。资源、业务和产品，以及它们的管理和控制功能都可以使用一套控制行为和流程执行的规范和策略（例如规则集）进行建模。流程规范可以自动完成资源、业务、产品和ONAP平台组件的实例化、发布和生命周期管理。某些特定的流程规范和策略可以根据地理位置进行分发部署，从而提升混和云环境下的性能优化和自动化程度。

SDC提供定义/模拟/验证系统资产及其相关过程和策略所需的工具、技术和存储库。每一项资产都可以归到资源、业务、产品、要约等四类的一种。

SDC环境通过通用服务和实用程序支持不同用户。通过使用设计工作室，产品和业务的设计人员可以上线/扩展/下线资源、业务和产品。操作人员、工程师、客户体验经理和安全专家创建工作流、策略和方法，来实现闭环自动化/控制和管理弹性扩展能力。

为了支持和鼓励一个健康的VNF生态，ONAP在VNF供应商API、VNF SDK和VVP组件中提供一套VNF打包和验证工具。厂商可以在他们的CI（持续集成）/CD（持续交付）环境中集成这些工具，从而打包VNF，并将其上传到验证引擎。一旦经过测试，这些VNF就可以通过SDC上线。另外，VNFSDK的测试功能正在LFN合规性认证计划中使用，以确保采用高度一致的VNF验证方法。

Policy Creation组件用于处理策略；这些是必需提供、维护和/或强制执行的规则、条件、要求、约束、属性或需求。在较低层面上，策略包括机器可读的规则，使得机器可以基于触发器或请求采取行动。策略通常考虑实际应用中的特定条件（无论是在符合条件时触发特定的策略，还是采取特定的策略以接近特定的条件）。

策略允许通过更新规则进行快速修改，从而在不需要重写软件代码的情况下，更新使用这些策略的组件的技术行为。策略允许通过抽象简化对复杂机制的管理/控制。

CLAMP为闭环控制的设计和管理提供了一个平台。CLAMP用于设计一个闭环，针对某一项网络业务配置其特定的参数，然后部署和停止使用。一旦部署，用户可以在运行期间内更新控制环的参数，也可以暂停和重新启动它。

6. 运行态框架

运行态执行框架执行SDC分发的规则和策略。

运行态框架允许在不同的ONAP模块（例如SO，控制器，DCAE，A&AI）中分发策略实施、模板，以及一个安全的框架。这些组件都使用了支持日志、控制访问和数据管理的通用服务。新组件MUSIC允许平台注册和管理多个站点的部署状态。外部API为第三方框架（例如MEF、TM Forum等）提供访问接口，从而支持运营商BSS与ONAP相关组件间的交互。日志服务还包括基于事件的一致性校验功能，从而支持编排后的一致性分析。

编排

SO组件通过自动顺序执行按需创建、修改或移除网络、应用或基础架构业务和资源所需的活动、任务、规则和策略，从而执行指定的流程。SO在一个非常高的层次上进行编排，并提供基础设施、网络和应用的端到端视图。

外部API北向接口组件在BSS和各个ONAP组件间提供标准化的接口，包括Service Orchestrator，A＆AI和SDC。这样不需要通过长时间和高成本的基础架构集成，就可以在现有BSS / OSS环境中提供平台的抽象视图。北京版本及后续ONAP版本将持续增强和标准化组织间的合作，最终实现支持MEF、TM Forum等相关标准机构定义的运营商之间的交互用例以及其它用例。

VID应用可以使用户从SDC实例化基础架构服务及其相关的组件，并执行变更管理操作，例如对现有VNF实例进行扩展和更新软件。

策略驱动的工作负载优化

OOF提供一个策略驱动和模型驱动的框架，用于为各种用例创建优化应用。 OOF HAS是一个策略驱动的工作负载优化服务，可基于各种策略约束（包括容量，位置，平台能力和其它特定的业务约束）实现跨多站点和多云的业务优化部署。

ONAP MC和其它一些ONAP组件（如Policy、SO、A&AI等）在通过OOF-HAS实现跨云站点的“策略驱动的性能/安全感知的自适应工作负载部署/调度”中发挥了重要的作用。 OOF-HAS利用HPA和ONAP MC提供的实时容量检查，来确定最优的VIM /云实例，这些实例可以为工作负载（VNF等）的部署和调度（归属）提供所需的性能SLA。现在运营商在保障性能和安全SLA的同时，可以通过云资源的细粒度优化实现虚拟化的真正价值。这一特性已经在北京版本的vCPE用例中得到体现。

控制器

控制器是一些应用程序，这些应用程序将云和网络业务耦合，并执行配置和实时策略，以及控制分布式组件和业务的状态。运营商可以选择使用多种不同的控制器类型，来管理执行环境中与其分配的控制域中相应的资源，例如云计算资源（网络配置SDN-C和应用App-C），而不是仅使用单一的整体控制层。此外，VF-C提供符合ETST NFV标签的NFVO功能，并负责虚拟业务和相关物理的（CTOS）通用服务器基础设施的生命周期管理。VF-C提供通过的VNFM功能，同时也可以与外部的VNFMS和VIM集成，作为NFO MANO堆栈的一部分。

新项目MUSIC将记录和管理Portal和ONAP优化框架的状态，以确保跨地理分布的ONAP部署的一致性，冗余性和高可用性。

清单

A&AI提供系统资源、业务、产品及其相互关系的实时视图，在卡萨布兰卡版本中，它还保留了历史视图。A&AI提供的视图将多个ONAP实例管理的数据、业务支持系统（BSS）、运营支持系统（OSS）和网络应用进行关联，从而形成一个从终端用户购买的产品到形成产品原材的资源的自上而下的视图。A&AI不仅形成产品、业务和资源的注册表，还保持这些清单项目的相互关系的最新视图。

为了保证SDN/NFV的承诺的动态特性，当控制器在网络环境进行更改时，会对A&AI进行实时更新。A&AI是元数据驱动的，允许通过SDC产品目录定义快速地动态添加新的清单类型，从而避免冗长的开发周期。

多云自适应

Multi-VIM/Cloud为VIM /云提供基础设施适配层，除了标准功能外，还可以提供高级硬件平台的感知和意图功能，可用于OOF，以及为云无关工作负载部署增强云选择和SO/VF-C的其他组件。其中，意图功能是在卡萨布兰卡版本中新引入的。

7. 闭环自动化

闭环控制是由许多设计态和运行态元素间的协作完成的。运行态环始于DCAE，然后经过微服务循环（如用于事件检测的Homes、用于决定动作的Policy），最后由控制器和协调器实现动作。CLAMP用于监视这些循环自身。CLAMP、Policy和DCAE都可以在设计态中创建循环。

我们将这种自动化模式称为“闭环自动化”，是因为它提供了必要的自动化功能，可以在没有人工干预的情况下对网络和业务条件进行响应。图3是“闭环自动化”的高级示意图，显示了使用自动化功能后业务生命周期内的不同阶段。

闭环控制是通过DCAE和一个或多个其它ONAP运行态组件提供的。它们共同提供FCAPS功能。DCAE收集性能、使用情况和配置数据，提供分析计算，帮助排除故障和发布事件、数据和分析方法（例如向策略、编排器和数据湖发布）。另一个组件Holmes与DCAE连接，并为ONAP提供告警关联功能。在卡萨布兰卡版本中，DCAE可以利用PNDA支持新的分析功能，利用高容量VES和批量性能管理的支持可以提供新的数据采集功能。

通过与Policy Framework和CLAMP协作，这些组件可以检测网络中存在的问题，并确定适当的补救措施。在某些情况下，这个工作是自动的，并且它们会通知SO或其中一个控制器采取行动。在其它情况下，根据操作人员的配置，它们会发出一个警报，在人工干预后再执行操作。通过引入自适应的策略执行，policy framework得到扩展，可以支持其他策略决策能力。

8. 通用服务

ONAP为所有ONAP组件提供通用的运行服务，包括活动记录、报告、通用数据层、访问控制、弹性和软件生命周期管理。

这些服务提供访问管理和安全执行、数据备件恢复和修复。它们支持标准化的VNF接口和指南。

在虚拟化的环境中运行会引入新的安全挑战和机遇。ONAP通过在每个ONAP平台组件中嵌入访问控制来提供更高的安全性，同时专门设计用于检测和调整违规操作的分析和策略组件来进一步增强安全性。

9. ONAP建模

ONAP提供的模型有助于业务设计，ONAP服务组件的开发以及标准互操作性的改进。

模型是设计态和运行态框架开发的重要组成部分。ONAP建模项目利用成员公司、标准化组织和其他开源项目的经验，生成简单、可扩展和可重用的模型。目的是满足不同用例的需求，指导开发，保证ONAP组件间的一致性，并探索一个通用模型来提高ONAP的互操作性。

在卡萨布兰卡版本中，ONAP支持下列模型：

基于ETSI NFV IFA011 v.2.4.1的VNFD信息模型，根据ONAP的需求进行了适当的修改；基于TOSCA实现（基于IM）的VNFD模型，模型遵循ETSI NFV SOL001 v 0.6.0中相同模型的定义。基于ETSI NFV SOL004规范的VNF包格式。通过VFC（使用建模项目提供的解析功能）实现了网络业务描述符（NSD）。这些模型使ONAP可以与其它基于标准的实现进行交互，改善业界的协作。

10. ONAP蓝图

ONAP可以支持无限数量的用例。但是，为了提供如何使用ONAP解决实际问题的具体示例，开发社区已经创建了一套蓝图。除了通过端到端的解决方案帮助用户快速采用ONAP平台之外，这些蓝图还有助于社区优先处理他们的工作。随着ONAP卡萨布兰卡版本的发布，我们推出了两个新的蓝图：5G和CCVPN。之前的蓝图：vCPE、VoLTE和vFW/vDNS也已经移植到卡萨布兰卡版本。

5G蓝图5G蓝图是经过多个版本的努力的，卡萨布兰卡版本围绕PNF集成、边缘自动化、实时分析、网络切片、数据建模、归属、扩容和网络优化引入了第一组功能。eMBB（承诺20 Mbps的峰值速率）、uRLLC（保证亚毫秒响应时间）和MMTC（可支持每平方英尺0.92个设备）的组合为它带来一些独特的需求。首先，ONAP需要支持除VNF之外还包括PNF的网络业务。然后，ONAP需要支持边缘云场景，因为网络业务将不再局限于大型数据中心，而是会扩散到大量分布式边缘位置。最后，ONAP需要为分析和策略驱动的闭环自动化实时采集性能数据。这些需求引领了ONAP内部的一些方案，从而全面解决5G蓝图。

了解更多信息请阅读5G Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_5G_112118FNL.pdf

vCPE蓝图本蓝图针对住宅用例场景，向租户提供的业务目前限于宽带住宅网关中设计的服务。 在这个蓝图中，客户拥有一个纤薄的物理CPE（pCPE），它只包含桥接功能，连接到DSL或DOCSIS等传统宽带网络（如图5所示）。通过建立一条到托管各种VNF的数据中心的隧道，可以以低成本向租户提供更多的业务。ONAP通过包括两个关键组件：管理连接业务的SDN-C和管理虚拟化业务的APP-C，可以支持虚拟连接和底层连接的复杂编排和管理。在这种情况下，ONAP为端到端的业务提供了一个公共业务编排层。此蓝图展示了扩展，变更管理和HPA等高级功能。

了解更多信息请阅读Residential vCPE Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_vCPE_112918 FNL.pdf

VoLTE蓝图本蓝图利用ONAP编排VoLTE业务。本蓝图演示了移动业务提供商（SP）如何基于SDN / NFV部署VoLTE服务。VoLTE蓝图通过与边缘数据中心和核心数据中心之间的厂商组件（包括VNFM、EMS、VIM和SDN控制器）互通，整合商业VNF，以创建和管理底层vEPC和vIMS业务。ONAP通过几个关键组件支持VoLTE用例，具体包括SO、VF-C、SDN-C和Multi-VIM /Cloud。 在本蓝图中，SO负责与VF-C和SDN-C协作的VoLTE端到端业务的编排。SDN-C建立网络连接，而VF-C组件负责网络业务和VNF生命周期管理（包括业务启动、终止和手动扩展）和FCAPS（故障、配置、计费、性能、安全）的管理。

了解更多信息请阅读VoLTE Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf

CCVPN蓝图CSP（如CMCC和Vodafone）发现承载网络间对于高带宽、扁平、高速OTN（光传输网络）的强烈需求。他们希望为大客户提供高速、灵活和智能化的业务，并为中小型企业提供即时灵活的VPN业务。

CCVPN（跨域和跨层VPN）蓝图结合了SOTN（超高速光传输网络）和SD-WAN，它利用ONAP的编排能力，实现资源和业务的统一管理和调度。它实现了跨域编排和跨服务提供商的ONAP对等。ONAP多个关键组件支持CCVPN用例，其中包括：SO、VF-C、SDN-C、Policy、Holmes和DCAE。在本蓝图中，SO负责与VF-C和SDN-C协作的CCVPN端到端业务的编排。SDN-C建立网络连接，然后VF-C组件完成网络业务和VNF生命周期管理。跨运营商的ONAP对接使用的是东西向API，与MEF Interlude API保持一致。本用例的关键创新是物理网络的发现和抽象建模、跨多个物理网络的跨域编排、跨运营商端到端业务的开通以及跨域业务的闭环重路由。

了解更多信息请阅读CCVPN Blueprint：https://www.onap.org/wp-content/uploads/sites/20/2018/12/ONAP_CaseSolution_CCVPN_112818FNL.pdf

虚拟防火墙、虚拟DNS蓝图是验证ONAP正确安装，以及初步了解ONAP的基本演示案例。 本蓝图由5个VNF组成：vFW、vPacketGenerator、vDataSink、vDNS和vLoadBalancer。本蓝图展示了ONAP的大部分内容，包括VNF装载，网络业务创建，业务部署和闭环自动化。涉及的关键组件包括SDC、CLAMP、SO、APPC、DCAE和Policy。

11. 结论

ONAP平台为物理/虚拟的网络功能提供了一个实时的、策略驱动的编排自动化综合平台，这将使软件、网络、IT、云业务提供商和开发人员可以快速自动化的部署新的业务，并支持全生命周期管理。

联合ONAP成员的资源，聚焦开放的标准体系，借助全球共享的平台架构和网络自动化的实现，ONAP将比任何一个单独的产品更快速地发展成为一个充满活力的生态系统。

12. 资源

在Youtube和Youku上观看主要平台组件的相关视频。

阅读了解如何利用容器部署ONAP。

附：中英文对照表

1 operator 运营商

2 infrastructure 基础架构

3 performance 性能

4 deploy 部署

5 response 响应

6 recipe 流程

7 policy 策略

8 instantiation 实例化

9 provisioning 供应

10 view 视图

11 analytics 分析方法

12 dashboard 仪表盘

13 onboard 上线

14 corrective 纠正

15 remedial 补救

16 design time 设计态

17 execution time / runtime 运行态

18 repositories 资源库

19 retire 下线

20 process 流程

21 inventory 清单

22 create 创建

23 publish 发布

24 SDO 标准化组织

注：以下专用名词在译文中保持原文，以下翻译仅供参考。

1. SLA（service-level agreements）：业务质量

2. VIM（Virtualised Infrastructure Manager）：虚拟化基础设施管理器

3. VNFM（Virtualised Network Functions Manager）：虚拟化网络功能管理器

4. VNF（Virtualised Network Function）：虚拟化的网络功能

5. OSS（Office of Strategic Services）：运营支撑系统

6. SDC（Service Design and Creation）：业务设计和创建模块

7. SDK（Software Development Kit）：软件开发工具包

8. Policy Creation：策略制定

9. CLAMP（Closed Loop Automation Management Platform）：闭环自动化管理平台

10. SO（Service Orchestrator）：业务编排器

11. DCAE（Data Collection, Analytics and Events）：数据采集、分析和事件模块

12. A&AI（Active and Available Inventory）：活跃和可用清单

13. VF-C（Virtual Function Controller）：虚拟功能控制器

14. FCAPS（Fault Configuration Accounting Performance Security）：故障、配置、计费、性能、安全

15. Policy Framework：策略框架

16. OOF（ONAP Optimization Framework）：ONAP优化框架

17. OOM（ONAP Operations Manager）：ONAP运行管理模块

18. MSB（Microservices Bus）：微服务总线

19. VVP（VNF Validation Program）：VNF验证程序

20. MUSIC（Multi-Site State Coordination）：多站点状态协调

21. VID（Virtual Infrastructure Deployment）：虚拟基础架构部署

22. HAS（Homing and Allocation Service）：归属分配服务

23. MC（Multi-VIM / Cloud）：多VIM/云

24. HPA（Hardware Platform Awareness）：硬件平台感知