点击查看第一章
点击查看第二章

第3章

ONAP架构设计
本章首先介绍ONAP架构在设计之初的目标与理念，包括要解决什么问题、需要具备哪些核心能力、相应的架构设计理念和设计原则是什么等。对于模型驱动等重要设计原则，还辅以具体示例，包括ONAP的实现流程与模型定义示例。理解这些设计理念与原则后，再一步步介绍ONAP的架构、ONAP的各组件与项目归类。最后介绍ONAP是如何构筑安全与可信的代码质量的，包含思路与落地方法等。
本章会涉及软件开发与过程管理的常见术语，但会尽量以通俗易懂的方式进行介绍，具有一定的开发经验的人理解本章内容会更容易些。

3.1　ONAP架构理念

相对以往OSS架构，ONAP架构理念有如下创新点：

• 借鉴了互联网软件设计的先进理念，提出设计态与运行态的概念。
• 基于模型驱动的设计框架，在ONAP各项目中落地数据驱动能力，同时提供一个策略驱动的运营管理平台，支持根据资源占用与故障情况，动态实现闭环自动化。
• 考虑到部分运营商可能面临的复杂场景（覆盖服务、网络、云交付等全生命周期），ONAP设计了分层的自动化框架，分别提供跨域、无状态的“编排器”项目，以及面向单领域，有状态进行编排控制的、更高效的“控制器”项目，所有模块都是服务化设计，方便按需定制与部署。

在上述基础上，还借鉴了软件领域的优秀架构设计理念与原则，最终的ONAP架构蓝图是所有这些有机结合的产物。社区专门成立了ONAP架构委员会，负责管理架构理念和原则。本节将介绍如下重要设计理念：业务无关的平台（Vendor & Service Agnostic厂商与业务无关）、开放性、闭环自动化及DevOps的理念。

3.1.1　业务无关的平台

ONAP定位为自动化使能平台，要能让不同运营商根据自身需要灵活定制，而不受具体厂商、业务、场景的限制。社区UseCase的目标主要是展示ONAP作为平台的能力，并不追求开发面向特定场景的完整功能实现。也就是说，ONAP不像Linux或OpenStack那样，版本发布后就是一个直接可用的软件产品，或可直接用于特定网络上，开展与UseCase对应业务的生产化部署；ONAP的版本发布仅表明已在特定UseCase下验证了ONAP作为平台的功能，商业部署仍须在此基础上进行开发与定制。不同版本的功能增强，原则上由UseCase驱动开发，但在具体实现中，会将UseCase特有实现（插件、业务定义，策略定义等）与平台实现分离。社区也创建了CLAMP项目，专门保存UseCase特有的闭环设计输出。

3.1.2　开放性

社区致力于创建一个开放可编程的软件生态，体系结构支持随时采用业界最佳组件、部件（不耦合特定软件产品或云平台环境或特定编程语言或编程框架），ONAP各模块也都设计成可插拔的，以方便替换与升级。当前ONAP涉及的编程语言超过50种，既有常见的Java、JSON、JavaScript、C、Python等，也有Go、Lua、Erlang等。编程框架有Spring、Sphinx、Hibernate、Tomcat、ODL、OSGI等多种。当然社区也在牵引归一化，以减少学习与维护成本，比如推动相似的数据库归一，如MySQL、PostreSQL、MariaDB。
开放性的另一个隐藏理念则是“共享”：常用功能或组件鼓励开发成“一次开发、多次使用”，避免重复开发，鼓励在前人基础上进行开发，比如CCSDK项目（控制器层公共服务Common Controller SDK）目的就是将不同领域控制器中的可重用组件与服务汇总起来，以便根据需要定制出符合自身要求的控制器，简化与加速领域专用的控制器开发。

3.1.3　闭环自动化

CloseLoop闭环自动化（或叫闭环控制）在工业、科研等很多领域都有定义。在ONAP语境中，闭环自动化表示端到端、无人工介入、全流程自动化，且支持动态变更。它是由许多设计态和运行态元素间的协作完成的。运行态闭环始于DCAE（接收相应事件），然后经过微服务循环（如用于事件与拓扑关联的Homles项目、用于决定动作策略的Policy项目），最后由控制器和编排器执行对应动作。CLAMP用于监视这些循环本身。CLAMP、Policy和DCAE都可以在设计态中创建循环。
图3-1是闭环自动化示意图，显示了使用自动化功能后业务生命周期内的不同阶段。

闭环控制是通过DCAE和一个或多个其他ONAP运行态组件共同提供的能力。闭环控制的目标是将日常运维中的FCAPS功能自动化（Fault Management，Configuration Manage-ment，Accounting Management，Performance Management，Security Management，故障管理、配置管理、计费管理、性能管理和安全管理）。其中DCAE负责收集性能、告警、使用情况等事件，并结合A&AI中的拓扑与配置数据等，应用可在这两类数据基础上作进一步分析，比如DCAE的子组件Holmes可提供告警或事件与拓扑对象的关联功能。得到的分析结果再向策略、编排器等系统发布，后者将决定执行相应动作。
在Casablanca版本中，DCAE可以集成PNDA以支持新的分析功能，利用高容量VES和批量性能管理特性来增强数据采集功能。
通过与策略框架、CLAMP协作，ONAP可以检测网络中存在的问题，并确定适当的补救措施。在某些情况下，这个过程是自动的，会通知SO或某个控制器采取行动。在其他场景中，根据操作人员的预先配置，它们会发出一个警报，在人工干预后再执行操作。策略框架支持对策略的动态刷新，框架本身也支持扩展以便与其他策略决策系统协同。
自愈或扩缩容等修复动作执行完后，ONAP会继续对业务进行监控，以保证故障已自动排除或需要其他处理，整个过程也将被记录为事件。
ONAP闭环自动化也可理解成一种可以分层实施的理念，比如在单ONAP中就存在SO专门负责业务级别的编排，以实现业务实例化、业务变更、全局优化部署等的闭环自动化。而对应的Controller控制层则负责控制资源的闭环自动化，包括本地资源的分配、回收、调整、扩缩容等。不同领域的控制器可分别负责域内的闭环自动化。
在实际网络场景中还可存在邦联部署的场景。比如，国干网中的SO负责跨省的端到端业务编排，而子域SO则负责省内的业务闭环自动化。子域业务还可分解，进行子域的资源控制器中的闭环自动化控制。

3.1.4　DevOps一体化设计

在软件开发生命周期中，遇到了两次瓶颈。第一次瓶颈是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，后来出现了敏捷方法论，强调适应需求、快速迭代、持续交付。第二个瓶颈是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps（Development和Operation的组合词）研发运营一体化。DevOps是一组文化、流程与工具整合后的统称，基于敏捷与精益的理念，从业务和整个价值链角度，推动组织优化软件交付方式，从敏捷开发，走向敏捷运维和敏捷业务。
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使构建、测试、发布软件能够更加快捷、频繁和可靠。DevOps提倡打破孤岛，促进开发和运维之间高度协同，在实现小批量迭代交付、增量式发布、高频率部署、快速闭环反馈的同时，提高生产环境中软件部署及运行的可靠性、稳定性、可伸缩性和安全性。
DevOps的三大原则：
1.基础设施即代码（Infrastructure as Code）
DevOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等。
2.持续交付（Continuous Delivery，CD）
持续交付是在生产环境中发布可靠的软件并交付给用户使用。持续部署则不一定交付给用户使用，其涉及两个时间—TTR（Time to Repair，修复时间）和TTM（Time To Market，产品上线时间）。要做到高效交付可靠的软件，需要尽可能减少这两个时间。部署可以有多种方式，比如Blue/Green Deployment（蓝绿部署）、Rolling update（滚动部署）、金丝雀部署等。

• 蓝绿部署：意指有两套系统，一套是正在提供的服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善且正在运行的系统，在独立集群环境中运行，一次只有一个系统对外提供服务，另一系统用于发布前的验证、修改等（不干扰用户）。升级过程中不停止老版本，在新环境中部署新版本，然后进行测试，确认没问题后，将流量切到新版本，然后再把老版本升级到新版本。优点是可减少发布时的中断时间，能够快速撤回发布（切换环境即可）。
• 滚动部署：一般是取出一个或者多个服务器对其停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。它相对于蓝绿部署，更加节约资源—不需要运行两个集群、两倍的实例数。可以部分部署，例如每次只取出集群的10%进行升级。
• 金丝雀部署：又称灰度发布，这和蓝绿部署有点像，但可以进一步规避风险。强调阶段性升级或切换，而不用一次性从蓝色版本切换到绿色版本。即：在生产环境的基础设施中小范围地部署新的应用代码。一旦应用签署发布，只有少数用户会路由到它，此时多数用户业务流量仍流向老版本。在此过程中观察影响，如果没有错误发生，新版本可以逐渐推广到整个基础设施。当前这种部署方式被云服务提供商，比如网游公司广泛采用，以验证用户对新特性的接受情况。当然这种方式主要挑战在于如何设计一种方法以便路由部分用户到新应用。发布示意如图3-3所示。

注释：矿井中的金丝雀
17世纪，英国矿井工人发现，金丝雀对瓦斯气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，人类毫无察觉但金丝雀可能已毒发身亡。因此当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
3.协同工作（Culture of Collaboration）
开发者和运维人员必须定期进行密切合作。开发应该把运维人员理解成软件的另一个用户群体。协作有如下几个建议：

• 自动化（减少不必要的协作）；
• 小范围（每次修改内容不宜过多，减少发布的风险）；
• 统一信息集散地（如Wiki，让双方能够共享信息）；
• 标准化协作工具（比如Jenkins）。

ONAP构造了完整的CI/CD环境，包括：所有项目都采用Docker容器发布，并统一采用OOM实现部署管理（短期还同时支持Heat部署方式），采用JIRA跟踪所有问题，采用Jenkins实现持续部署管理。

3.2　架构设计原则

为了实现以上设计理念，ONAP借鉴了诸多业界软件设计原则，本章重点介绍其中最重要的几个原则：模型驱动、微服务化及云原生。鉴于这几个术语在软件领域被普遍使用，可能有不同的理解，因此在本节中，除介绍业界通用理解外，也会补充描述ONAP对设计原则的特有理解与定义。

3.2.1　模型驱动

介绍模型驱动前需要介绍一下什么是模型。模型是对“事物”的一种抽象化表达，从特定角度对系统进行描述，省略部分不重要的细节，聚焦感兴趣的特性。
模型驱动在软件开发领域有多种表达方式，如MBD（Model Based Development，基于模型的开发）、MDD（Model Driven Development，模型驱动开发）和MDA（Model Driven Architecture，模型驱动架构）。其主要核心都是从模型生成代码和其他开发过程中的组件，在解决领域问题的同时，提高生产效率，比如：发生变更时，软件设计不变或变更较少（模型不变）。与之对应的传统开发方式则是硬编码（即使用编程语言C、C++、Java、Python等编写代码）。但从本质上来说，只要是进行变更，肯定需要某人/某个APP在某个地方进行某些修改，这样才能让变更真正生效。
模型驱动的修改与硬编码方式的修改真正的差异在于：谁负责修改，改什么（包括在哪修改），影响多大。对于传统硬编码方式而言，所有变更都需要由原软件提供者（即Vendor软件供应商）来修改，且需要在实际产品代码上修改，包括重新编译、发布、打包等开发环节，再经过商业交付流程提供给使用者。而使用者则在此过程中则只能等待，等待供应商提供修改后的版本，然后再经过入网测试、升级部署等流程后才能在实际网络中使用。这样的方式不仅代价大、周期长（一般以月为单位），而且多数情况下，产品升级时还需要将系统关机重启，影响较大。如果整个过程中发生任何问题，包括理解上的差异，很可能需要从头再来。
而对于模型驱动的平台架构，能做到对多数变更，但平台开发者（供应商）不需要参与代码修改，平台本身也不需要停机、重新编译、发布等开发过程。而是由使用者/用户通过修改外部（相对平台代码而言）的模型文件（TOSCA或YANG等）或插件（可能包括JavaScript、Python等动态语言）即可动态生效，这一开发过程在ONAP中被称为设计。当然为了实现这一点，需要提前定义一些约定：模型的格式（模型文件应该如何描述）和模型生效的流程（模型如何加载、生效，如果中间出现错误如何处理等）。多数模型驱动的架构还会提前定义一些预定制的元模型或领域模型示例，以简化学习门槛，加速在指定领域中的应用。
在本节中，模型驱动表达的意思是，ONAP支持在不需要修改ONAP自身框架代码的前提下，通过对模型做组合/变更（新增，删除或修改），实现电信业新业务的上线或更新。一般是通过修改某些脚本及动态加载部分插件或驱动来实现的。
模型驱动并不意味着业务变更完全不需要修改代码，只是不需要修改ONAP框架代码，即分为两部分：一部分负责对平台的修改（尽可能少甚至不需要），平台的设计人员不参与；另一部分是（在多数场景下）负责新业务发放的业务设计员通过对模型的组合与修改完成的（也可能包括一些脚本的开发）。
ONAP各组件是元数据驱动和策略驱动的，以确保功能和特性能灵活使用和交付，支持动态增加或变更，而且作为面向电信领域的开源社区，也有利于定义面向电信自动化领域的相关模型规范。具体体现在以下几方面：

• 全局数据结构：ONAP的全局数据结构都定义在Schema文件中，文件名类似aai_schema_v15.xsd（早期Amsterdam版本中的数据模型版本是V8与V9，最新的Casablanca版本已升级为V15了），正常情况下，在SDC中每次修改模型的定义（不是模型对应的实例，比如在网元中增加一个“名称”属性等），则SDC会自动触发模型文件的版本递增，ONAP的A&AI支持多个版本的模型文件并存。ONAP社区版本发布时都会指明具体对应的模型文件版本号，并将运行态分发到各需要访问模型的组件实例下。也就是说，ONAP在代码层面并不固定描述用户、网元或设备的数据模型，即没有硬编码定义这些对象的结构，而是采用Schema脚本进行描述。因此，在需要变更（比如增加对象或某对象增加属性定义）时，只要在设计态修改对应Schema脚本，并分发到运行态涉及的组件中即可。在全局存量系统A&AI启动时会自动加载Schema文件，并在数据库中创建对应的表结构与关系。
• 各资源构件：各资源构件（网络或业务的定义，如BPMN与Policy等）都保存于可重用资源库目录中，方便动态支持资源上线、服务的定义和创建，且支持通过由更简单的、可重用的资源构件组合成复杂业务。
• ONAP平台自身：ONAP自身特异性也采取类似的元数据驱动的方式实现。比如从ONAP的Casablanca版本开始，在CCSDK项目中启动CDS（Controller Design Studio），通过设计与定义不同的控制器蓝图（Controller Blueprints），即可帮助运营商根据需要灵活定义Controller模板（比如将有线与无线融合到一个Controller，或者分成不同Controller）。策略驱动在不同层次或领域闭环机制中都有应用，以实现对云、网络和业务的实时自动化控制。

1.常见模型
常见模型包括业务模型、概念模型、数据模型、对象实例（物理数据模型）和元模型等，分别表示从现实世界到信息世界的不同层次的抽象。

• 信息模型、业务模型、概念模型：可简略记成IM（Information Model，信息模型），其为对现实世界中真实事物的描述，不涉及具体软件实现，例如员工、合同、客户、网络、站点、设备等；也包括这些抽象概念之间的关系，比如站点中“包含”设备、而交换机“属于”某种设备等。
• 数据模型：可简略记成DM（Data Model），这是对业务模型/概念模型的进一步分解和细化，包括所有的实体（抽象代表一类对象，如员工代表所有具体的员工）和关系（实体间的关系）。需要确定每个实体的属性，定义每个实体的主键，指定实体的外键，并进行范式化处理。一般在软件设计中定义对应的数据/对象结构，比如员工包括工号（字符Char(8)）、姓名（最长20个字符的可变字符串varchar(20)）、年龄（数字integer）和出生日期（日期date）等。
• 对象实例：英文一般为Instance（实例），用于在数据模型基础上定义每个具体的独立对象，比如定义员工的数据模型，此时某个具体员工A的工号是00123456，则员工A就是一个实例。
• 元模型（Meta Data）：即模型的模型，是模型驱动设计更高一层次的抽象。一般针对特定领域的模型定义抽象概念（元模型），并用其构建该领域中具体数据模型。比如，在网络领域IPV4（形如“10.10.10.10”的32比特的对象）或IPV6（形如“1:123::ABCD:0:1/96”的128比特的对象）可作为元模型，然后用它来表示新的模型对象，比如VPN（每个接入点都可以是IPV4/IPV6的IP地址）。

目前很多领域都有自己特有的模型及模型语言，如前文所述，ONAP致力于创建一个开放、可编程的软件生态，支持业界最佳组件，而非一切重新开始，重新发明轮子。因此，ONAP自身也采用了多种模型，比如面向业务与VNF生命周期管理的TOSCA语言，面向网络层配置管理的YANG语言，内部数据库建模又采用XML Schema语言等。下面就一一介绍。
2.常见模型语言
1）XML
XML（Extensible Markup Language，可扩展的标记语言）是1998年2月由W3C（World Wide Web Consortium，万维网联盟）正式批准定义的标准通用标记语言。“标记”指计算机所能理解的信息符号，通过标记，计算机之间可以处理包含各种信息的文章等。如何定义这些标记？既可以选择国际通用的标记语言，比如HTML（HyperText Markup Language，超文本标记语言），也可以使用像XML这样由相关人士自由决定的标记语言，这就是语言的可扩展性。XML是从SGML（The Standard Generalized Markup Language，标准通用标记语言）中简化修改出来的。XML是一套定义语义标记的规则，这些标记将文档分成很多部件并对这些部件加以标识。XML也是元标记语言，即为定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。
直白解释就是，XML是一种规则，其把一个文档划分为不同的层次或部分，并对这些层次或部分做好标记。这个文档是能支持不同领域的（比如文学、物理、化学、音乐等），不同领域的文档可定义其特有的领域语言（也用XML定义）。XML文档的字符分为标记（Markup）与内容（content）两类。标记通常以“<”开头，以“>”结尾；或者以字符“&”开头，以“;”结尾；不是标记的字符就是内容。
XML有如下几个特征：

• 内容与形式分离，其设计宗旨是传输和存储数据，而不是显示数据。
• 良好的可扩展性，标签没有被预定义，需要自行定义。
• 被设计为具有自我描述性。
• 遵循严格的语法要求。
• 便于不同系统之间信息的传输，是W3C的推荐标准。

一个简单例子如下：

以图的方式表达更好理解一些，如图3-4所示。以上XML脚本描述的是一个学生，记录了学生如下信息：年龄、姓名和学校。其中的学生、年龄等即为自定义标签（tag）。

2）XML Schema
上面的XML例子中，虽然可以描述一个对象（通过自定义标签），但对于计算机处理来说可能还是不够的，只能说明它是语法正确—术语称为well-formed XML，但不一定合法—术语称为validating XML。
比如年龄这个标签，在计算机处理中还需更进一步严格定义：数据类型是一个数值，而不是字符串。显然，说年龄是10（岁），这是合法的（一个数值）；而把年龄说成一个字符串OK或“非常大”，则是非法的。
为了约束一个字段或者说为了约束XML的类型，就有了XML Schema（XML Schema Definition，XSD），它是一套W3C标准，即为用于XML的模式定义语言，其作为关联的文档来定义XML标记规范。
以下是一个对Age进行约束的例子。Age这个标签（XML又称元素，即element）有如下定义/约束：

• value必须是整型（xs:integer）。
• 值范围必须是7～50。

3）YAML
YAML（Yet Another Markup Language，另一种标记语言）是一种以数据为中心的标记语言，官方定义为一种人性化的数据格式定义语言。数据组织主要依靠的是空白、缩进、分行等结构。YAML相比XML有如下优点：

• 可读性好。
• 和脚本语言的交互性好。
• 使用实现语言的数据类型。
• 有个一致的信息模型。
• 易于实现。

比如上面那个学生的例子，用YAML语言表述如下。

由于YAML有较好的可扩展性与可读性，相比XML编码效率更高，在特定场景下具备明显优势。比如常用的动态语言（Python、Ruby等）就支持用YAML定义的数据结构与数据类型。一些常见IT工具也使用它来定义模板，比如OpenStack的Heat和AWS的CloudFormation、SaltStack、Puppet、Chef。
一个环境描述的Heat实例（包括对Nova、Database、Chef的定义）如：

4）YANG
YANG是IETF在RFC 6020中定义的用于网络配置的数据模型描述语言，支持NETCONF接口协议，实现了网络配置的标准化，是一种DSL（领域特有语言）。
NETCONF协议（NETwork CONFiguration Protocol）是一个网络配置管理协议，是由IETF标准组织定义的一套管理网络设备的机制。用户可使用这套机制增加、修改、删除网络设备的配置，获取网络设备的配置和状态信息。
YANG与XSD（XML Schema Definition）基本是等价的，也即YANG是一种Schema定义的语言，而不是像XML/YAML一样为了数据的传输和存储。
YANG从设备维护的角度，将数据的层次结构模型化为一棵树，树中每个节点都有名称，且要么有一个值要么有一个子节点集，其还给节点提供了清晰简明的描述，同样提供了这些节点间的交互。相比XML Schema，YANG语言定义的数据模型没有晦涩的内容，可读性好、简单易懂、可扩展。当前YANG已在设备配置领域被普遍接受，IETF、ONF等标准组织都要求提交的模型用YANG来写。其他组织，如Openconfig，OpenDayLight等也普遍支持YANG。
下面为用YANG定义的一个RPC（远程进程调用）的示例，表示一个activate-software-image的远程调用方法，输入是一个string参数image-name，输出是string类型的status：

5）TOSCA
TOSCA全称是Topology and Orchestration Specification for Cloud Applications，是一种数据建模描述语言，是由OASIS组织（https://www.oasis-open.org/）制定的面向云计算环境中的应用拓扑和编排描述语言，目前支持YAML和XML实现。
TOSCA的基本概念有两个—节点（node）和关系（relationship），且都可通过程序来扩展，同时TOSCA规范中也支持Plan（即Workflow工作流文件）。
（1）节点预定义了很多基础类型，包括云基础设施中常用的计算节点、网络节点、数据库节点等。
（2）关系定义了node之间的关系，具体如下：

• DependsOn（依赖于）：表示节点间的顺序依赖关系，一般影响实例化过程中的创建顺序，比如A节点依赖于B节点，则在创建A对象前须提前创建B。
• HostedOn（运行于）：比如“MySQL数据库”与“计算机”的关系就是HostedOn的关系，即数据库运行在计算机上。
• ConnectsTo（连接）：表示连接关系。

TOSCA面向云计算环境中的应用拓扑和编排场景来预定义一些属性，因此一般认为较适合用于解决以下场景中的需求：
（1）自动化的软件部署和管理。
（2）应用生命周期（安装、扩容、卸载等）管理方案的可移植性（注意：不是应用本身的可移植性）。
（3）组件之间的互操作性和重用性。
注意：OpenStack中的Heat子模块也是基于TOSCA标准的。
考虑到YANG、TOSCA都具备较强的扩展能力，个人认为语言本身没有本质区别，也不存在谁一定更适合某领域的说法，这更多是不同领域习惯的差异问题。IETF、OASIS等组织也都在不断扩展两种语言。
比如，NFV领域的VNFD，就是以TOSCA描述文件（可以是YAML或XML格式）进行说明的，包括安装软件过程中都有哪些组件、组件之间有什么依赖关系等；当然，实际运行时还需要用TOSCA运行态环境来对TOSCA文件进行读取（分析文件的语法、语意）和解释执行（进行具体的软件安装、配置工作）。
一个TOSCA描述文件（称为Service Template）示例：在遵循TOSCA 1.0和描述信息description之外，还需要遵从拓扑模板，包括一个名为my_server的节点，类型是tosca.nodes.Compute。该类型预置了两个capabilities信息，一个是host，定义了硬件信息；另一个是os，定义了操作系统信息。

TOSCA脚本还可用于表达对输入、输出的建模。比如，以下就定义了一个新节点类型—tosca.nodes.DBMS.MySQL。该类型允许接收root_password和port的参数。在requirements里定义了mysql这个节点，该节点需要被安装到db_server节点上，这就是“关系”。

ONAP SDC项目使用TOSCA来描述Serivce业务、Resource资源对象，而且定义了一些电信运维领域的资源/管理对象（CP连接点connection Point，VL虚拟连接Virtal Link等），以简化设计。
由图3-5所示可看出，一个vIPR ATM service包括两个Node：一个VNF（vIPR ATM VF），一个外部网络VL连接（vIPR ATM OAM Net）。当然，真正的场景中业务可能会复杂得多，如多VNF及多VL连接等。VNF自身也可能是更细粒度的对象，只不过是以模型方式组合而已。比如上例中，VNF（vIPR ATM VF）由更小的VFC、VL及CP组成。示例模板如图3-6所示。

3.模型设计示例
由于对象之间存在复杂关系，且不同对象可分别对应不同模型文件，因此在OASIS组织中就定义了一种把多个模板文件以特定方式组织并进行Zip打包后的存档包格式，即CSAR云服务存档（Cloud Service Archive）。它支持云应用程序生命周期执行和管理所需要的文件，包含不同类型的多个文件（英文叫artifacts）。这些文件通常组织在几个子目录中，每个子目录包含的文件都是相关的（可能还有其他子目录）。

每个CSAR必须包含一个所谓的清单文件。此文件名为manifest，文件扩展名为.mf。它表示CSAR中其他文件的元数据，这些元数据以“名称/值”对的格式提供。
一个ONAP的CSAR文件示例结构如图3-7所示，商用部署场景下还可能包括License文件、metadata元数据目录等，CSAR架构细节定义可参见https://wiki.onap.org/display/DW/Csar+Structure 。

CSAR文件是ONAP中模型上线、校验、分发的原子单位，且每次对模型进行修改变更之后，都必须修改模型版本号。
ONAP支持多种DM格式，如Heat、TOSCA、YANG等，但内在的IM信息模型是保持一致的，即从VNF厂商提供CSAR包开始，ONAP可能会对DM做一些映射与转换，但因为有统一的IM模型，因此屏蔽了厂商差异，如图3-8所示。

VNF网元供应商需要按VNF SDK项目的要求准备好相应的CSAR文件，其中最重要的就是VNFD文件（VNF Description，VNF描述文件），它不仅定义了VNF的基本情况信息（名称，版本号，供应商），还明确了VNF对计算、存储、网络等基础设施的细节要求，以及支持哪些操作、如何操作对应的工作流文件等。然后将准备好的文件按VNF SDK项目的要求，进行自动化测试验证，之后即可加入ONAP的设计态目录，并被ONAP系统使用（这称为onboarding上线）。ONAP在编排过程中，可能会根据各项目的需要对相应DM数据模型做一些转换/处理，比如，SO与Controller可能将类似信息保存到不同数据结构中，但整个IM信息模型在整个ONAP中是共享的。在ONAP的A&AI全局数据库中，尽量采用通用的DM定义，比如，业务实例定义可表示任何业务，即原则上并不会因为新增了一个领域的业务，或新增对某厂商VNF的支持而要求A&AI修改数据库结构定义。
具体流程如图3-9所示（参见https://wiki.onap.org/display/DW/Onboarding+Services+into+ SDC+and+Instantiating+through+VID）。

步骤1　在VNF SDK中验证VNF/CNF。
VNF SDK验证通过的VNF/CNF（Containized Network Function容器化的网络功能）会将相关CSAR文件自动加入SDC目录中，并作为资源等待处理。
步骤2　通过SDC界面进行相关设计。
用户在SDC的GUI界面中设计生成对应的模板文件，包括在界面上import导入外部的资源模型文件（上一步中VNF/CNF的TOSCA CSAR包）。
在SDC设计界面中设计资源与业务，及其之间的映射关系，如VF、Service等，并将其加入SDC目录中（可用于后续基于此做更改或进一步设计封装）。
将所有设计结果导出为对应的csar包（包括生成对应的版本号），并提交测试验证。
此时由负责测试和校验的用户角色登录SDC，测试人员与校验人员完成测试和校验后（线下方式等），进入SDC中审核并让流程进入下一环节。如果此环节发现问题，可返回。
步骤3　设计结果通过SDC分发引擎分发到运行态各组件。
管理员进入SDC后，可点击Distribute将模型文件从设计态向运行态的各实例分发（运行态各实例之前就已在DMaap总线注册了要监听的模型文件类型），相关SDC Message Broker分发总线则会根据注册情况，发送通知给相应运行态实例。
各运行态组件实例（SO、A&AI、Controller等）收到通知后，会主动从SDC目录中获取设计态中已完成的模板文件—CSAR包及对应的Artifacts交付件，并将之导入自身目录中。此时运行态组件即支持了新的模型对象，等待上层OSS或GUI界面对业务进行实例化。
4.模型定义示例
举例而言，Device设备的定义如下：包括device-id属性、esn号、device name设备名称、Description设备描述、Vendor供应商、Classic分类等。在A&AI全局数据库中的定义如图3-10所示。

打开Schema文件，仅须关注Device类。以属性device-id和esn号为例，对应描述如下：

Schema文件基本上是自解释的，可看出device-id属性和esn号都为String字符串类型，目前没为其指定默认值，其Description字段中简要描述了属性的含义。
对应的aai_schema_v15.xml则根据Schema文件自动生成Java语言定义的XML文件，具体如下：

最后的ref="tns:relationship-list"字段代表与Device对应的对外引用关系列表，这是ONAP模型定义的一个常见的基础属性类型，因为ONAP的A&AI系统是基于图数据库系统设计的，因此支持根据不同的relationship从一个对象查询相关联的对象。比如，查询在一个AZ内，属于某个特定租户的所有VM的所有网卡上的IP地址列表。如果是传统关系型数据库，则很可能需要一个非常复杂的App才能完成。有了图数据的关系，采用Traverse查询方式，通过一条命令即可返回结果。
图3-11所示可简要解释关系列表的组织，它可包括一系列的关系relationship，而每个关系又有指向的对象、关系的Label描述、Link、关系对应的Key/Value对及属性等。

对应Schema文件定义如下（"relationship-list"是"relationship"的List列表对象）：

3.2.2　微服务化

服务化架构（Service-Oriented Architecture，SOA）是一种粗粒度、松耦合的以服务为中心的架构，服务之间通过定义明确的协议和接口进行通信。这里说到的“服务”，本质上来说就是指RPC远程程序调用。面向服务架构（Service-Oriented Architecture，SOA）是Gartner于20世纪90年代中期提出的概念，主要面向分布式系统的开发。多数是遵从著名SOA专家Thomas Erl的归纳：

• 标准化的服务契约（Standardized service contract）。
• 服务的松耦合（Service loose coupling）。
• 服务的抽象（Service abstraction）。
• 服务的可重用性（Service reusability）。
• 服务的自治性（Service autonomy）。
• 服务的无状态性（Service statelessness）。
• 服务的可发现性（Service
  discoverability）。
• 服务的可组合性（Service composability）。

这些原则要达到的目的是：提高软件重用性，减少开发和维护的成本，最终增加业务的敏捷度。
微服务架构则是一种服务化架构，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立部署到生产环境、类生产环境等。
微服务的诞生并非偶然。它是互联网高速发展，敏捷、精益、持续交付方法论的深入人心，虚拟化技术与DevOps文化的快速发展，以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物，涉及业务、开发、测试、部署、运维等多个环节。但具体拆分到什么粒度才叫微服务，业界并没有明确量化的标准，需要根据业务上下文、团队、流程实践等共同衡量后定义的。
具体到软件开发中的实现技巧，推荐参考PaaS先驱Heroku公司的CTO Adam Wiggins提出的“微服务12因子”的理念（https://12factor.net/zh_cn/）。
SOA与微服务架构在很多地方是重合的（可以混用）。如果要区分的话，SOA关注的是服务的重用；微服务则在关注服务重用的同时，也同时关注快速交付。
ONAP架构支持微服务化，各项目都分成多个独立服务，可单独部署。服务之间的通信经由DMaap或MSB项目（都是基于Kafka构建的服务），支持弹性缩放和CI/CD环境的集成。

3.2.3　云原生设计

什么叫云原生（Cloud Native）？历史上有多个定义。2010年，WSO2的联合创始人Paul Fremantle在业界最早提出Cloud Native，认为其有如下几个关键特征：

• Distributed/Dynamically wired，分布式/动态连接。
• Elastic，弹性。
• Scale down as well as up, based on load，基于系统负载的动态伸缩。
• Granularly metered and billed，粒度合适的计量计费。
• Pay per user，按使用量计费。
• Multi-tenant，支持多租户。
• Self service，支持自服务。
• Incrementally deployed and tested，支持增量的部署与测试。

云原生系统的效果应该是更好地利用资源，更快地提供资源，更好地管理。
在2013年，AWS的云战略架构师，同时也是NetFlix的云架构师Adrian Cockcroft提出对Cloud Native新的定义：基于不可靠的、易失效的基础设施（ephermeral and assumed broken components）构建高度敏捷（high agile）、高可用（highly available）的服务。
2015年，Google联合其他20家公司宣布成立了开源组织Cloud Native Computing Foundation（CNCF），开源了Kubernetes。Kubernetes是一个以应用为中心的容器编排、调度集群管理系统，希望成为CloudNative Application的基石。从CNCF组织来看，Cloud-Native Application应该包含微服务、容器、CI/CD特征。
根据一般的理解，Cloud Native背后的软件架构需求有：

• 按需特性的伸缩。
• 按特性持续演进。
• 应用快速上线。
• 系统高可用。
• 全面解耦合。
• 系统自服务。
• 支持多租户。
• 异构公有云。

ONAP当前支持在OpenStack及微软Azure上运行，未来还计划支持AWS。

3.3　架构与组件

从第一个版本的Amsterdam开始定义ONAP的整体架构，后续各版本都有微调，但整体架构是一脉相承的。最新的发布版是Casablanca版（2018年11月发布），因此本书就以该版本为例来说明相关架构。图3-12所示架构是2018年8月23日在社区TSC会议批准的3.0.3版本。

图3-13是从模型驱动角度进行简化后的ONAP概要示意图。
注：IM表示信息模型，DM表示数据模型，VNF SDK、SDC、SO、DCAE、A&AI、SDN-C/APPC/VF-C都是ONAP的具体项目名称。

假设：运营商X计划基于厂商X提供的VNF（虚拟化网元）来为最终用户提供业务（最终创建业务A、B、C）。其大致流程与模型在ONAP各项目中的交互流如图3-13所示，图3-13下部的几方块代表ONAP中的关键项目/组件。从左往右，VNF SDK（负责VNF的验证校验）与SDC（负责业务设计）属于设计态项目，A&AI（全局数据库）、SO（跨域业务编排）、SDNC/APPC/VFC（单域控制器）、DCAE（负责数据采集与分析，与策略等项目共同构成闭环控制）等都是运行态项目。图中所示的大致流程如下：
步骤1　厂商X按VNF SDK项目提供的SDK开发工具包与开发指导要求，准备好VNF网元的描述文件、CSAR包等。这一步骤目的是，以机器可读的方式让ONAP理解VNF网元的模型情况，包括网元名称、版本号、厂商名称、对软硬件的资源要求、支持的操作等。这一阶段可认为是完成了VNF网元的入网测试过程。
步骤2　通过VNF SDK测试认证的CSAR包（包括对VNF网元的模型描述文件等）被加载到SDC。此时运营商的设计人员可将VNF网元作为可重用的资源来进行设计，与之前支持的资源（比如数据中心的资源，包括计算、存储、网络、其他VNF或PNF、物理网元等）一起，根据需要设计成新业务模板。设计模板的好处在于，可要求将此类业务的通用配置在模板中提前设计好，以降低在具体业务实例化过程中的输入负担。假设最终需要创建A、B、C共3条业务（有不同的输入输出IP地址、名称，对应不同客户），在业务模板中就可以定义业务必须经过哪些VNF网元的处理、是否需要有保护，以及业务配置后需要重点监控哪些性能指标、一旦发生故障之后应采取哪些行动等共性配置。在这一阶段输出的数据模型称为AID（Architecture integration document，架构集成文档），它最终也以CSAR包格式导出，并经过测试、审核、验证等环境后，被分发给后续ONAP各模块。至此就完成了新业务的设计及上线过程。
步骤3　当收到业务实例化相关请求时（通过BSS/OSS或者用户手工配置等），SO（Service Orchestrator，业务编排器）根据收到的业务实例化参数信息及业务模板ID调用相应的工作流处理，包括创建具体的业务实例（A/B/C）及将其保存到A&AI（全局数据库Active and Available Inventory）；评估业务对应的资源需求，并以合适的方式满足；将跨域的资源按要求分解成单域命令并调用对应的单域控制器（SDN-C/APPC/VF-C）完成对应的资源配置；相关资源占用情况也会同步刷新到A&AI中。至此就完成了新业务发放过程的自动化。
步骤4　业务发放成功后，DCAE（Data Collection，Analytics and Events，数据采集&分析）模板开始按业务设计的要求开始对特定事件进行持续监控。一旦发生指定的事件，则触发对应的闭环控制，按预定策略触发相应的动作。至此就完成了业务生命周期中维护过程的自动化。
从以上简要描述可以看出，ONAP作为一个自动化平台，覆盖了从供应商设备的入网测试、上线到将其与其他资源一起设计为新业务并自动发放、自动维护管理的全过程。

3.3.1　设计态框架和运行态框架

ONAP大体上可划分为两大框架：

• 设计态框架：用于对平台进行设计、定义和编程的设计期框架（统一上线）。
• 运行态框架：执行设计态框架所编写的逻辑（统一进行交付和生命周期管理）。

ONAP并不是简单集成这两个框架，而是非常紧密地结合，结合两者的就是模型，即设计态框架输出的模型，就是运行态框架的输入，模型文件通过SDC中的分发功能实现二者的无缝对接，如图3-14所示。

1.设计态框架
ONAP设计态框架是设计、定义和编程的框架，目标是方便开发可部署、可重用的软件资产，满足业务全生命周期的需要：增加新功能、修改已有能力、持续维护提升等。这是网络DevOps人员操作的重点，未来网络的自动化运行，多数工作都是在该平台上进行的。在ONAP上主要涉及三个项目：

• VNF REQS（VNF Requirements，VNF需求）：描述与定义可被ONAP管理的对象的需求。
• VVP（VNF Validation Program，VNF验证程序）：验证基于VNF REQS规范的VNF HOT模板和环境文件。
• VNF SDK：搭建测试验证可被ONAP管理对象的一个工具链平台，对符合ETSI NFV标准的VNF（TOSCA脚本描述）进行测试验证。它也是LFN的CVC（兼容认证项目）的重要组织部分，用于支持以代码化的方案验证可管理对象（VNF或PNF）是否满足VVP定义的需求。如果验证通过，则将其上线到设计态框架的目录中，供SDC设计使用。
• SDC（Service Design and Creation）：定义了多种角色以分别负责业务与资源设计、设计结果测试验证、资源确认等流程。完整设计工作至少需要定义设计者、测试者、验收者这三类角色。当然用户还可按需定义安全专家、客户专家、运维专家来创建相关模型、策略和工作流等。

2.运行态框架
运行态框架提供执行框架来执行逻辑，包括两大场景：业务实例化的自动化部署、自动发放场景（通过协同器与控制器两层机制来实现）及闭环控制场景（包括监控、分析、策略等闭环驱动框架能力）。
业务实例化的自动化部署和发放，即按用户在设计态框架中的设计结果及相应实例化的输入信息，实现新业务发放。业务发放过程中需要根据工作负载进行优化，选择对资源的最优部署方案，同时触发DCAE系统对设计态明确需要关注的事件进行实时监控。这一阶段完成后，即表明业务已开通，完成了与用户的业务交互。
闭环控制场景则是由事件触发的，即在特定事件或故障发生时，根据预置的动态策略实时闭环处理。它也是前面提到的闭环自动化中的主要使能部分，即设计→创建→收集→分析→检测→发布→响应中除设计之外的所有部分。
运行态框架从自行化层面可分为两层：编排层与控制层。二者的功能有部分重叠。其中编排由跨领域的业务编排器（Service Orchestrator）实现，而控制由各单领域的Controller控制器（包括Multi-VIM，VF-C，SDN-C，APPC等）实现。
运行态框架还包括一些核心组件与服务：

• 公共服务（Common Services）：提供访问控制、消息&文件转发、日志、数据管理等功能。
• 控制器层公共服务（Common Controller SDKC，CSDK）。
• 全局数据库（Active and Available Inventory，A&AI）。
• 数据采集&分析（Data Collection, Analytics and Events，DCAE）。
• 策略框架（Policy）。

运行态框架还包括一些周边服务和模块，它们一般是可选的：

• 管理界面（Dashboard）。
• 优化框架（OOF，ONAP Optimization Framework）。
• 安全框架（Security Framework）。
• 集成测试（Integration）。
• 外部接口（External API）。
• 运维部署服务（ONAP Operations Management，OOM）。

3.编排与控制
编排（Orchestration）本为管弦乐中的术语，主要是研究各种管弦乐器运用和配合的方法，通过各种乐器的不同音色来充分表现乐曲的内容和风格。但它在计算机领域被描述为对复杂系统、中间件（middleware）和业务的自动化安排、协调和管理。它与自动化的差别在于，自动化通常专注于一个任务，而编排通常是指与特定任务无关的自动化调度能力，常指对流程与工作流的自动化。通过某种描述语言定义相关工作流，同时由编排器（Orchestrator）负责根据加载的工作流执行对应的动作。
而控制原本是控制论中的术语，描述根据控制对象输出反馈来进行校正的控制方式，比如在实际测量值与计划值发生偏差时，按定额或标准来进行纠正。在SDN领域也引入了控制器（Controller）的概念，负责领域内的资源自动化。
在ONAP中，对编排器和控制器都给出了自己的定义，其中控制器与行业中的一般概念是有差别的。
首先，这里的控制器与行业中的控制器都有Orchestration编排的能力，即支持根据预先定义的工作流或流程，在运行态框架中解析并执行相应动作。这与硬编码的自动化过程的最大差别表现在图形化设计和修改工作流的能力，这跟模型驱动的设计理念是一脉相承的。借助便利的定义操作和无须开发投入的变更操作，编排器提供了灵活的适应性，缩短了新业务或变更业务的上市时间，是ONAP架构灵活性的主要使能技术，与Policy策略组合在一起，共同提供了可灵活定义流程的能力，让用户从业务和技术策略出发，灵活地完成自动化任务。
ONAP运行态框架在绝大部分场景中均无须人员介入，需要人员介入往往是在设计流程之前（在设计态框架中完成），但部分过程有可能需要人员干预或是选择动作，如进行例外或事后处理时。
编排支持同时处理大量请求，因此，编排器引擎被设计成一种可重用的服务，以便ONAP的任何组件中都可以执行预定义的过程方法。编排服务提供一套公共API来保证跨ONAP组件的交互的一致性。编排器引擎可解析工作流并遵照执行。这种服务化的设计模式可保证跨所有编排活动的一致性，并保证工作流执行环境一致。
其次，ONAP中的编排器和控制器的差异仅在于：自动化适用领域的目标与范围/层次不同，对编排效率的要求不同，被编排对象是有状态的还是无状态的，如图3-15所示（注：MSO项目在ONAP最新版本中已换名为SO，ASDC换名为SDC）。

SO即业务编排器，负责从最顶层管理编排工作和实现对下层控制器间的编排，包括理顺控制器间的数据交互，帮助其根据指定的流程和所需信息去完成相应方法所指定的动作。通过自动顺序执行按需创建、修改或移除网络、应用或基础架构业务和资源所需的活动、任务、规则和策略，执行指定的流程。SO在一个非常高的层次上进行编排，并提供基础设施、网络和应用的端到端视图。
SO性能要求相比控制器更低（图3-15所示的分钟级只是示例，具体要求视业务场景而定），且一般要求被编排对象是无状态的。对新业务来说，这可能涉及业务、资源优化部署的决策，以及为满足业务请求参数，选择具备相应能力的控制器来处理。如果现有控制器（基础设施、网络或应用）不存在或不具备相关能力，SO将创建并实例化一个新的控制器，以执行相应业务请求。
SO通过访问A&AI取得已有网络和对应控制器的信息来支持业务请求。A&AI提供可支持业务请求的候选控制器的地址；然后SO询问控制器是否仍具备相关能力；最后SO和控制器向A&AI报告完成业务请求的参考信息，以供随后的操作使用。SO执行的编排工作包括：

• 现有业务的交付或变化。
• 业务伸缩、优化或迁移。
• 控制器实例化。
• 容量管理。

尽管重点在编排，所有方法仍需要使用配置信息、标识符和IP地址来更新A&AI。
控制器是一些应用程序，这些应用程序将云和网络业务耦合，并执行配置和实时策略，以及控制分布式组件和业务的状态。运营商可以选择使用多种不同类型的控制器来管理执行环境中与其分配的控制域中相应的资源。控制器负责单业务或网络领域的自动化编排，效率要求一般是秒级或更高。其管理对象可能是有状态的，意为控制器需要保存相应领域资源的状态，并能对相应事件进行实时响应。目前社区主要有如下控制器：

• 基础设施控制器（Multi-VIM）：为VIM/云提供基础设施适配层，除了提供标准VIM的管理功能适配外，还可提供对HPA（硬件平台感知功能）的支持，以便OOF及SO/VF-C等组件基于硬件差异对资源进行最优化部署。比如，Multi-VIM可在SO的请求下创建/启动一个或多个虚机，并加载合适的VNF。当Multi-VIM完成请求之后，会把虚拟资源识别符和访问信息（IP）返回给SO并更新到A&AI等，以供其他制器使用。
• 网络控制器（SDN-C）：构建和操作方式跟基础设施控制器类似，支持在SO的请求之下，建立LAN或WAN连接并进行配置。
• 应用控制器（APPC）：在SO的请求下完成VNF的实例化、配置或规模伸缩等LCM操作。需要注意的是，APPC不负责VNF的创建与删除，这是在SO层面完成了的（更新A&AI即完成），即VIM基础设施层的资源分配等由SO调用基础设施控制器完成。APPC比较适用于简单的VNF（单虚机或容器）或者多VNF，但多VNF之间没有复杂的网络或依赖关系。
• 虚拟功能控制器（VF-C）：ONAP的控制器领域提供了符合ETSI NFV MANO标准的解决方案，它提供的是符合ETSI NFV标准定义的NS（网络业务，Network Service）粒度的接口。VF-C适用于类似vEPC、vIMS等复杂电信级VNF（需要多个虚机或容器资源，且互相之间有复杂的网络与依赖关系等），VF-C一般通过自身拥有的通用VNF管理器gVNFM或对接符合ETSI NFV标准的厂商VNF管理器sVNFM来实现对NS的LCM管理。

注：控制器目前选择与编排器不同的编排引擎，在SO中使用的是Camunda工作流引擎，编排脚本是符合BPMN标准的bpmn脚本，而SDN-C与APPC使用的是DG（有向图）工作流引擎，脚本采用Node-Red（一个面向IoT场景的工作流开发工具https://nodered.org/ ）的XML文件。当前DG引擎在CCSDK项目中，未来不排除某些控制器采用其他编排引擎甚至重用Camunda引擎的可能。

3.3.2　业务编排器与网络控制器的架构对比

本节以SO与SDN-C的架构示意（见图3-16）为例来简要说明在ONAP中，控制与协同的异同。

SO（业务编排器）的架构从上向下描述，分别是：
API Handler：API的处理层，包括不同API的适配、分批处理等功能。

• 数据存储部件：提供Catalog目录存储功能，外部系统可通过访问目录来了解SO当前支持的业务类型（来自SDC设计结果的分发）。内部其他模块（包括BPMN执行引擎等）也可从中获取与指定业务模板对应的业务逻辑脚本（Service Recipe）。请求数据库则保存所有收到的业务请求，包括业务的实例化请求、业务变更请求等。
• BPMN执行引擎：具体的工作流执行单元。根据从API Handler中获得的业务模板来配置相关参数、需要执行的操作类型。访问目录DB，找到对应的业务逻辑脚本（Service Recipe），并执行之。在具体执行步骤中可能调用适配层，以触发控制器层完成后续的配置工作。同时，也可能在A&AI全局数据库中创建/刷新对应的业务实例。
• 适配层：用于对周边组件的适配，包含对SDN-C网络控制器的适配器、对基础设施资源管理层的适配器等。

SDN-C的架构如图3-17所示。由图可看出，SDN-C架构设计理念与SO基本上是一致的。其他控制器也类似，这里仅用SDN-C作为示例。社区CCSDK项目提供了控制器的通用框架，以帮助用户快速开发类似架构的控制器。图3-17所示架构从上向下，分别是：

• API Handler：类似SO的API处理层，唯一差别就是对接的系统不同。
• 数据存储部件：提供单域控制器自身的Catalog目录存储功能。由于控制器需要处理有状态的编排，因此SDN-C的数据存储部件可能保存一些单域特有的资源状态信息，可能与SO保存的资源状态不一致。
• DG执行引擎：SDN-C的业务逻辑执行单元，选用DG（有向图）工作流引擎，根据从API Handler中获得的业务模板配置相关参数、需要执行的操作类型。访问目录DB，找到对应的DG业务逻辑脚本，并执行之。在具体执行步骤中可能调用适配层，以触发控制器层完成后续的配置运作。同时，也可能在A&AI全局数据库创建或刷新对应的业务实例。
• 适配层：SDN-C的适配层基于OpenDayLight的MD SAL架构开发，因此对YANG语言有较好的支持，内部有配置树与操作树两类处理。

从以上SO与SDN-C的对比可以看出，控制器与协同器在架构设计理念上是一脉相承的：业务逻辑处理单元一个是BPMN工作流引擎，一个是DG有向图引擎；另外在对TOSCA与YANG的集成程度上有些差异，内部数据库保存的状态根据适用场景的不同也有所不同；其他都是类似的。

3.3.3　核心服务&模块

核心组件与服务，即使用ONAP必然涉及的服务与模块，这些组件也是以服务形式提供的，原则上应该越少越好。
核心组件与服务提供必需的基础能力（日志等）及与周边系统互通的能力，包括访问控制、消息&文件转发、日志、数据管理等公共功能。涉及项目主要有：

• DMaaP（Data Movement as a Platform）：提供高性能的数据移动服务，因为ONAP内部需要多种数据移动，比如设计结果文件要从设计态分发到运行态、数据采集结果文件在各组件间转发、数据Schema文件变更后也要分发等。
• MSB（Micro Service BUS）：提供微服务框架能力，包括服务的注册与发现、网关流量均衡（load balancer）等。从Casablanca版本开始，还逐步开始增加Service Mesh的集成。
• AAF（Application Authorization Framework）：在ONAP内部组件间提供一致的身份验证、授权和安全性能力，以便应用程序、工具和服务能够匹配执行功能所需的访问。包括证书管理器等功能。
• Log（Logging Enhancements Project）：ONAP包括不同的组件或容器，这些需要写入不同的日志文件中，故日志文件数据量可能很大（尤其是在调度等环境中），需要各组件遵循统一的日志规范和日志工具，以便对跨组件、跨文件的日志进行跟踪分析等。
• CCSDK（Common Controller SDK）：提供控制器之间可重用的服务化组件，用于大幅提升Controller定制/开发的效率，包括NBI接口统一处理框架、与AAI数据同步、统一的plug-in插件框架（基于OpenDayLight的MD-SAL）、LCM生命周期管理框架、统一的HealthCheck健康性检查框架、统一控制器的日志管理组件、通用模型管理组件等。
• A&AI（Active and Available Inventory）：在服务化框架中，各个服务可拥有自身数据库，但所有需要其他组件了解或访问的数据模型与实例，都须同步到A&AI中。因此，基本上所有ONAP组件都有与A&AI交互的需求。
• DCAE（Data Collection，Analytics and Events）：用于统一处理除业务与Top信息之外的所有事件类数据的采集、存储与分析。自身的Health事件、日志数据、异常、需要监控的异常处理等都需要与DCAE进行交互。
• Policy：策略是实现闭环自动化的一个关键环境，负责策略规则集的维护、分发和处理。策略为创建和管理易于更新的条件规则提供了一个集中的环境。

3.3.4　其他组件

运行态框架中除核心组件外，其他所有项目都可划分为周边服务&模块，可基于特定UseCase场景选择使用。常见的有：

• 管理界面Dashboard：提供集中的组件监控与管理界面，包括业务的实例化下发等。
• 优化框架ONAP Optimization Framework（OOF）：一个策略驱动的工作负载优化服务，可基于各种策略约束（包括容量、位置、平台能力和其他特定的业务约束）做到跨多站点和多云的业务优化部署。
• 集成测试Integration：提供ONAP内部各组件间的集成服务。
• 外部接口External API：用于ONAP与外部系统（OSS/BSS）的API交互。
• 运维部署服务OOM（ONAP Operations Management）：提供基于容器的ONAP组件部署服务。
• MUSIC：记录和管理Portal、ONAP优化框架的状态，以确保跨地理分布的ONAP部署的一致性、冗余性和高可用性。

3.4　安全与可信的代码质量

社区对ONAP的代码质量进行衡量时主要是通过七个维度实现：鲁棒性（Stability）、安全性（Security）、可伸缩性（Scalability）、性能（Performance）、韧性（Resiliency）、可管理性（Manageability）、可用性（Usability）。通过为各维度定义不同级别的度量指标（0～3），并在版本开发中要求各项目针对这些指标不断优化，最终达成改善代码质量的目标。在ONAP社区，这几个指标简称为S3P（Security, Stability，Scalability, Performance）。
社区架构委员会例行与各项目协商，针对版本现状，定义各版本的质量指标目标与适用项目等。各维度度量指标定义如下。
1.鲁棒性
鲁棒性又称可靠性，是软件系统最重要的质量指标。根据ISO9000国际质量标准（ISO/IEC9126-1991）的规定：鲁棒性是指在规定时间内及条件下，软件能维持其性能水平的能力。一般用在一段时间内密集强化输入的测试方式来验证，即输入比正常输入更恶劣（合理程度内的恶劣）的数据，同时尽可能多地覆盖调用的子模块。这种测试方式在软件领域也叫浸泡测试（soak test），即尽量贴近实际使用情况，在一个稳定的、有一定负载的环境上，持续长期测试并实时监控CPU、内存、磁盘IO等指标变化，以发现内存泄漏、频繁GC等性能问题。ONAP对鲁棒性的要求如下：

• Level 0（0级）：在版本发布要求中，无鲁棒性内容。
• Level 1（1级）：版本已执行过72小时组件级浸泡测试（稳定负载下的随机事务测试，且对主要代码分支，代码覆盖率达到80%以上）。
• Level 2（2级）：版本已执行过72小时平台级浸泡测试（稳定负载下随机事务测试，且对主要代码分支，代码覆盖率达到80%以上）。
• Level 3（3级）：在6个月以上长期测试中，出现缺陷率持续降低的测试跟踪记录。

2.安全性
ONAP采用核心基础设施倡议联盟（Core Infrastructure Initiative，CII）的勋章项目要求作为安全性度量标准。CII是2014年4月24日Linux基金会成立的组织，目的是为属于互联网基础设施的开源软件提供支持（包括资金支持），避免类似“心脏出血漏洞”问题的再次发生。而CII Badge（徽章）项目则给出开源软件的安全最佳实践要求及徽章认证。以帮助开源软件提升安全能力。认证分三级：基础认证、银牌认证、金牌认证。目前已有2000多个开源项目参于了认证，具体可参见https://bestpractices.coreinfrastructure.org/en/projects 。
注：心脏出血漏洞（Heartbleed bug），简称心血漏洞，是一个出现在加密程序库OpenSSL中的安全漏洞。该程序库广泛用于实现互联网的传输层安全（TLS）协议。它于2012年被引入了OpenSSL中，2014年4月首次向公众披露。在漏洞披露时，约有17%（大约50万）通过认证机构认证的互联网安全网络服务器容易受到攻击。
对项目的安全认证要求如下（0～3共4个级别）：

• Level 0（0级）：无要求。
• Level 1（1级）：项目通过CII基础徽章认证，无业界已知的严重级别或高级别漏洞（＞60天的）。
• Level 2（2级）：项目通过CII银级徽章认证且所有内外部通信都是支持加密，且支持基于角色的访问控制与鉴权。
• Level 3（3级）：项目通过CII金级徽章认证。

ONAP对整个版本的安全需求定义如下：

• Level 1（1级）：70%项目通过1级认证，剩下项目满足80%条款要求，且需要符合社区安全委员会制定的特定加密标准。
• Level 2（2级）：70%项目通过2级（CII银级徽章认证），剩下项目都已通过CII基础徽章认证，且满足80% CII银级徽章认证的条款要求。
• Level 3（3级）：70%通过3级（CII金级徽章认证），剩下项目都已通过CII银级徽章认证，且满足80% CII金级徽章认证的条款要求。
• Level 4：所有项目100%通过3级（CII金级徽章认证）。

3.可伸缩性
可伸缩性（又称可扩展性）是一种衡量软件系统计算处理能力的设计指标，高可伸缩性代表在系统扩展成长过程中（常见的是容量或工作负载增长），软件仍能持续对外提供正常服务的能力，即不出现性能急剧劣化等无法服务的瓶颈限制。可伸缩性设计与事后的性能调优是不同的，其强调在设计之初就对高性能、低成本和可维护性等诸多因素进行综合考量和平衡，追求的是平滑、线性的性能提升，更侧重于系统的水平伸缩能力，力求通过较少改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟等高性能。比如，如果系统设计之初将所有数据表保存在同一数据库服务器，则在后续系统达到一定规模时，负载就会严重依赖数据系统自身能力；而如果提前将不同数据做了分区，则后续根据访问量随时做分区扩展，扩展就是更好地设计可伸缩性。ONAP对可伸缩性各级别的定义与要求如下：

• Level 0（0级）：无可伸缩性。
• Level 1（1级）：支持独立于其他组件的单点水平扩缩容能力。
• Level 2（2级）：支持跨地理位置扩缩容能力（在独立于其他组件的条件下）。
• Level 3（3级）：支持跨多ONAP实例间的组件扩缩容能力（包括提供相应的可操作性）。

4.性能
软件性能是指软件及时响应以满足用户要求的程度。常见性能指标通常包括响应时间、并发数、吞吐量及性能计数器等。狭义地讲，性能是指软件在尽可能少地占用系统资源的前提下，尽可能高地提高运行速度；广义地讲，软件性能关注的不是软件是否能够完成特定功能，而是在完成该功能时展示出来的及时性。由于感受软件性能的主体是人，不同的人对于同样的软件也会有不同的主观感受，如果时间和空间效率与其心理期待一致或能够达到用户的既定要求，用户就会认为软件性能是高的。比如，在一个需要长时间的操作中增加进度条，进度条本身对于缩短处理时间没有帮助，但更容易让人觉得系统性能是可接受的。在ONAP中对性能的理解是基于狭义定义的，其分为如下3级：

• Level 0（0级）：没有专门的性能测试。
• Level 1（1级）：定义了性能标准基线且有对应测试结果（如针对各组件定义响应时间、事务/消息速率、延迟、占用空间等）。
• Level 2（2级）：针对1级中定义的性能基线，在1个版本中定义改进计划（基于等效功能&等效硬件）。
• Level 3（3级）：对2个或以上连续版本实施性能改进计划。

5.韧性
韧性又称弹性，描述ONAP软件自身在故障场景下，继续对外服务的能力。ONAP对韧性的各级别定义与要求如下：

• Level 0（0级）：无冗余能力。
• Level 1（1级）：支持在单站点内手动故障检测、重路由或故障恢复；30分钟内完成测试。
• Level 2（2级）：在单个地理站点内支持自动故障检测和重路由，包括定义相关基线（存在无状态组件与有状态组件，可分别定义基线）。
• Level 3（3级）：跨地理站点支持自动故障检测和重路由，包括定义相关基线。

6.可管理性
可管理性又称易管理性，是指系统在运行过程中衡量便于管理的程度。良好的可管理性可以有效减少系统的管理和维护成本。ONAP对可管理性的定义主要关注在对ONAP进行维护运作时是否能达到方便影响范围控制等要求。

• Level 1（1级）：所有ONAP组件统一使用单一的日志记录，实例化一个简单ONAP系统时，在满足最小资源要求的情况下，时间应小于1小时。
• Level 2（2级）：组件可以独立升级，而不会影响操作交互组件，支持跨组件的分布式事务跟踪，各组件支持以通用方式实现对组件的统一配置。

7.可用性
易用性是指操作人员在学习或使用系统时的容易程度。易用性的设计重点在于让系统或产品符合使用者的习惯与需求。ONAP对易用性的要求集中在文档与用户界面设计的一致性与便利性上。

• Level 1：提供了用户指南、部署文档、API文档及代码遵从编码指南。
• Level 2：整个ONAP中的各个项目都提供一致的用户界面，且进行了可用性测试，提供辅助文档。

各版本S3P指标目标与满足情况如下：

• 从ONAP R2（Beijing版本）开始，启动这套质量评估机制，各项目基本处于从0到1的过程。
• R3版本则要求多数指标都需达到2级要求（可伸缩性要求达到1级，部分设计态项目对韧性要求可降低）。
• R4（都柏林版本）重点在如下领域进行增强：ONAP自身容器镜像优化，包括大幅减少体积、增加对代码的文档说明、集成CNCF的ServiceMesh组件、支持升级、跨地理位置的灾备、统一日志记录等。

3.5　本章小结

ONAP作为一个开放的管理平台，是为运营商级规模的实时工作负载而设计和建造的。其设计时参考了业界诸多设计原则与最佳实践，可帮助用户快速引入新功能而缩短新业务上市时间。它提供了设计态框架与运行态框架。在设计态框架中提供了一个可视化的设计框架来实现对所有元数据和策略的管理；在运行态框架中，分成编排与控制两层，同时提供一些核心服务组件以及周边服务和模块。
社区将软件成熟度划分为七个维度，简称S3P（鲁棒性，安全性，可伸缩性，性能，韧性，可管理性，可用性），定义了各维度的度量指标级别，并随着社区版本发布不断提升。