​云原生，即集成微服务、DevOps 、持续交付、容器化为一体的架构体系。

蓬勃发展的云原生生态，开源成为主流创新平台

云原生是一场技术的全面升级。云原生生态的蓬勃发展，带来了容器、Kubernetes、K8s Operator等架构领先方案的创新，实现了交付介质、基础设施管理、运维模型和持续交付理论的全面升级和突破，使得开源成为主流创新平台。如今K8s已经成为云原生时代的“安卓”。

应用管理平台诞生，优势之下又遇困境

但原子、碎片化的声明式对象，海量、琐碎的基础设施细节，复杂、各成体系的操作语言都会使得应用开发者面对容器+K8s交付界面时觉得较为复杂，使用其他云平台时又觉得体验感不佳，而通过应用管理平台则可以很好解决屏蔽云原生应用交付的复杂性。但针对应用管理平台又有新的困难出现：

• 传统平台模式易于使用，有限且不可扩展的专有API与能力致使平台扩展困难，迭代缓慢，导致平台开发无法满足日益增长的应用管理诉求。
• 容器平台模式开放组件且扩展性强，但缺乏抽象，过于“原汁原味”透出大量底层细节，导致应用开发者学习曲线陡峭。

云原生管理平台不断发展，确立核心设计原则

对于以上优势与困难，阿里巴巴在云原生应用管理平台做了如下演进：

• 2012年采用LXC的自研容器虚拟化技术（T4）支持集团在线业务
• 2015年Docker容器产品对外开放；阿里巴巴采用自研调度系统，开始混合云弹性架构
• 2018年全面推进阿里基础设施的K8s升级；容器服务K8s产品化对外开放，应用平台的底层切换到K8s
• 2019年联合微软发布统一应用模型OAM标准；主要应用平台产品EDAS的核心链路开始演进到OAM
• 2020年核心系统全面使用云原生技术，三位一体；多套应用平台启动PaaS内核升级，基于OAM/KubeVela支撑不同场景的应用交付和运维
• 2021年OAM规范成为信通院《云计算开放应用架构》核心行业标准；云原生技术在边缘、AI、游戏等垂直领域全面商业化落地
  同时确定了现代应用管理平台KubeVela的核心设计原则：
  

由于不同场景的应用平台接口不一，重复建设导致平台开发时功能重复开发，难以复用与集成，对于应用开发者，对接的API又完全不同，交付能力存在很大差异。因此KubeVela使用阿里云与微软云在2019年末联合发布的开放应用模型（OAM），基于该模型大幅简化心智、屏蔽基础设施细节与差异性、可交付一切制品的特性，KubeVela为完全声明式，可以直接被GitOps驱动，只有唯一需要用户学习的API，包括待交付组件、运维能力、交付则略、工作流定义等，构成统一的、基础设施无关的开放应用模型。

而在应用交付过程通常需要审批、暂停观察、调整等人为干预，“面向终态”就将无法满足这种面向过程式的交付方式。于是KubeVela将应用交付本质构建成一个流程，是由组件、运维能力、策略、步骤等灵活定义的DAG（有向无环图），形成围绕工作流的声明式交付，大大提高了工作效率。

利用像“乐高”一样的构建应用模块，形成了KubeVela高度可扩展、易编程的特性，其基于CUElang的胶水层，天然适合基于Go语言扩展，无任何限制；使用数据配置语言，十分适合数据模板化与数据传递；同时高效可扩展，动态生效，响应速度快，有效解决了平台能力扩展复杂度太高，结构复杂，难以大规模维护的问题。平台开发者编写组件和运维能力模板注册到KubeVela，应用开发者就可在KubeVela直接使用组件和运维能力进行应用交付，实现动态扩展。

通过面向混合环境的设计，使用完全独立的控制平面，不入侵到业务集群，由KubeVela负责在控制平面管理和操作这些插件，无需使用KubeFed等技术生成大量联邦对象，天然支持直接向多集群进行交付，并且可同时支持Push和Pull模式（可集成OCM/Karmada），解决了同一个应用在不同环境下部署的组件依赖差异巨大，在不同场景下的运维能力要求差异也很大，导致交付差异巨大的现象。

如今，KubeVela已成为了阿里云原生态基础设施的一部分，成为了一个简单易用且高度可扩展的应用管理平台与核心引擎，KubeVela社区和生态已获得931,000次镜像下载，有超过100位贡献者，超过2,000个Commit，成为行业标准，有超过35家海内外企业采纳，逐渐成为国际化社区。

根据日益上升的软件架构现代化诉求，相信其较强的基础设施能力丰富度必将在未来获得更广泛的应用。

了解更多可点击链接获取原文资料：云原生时代应用管理平台的演进之路

你的开源内容应该上榜

中国科协开源申报活动火热进行中，赶快点击链接进行申报吧！申报链接
中国科协首届2021“科创中国”开源创新榜评选，全程免费参与，对于申报成功的开源产品/社区/机构，主承办方会先后进行多种形式的宣传报道和展示。