TM Forum ODA - 打开云原生IT与网络架构的钥匙

2022-07-28 803

电信行业引领了信息化时代，是数字化时代的排头兵，电信IT从业务支撑者变成了业务使能者，成为运营商全面赋能数字化社会的工具。近年来，NFV在核心网规模应用，通过统一的操作原语实现了5G切片等创新场景，给无线领域带来了新的变革，电信软件如何适应数字化趋势，构建一个开放、符合云原生要求、支持零操作运维的软件架构？

TM Forum ODA提供了答案，下面我们来介绍一下。

整体架构

面向数智驱动、泛在连接和虚实相生的新通信时代，电信IT面临着许多挑战：如何引导生态发展，并充分利用生态中的供应商、集成商和咨询公司来实现敏捷业务能力？如何简化IT架构，提高自动化运维水平，降低系统集成成本和运维成本？

TM Forum作为一个全球产业组织，迄今成立时间超过34年，在全球拥有超过800家的会员，通过行业经验、最佳实践和行业标准来推动电信行业的领先发展。针对电信行业的这些挑战，TM Forum推出了ODA(Open Digital Architecture)开放数字框架，从工具、代码、知识、标准等来构建一个面向未来的IT蓝图，ODA主要包含五个部分：

//业务架构 (Business Architecture)

包含支持高效、敏捷运营的关键业务流程多层模型（eTOM），实现业务能力映射和价值流映射。

//系统架构(Information System Architecture)

包含支持松耦合的功能架构和数据架构(SID)，能够在运营商、供应商及其他合作伙伴之间提供标准的信息定义。

//实施架构 (Implementation Architecture)

包含50多个REST-based的Open API，可以实现IT系统标准化的互操作性；支持重用和简单集成的ODA组件，同时标准化的数据模型亦可帮助实现AI运维。

//部署和运行时环境 (Deployment & Runtime Environment)

通过Canvas来支持即插即用的ODA组件的运行，提供标准技术框架和DevOps支持，并且经由实验室测试环境持续部署验证。

//治理（E2E Governance）

提供相关的原则、设计指南、元数据，以及覆盖架构全生命周期的敏捷管理工具。

通过这五个部分的相互配合，运营商可以像搭积木一样搭建符合云原生要求，支持自动化运维的数字化IT系统。其中ODA Component是这整个框架的核心。整个架构示意图如下:

ODA部署实施

ODA部署实施架构主要由两个关键元素组成：Canvas和ODA组件，其关系如图所示:

Canvas提供了一个ODA组件运行环境，对外可以与CI/CD平台对接，支持DevOps发布流程，比如：自动化的组件部署和更新，并为应用提供了一个标准化的、支持云原生的运行环境，支持容器化、微服务应用的编排部署，并提供各种非功能性服务，比如服务注册、API治理、监控/日志等可观测性服务以及统一安全认证、事件总线等。Canvas是基于各种云原生组件构建，为云原生应用而设计，比如编排引擎使用Kubernetes，事件格式采用CloudEvent协议等，不过这些组件都是可按需替换的。Canvas的整体示意图如下：

ODA组件是经过标准化的应用，像乐高积木一样拥有标准的对接和管理接口，支持通过Open API相互连接，实现零配置(ZeroTouch)，可拔插方式在Canvas中运行。ODA提供了一种标准的六边形元数据描述格式，将应用的数据模型标准化为五类属性，包含核心功能(暴露的API接口和依赖的API接口)、事件通知、安全接口、环境要求、运维管理，为自动化的对接和管理提供了标准化的信息。ODA组件的示意如下：

另外，TM Forum还提供了ODA组件地图，对电信领域中的组件进行了标准化的划分，用于替代TAM。约定了标准化的部件和对接的Open API，实现系统解耦，方便供应商的产品开发和运营商的采购，各生态参与方可以对功能范围快速取得一致理解，并降低对接成本。

ODA Zero-Touch流程介绍

下面我们以某运营商需要上线一个CPC组件为例来讲解一下ODA下的整个部署流程。假设运营商已经拥有了一个ODA Canvas平台。

第一步，运营商可以到ODA的组件市场查询并选择某个供应商的组件，在经过商务等环节之后，获得了相应的ODA组件软件包(Helm Charts)。

第二步，通过Kubernetes的Helm工具来部署这个软件包。Kubernetes会创建出对应的应用，启动相关容器，同时还会创建一个对应于此ODA组件的Kubernetes CRD自定义资源对象，比如本次安装创建了一个CPC Component的ODA CRD对象。

第三步，Canvas通过Kubernetes Operator扩展持续监听ODA CRD对象的创建，当发现新增了一个CPC CRD对象之后，自动获取到资源对象中的ODA组件的元数据信息，并根据这些信息自动触发对应的开通动作，比如为CPC创建若干个API的CRD对象，描述CPC所提供的Open API。

第四步，Canvas对API CRD对象也设置了监听，当发现系统有新增API之后，API Operator会采集API的详细信息，比如内部访问地址、安全认证协议等，并将这些API发送给API网关，由API网关进行API的注册和对外开通，并将API网关反馈的外网访问地址更新到API CRD对象中，这样即实现了组件的自动化开通。

不仅仅是API网关的开通，其他的比如安全中心的策略/证书自动下发等都可以利用这个机制来实现。ODA架构充分利用Kubernetes平台的扩展机制，基于事件并根据ODA组件的数据模型实现Zero-Touch零配置的运维能力。上述流程示意图如下：

ODA技术亮点

将软件模块化，像积木一样来组装系统的想法并不新鲜，TM Forum ODA架构与TAM、NFV等规范等相比，有许多不同和亮点：

ODA与TAM相比，不仅实现了组件在功能层面的模块标准化，还覆盖了组件的非功能性要求，ODA组件的数据模型包含了安全、依赖、管理操作等部分，覆盖到了应用部署和运维环节。

ODA不仅仅是设计态的规范，还提供了配套的、支持微服务、云原生的Canvas环境和CTK等工具，提供了一个完整的可运行的应用框架。

ODA基于云原生操作系统Kubernetes的Operator扩展机制，通过事件驱动和插件扩展实现零配置的自动化运维，与NFV相比，ODA一开始就是基于云原生理念来设计，更加轻量化和易落地。

ODA规范设计和验证过程采用了开源的模式来协作，通过建立ODL（Open Digital Lab）开放数字实验室，众多运营商和供应商一起参与对设计进行验证、反馈和改进，更加开放并具有可落地性。

实战ODA-CA

浩鲸科技是第一批加入ODA宣言的企业之一，在创立之初就积极加入到规范建立、推广和落地的行动中，同时也是ODA-CA(ODA Component Accelerator)项目的初创成员之一。ODA-CA项目在AWS上搭建了一套ODL环境来对相关规范和技术进行验证。在这个项目中，浩鲸科技开发并完成了Product Catalog、Product Order Capture等ODA组件的测试验证，并向Canvas开源社区贡献了API Gateway等Canvas平台组件。在今年9月即将于根本哈根举办的全球数字化转型峰会（DTW）期间，TMF将联合浩鲸科技共同发布电信域解决方案的ODA Map。

根据浩鲸科技多年的电信领域实践经验，ODA组件的开发，首先是支持Open API接口，其次是云原生改造，并支持运行到Kubernetes平台上，最后是按照ODA规范输出元数据描述文件。如果应用本身已经支持了OpenAPI和云原生，组件适配的工作量并不大，以浩鲸科技为例，1个月左右时间就完成了适配和测试。另外值得一提的是，作为一个开源社区，Canvas底座也是开放的，比如Kubernetes平台，无论是Rancher等商业版还是社区版都可以支持。也欢迎各方积极参与并贡献平台组件。

总结

ODA基于TM Forum多年的电信管理经验和最新的云原生技术，通过可复用、可编排的组件设计和可拔插、可扩展的运行底座，可以帮助运营商建立一个敏捷、云原生和零运维的数字化系统，提高供应商、运营商、集成商的协作效率，同时标准化的、开放的组件市场也可以吸引更多创新团队加入，建立更加丰富的生态。ODA采用了开源模式共建，并借助社区的反馈进行改进，因此欢迎更多的企业一同参与，丰富组件市场和平台插件。

王玉木

浩鲸科技云产品总监、

TM Forum Contributer

拥有15y+电信行业基础架构研发经验，目前负责Cloud Native、DevOps相关平台研发。
TM Forum ODA、Docker等社区的Contributer，获得5+容器相关专利，通过系统架构师、CKA、DevOps Master等认证。
阿里云云原生讲师。

媒体中心

媒体中心

TM Forum ODA - 打开云原生IT与网络架构的钥匙

关于我们

产品与解决方案

成功故事

媒体中心