目前，招商银行的云原生应用已经完成了大规模私有云建设，所有基础设施已经全面云化。经过三年的发展后，即将在今年完成应用全面上云。后续所有应用的开发、运维、交付将在私有云上进行，因此，我们也在进行云原生应用的全面转型。
而转型过程中，我们也面临了巨大的挑战。
首先，企业基础设施复杂，包括计算、存储、网络、安全，特别是网络基础设施极具复杂度。运行时经过私有云建设后实现了全覆盖，包括虚拟化、容器类、函数式、大型机、小型机等，属于行业特有。
其次，高要求。行业性质导致对应用交付和运维的要求较高，很多应用需要 24*7 的可用性。
最后，稳定安全。云原生应用转型是必经之路。因此，技术选型上也倾向于成熟、可用、合规、开源的技术，期望能够稳定、安全地完成云原生转型。
从应用设计开发视角来看，会有各种应用设计方式对业务应用进行划分，业务应用按照微服务方式又会被拆解为微服务以及组成依赖。以点餐系统为例，可划分为交互类、订餐类、门店类、后厨、配送、结算以及外部消息通知业务，每业务都可由多个微服务组成。以结算业务为例，可能由付款、对账以及退款等微服务组成。
应用完成设计开发后需进行部署，而部署时也会面临诸多问题。比如付款服务需要提供HTTP访问，需要进行部署然后对外访问，平台侧会要求开发人员申请网络资源，比如路由、f5、SOP，如果没有资源则无法满足服务。而应用开发人员更倾向于平台提供符合其应用认知的一套概念或模型，彻底屏蔽底层的复杂性，并提供发布保障能力，保证微服务化应用能够平稳发布，避免造成安全事件。
另外，运维阶段出现问题后需要能够快速修复，否则会产生经济损失或其他事件。但如果平台侧没有做抽象天然，应用和运行时耦合，则复杂度难以被屏蔽，因为应用团队和平台团队的关注点并不相同。
针对关注点不同，最好的解决方式是分离，而实现分离最好的方式是进行抽象。
社区提供了OAM应用开放模型来进行抽象。所有云上的资源对象会被归类为两类，一类是工作负载，一类是应用具备的能力，比如弹性能力、灰度能力、被访问的能力等。资源属性变为了工作负载的一种属性，而非独立的资源对象。从而实现多云以及复杂基础设施概念上关注点的分离。
而仅有分离依然不够，必须要有对应的framework进行支撑，因此我们选择了KubeVela。云原生应用的治理和管理是长期性的，有丰富的未来，也会演进出更多丰富形态或功能。因此，framework必须高度可扩展、插件化，方能满足长期演进的诉求。
有了内核，还需要有一套业务能够附着在该套体系上。
业务被定义为企业云原生应用交付和运维的一种范式，重点包括以下几个方面：
• 按业务scope来交付应用。应用已经被微服务化，意味着要交付一个肯定不止交付一个微服务，而是交付业务相关的微服务，需要按应用来交付。
• 应用易部署。
• 应用易观测。
• 兼容非云原生的工作负载
• 最佳实践能力平台化。平台要可扩展，范式要可扩展，支持其他更丰富的能力，将实践平台化、能力化，而不是作为一种布道或方法论停留在平台工具链以外。
技术实践一：面向OAM实现了7种工作负载，提供面向业务应用的交付。
以点餐应用为例，系统划分为应用后按照多个业务被拆解为多个微服务，比如结算业务由三个微服务组成，三个微服务有对应的SQL。后端微服务需要提供HTTP、RestAPI、web后端等微服务，有对应的DB。
因此在云原生应用管理平台里能找到与之匹配的应用工作负载，像搭乐高一样将其聚合在一起。完成面向OAM的描述后，将描述传递至业务管理平台，OAM Engine会在基础设施和运行时里创建合适、匹配的资源对象，并使运维能力自动化生效。
此时，平台开发团队管理的依然是资源，但应用开发团队管理的已不再是资源，而是应用对象。
技术实践二：应用全链路灰度发布。
易部署指部署不出问题，安全可靠、稳定可控、可观测。
如上图所示，A为前端服务，调用了C网关，然后网关分发到B并且操作DB。需要上线A和B的V2灰度版本。此时，应用平台需要提供三个方面的能力：
• 帮助应用开发人员创建与之匹配的灰度环境，但是流量不进入。
• 使流量可以平滑、端到端地进入对应的微服务灰度版本，中间经过的节点能够实现透传，意味着流量控制在需要经过的部分，其他部分不受影响，即可以进行安全切流。
• 流量能够识别。按照比例或流量特征，通过 header、cookie或body过滤出需要的流量。
比如要验证某测试用户的一笔银行交易经过某链路，它不应该影响全局的其他链路。最终灰度完成后，系统要自动化地回收相关资源，清理现场是一项繁重的工作，尤其是复杂的微服务应用。如果验证成功，则将V2作为正式版本，将V1回收；如果不达标，则会回退，将V2回收，流量切回V1，过程安全可控。
微服务作为一种运维特征被描述进OAM Spec，并由controller实现成体系的灰度发布能力，通过OAM和KubeVela进行扩展。
技术实践三：应用可观测体系。
应用被部署后，云原生应用面临的最大问题是微服务化后分布式数据更碎片化，运维人员的运维难度更大。
因此，需要将面向业务视角的微服务log、trace、metrics按照OpenTelemetry的方式归拢到存储里，用于分析排障。比如控制哪些服务应该被采集、面向微服务应该如何做SLA、SRE等服务能力的标定度量，以上能力均可以插件化的方式描述进OAM于KubeVela。
OTel采集服务实例时，metrics的trade会打在对应服务实例应用的annotation上，使得采集器确认应该采集哪些服务。其次，可将对于服务的可用性、性能的要求内置入平台，平台基于可观测数据进行动态计算，没有达到标准则会触发告警，使得云原生应用的排障或运营更数字化。
技术实践四：VMService兼容非云原生负载。
上云过程中，很多企业会有虚机应用的工作负载，针对大部分工作负载，可以采用容器化改造的方案。而对于一些较为重要的应用，企业无法承受改造带来的风险，应如何解决？
虚机的应用分为两个阶段：
• 首先，创建虚机控制流。
• 其次，部署虚机应用的控制流，上图绿色为流量。
如上图左侧，我们将虚机VMService做成模型实现工作负载标准化后，内置了路由和负载均衡相关描述，将描述交给OAM Engine后，由其负责路由controller的逻辑、创建VMService的虚机逻辑、启动应用等，使虚拟从资源申请到应用的发布实现完全的自动化。
OAM Engine可以完全复用到非云原生的工作负载。比如希望将工作负载迁到K8S上，可直接复用OAM Engine，只有对接的运行时发生变化，模型不变。对于上层应用开发者而言，只有配置上的轻微差别，可以实现无感地从虚拟化到容器、云原生的管理方式。
上图为应用架构，整体分为三层、四个部分。
最上层为交互层，中间是OAM和KubeVela留给企业的可高度扩展层，可以定义自己的工作负载，定义自己需要的运维特性与之绑定。底层OAM Engine可交给社区，企业和开源社区之间存在一条清晰的分界线，利于软件的合规管理。若企业发现某个通用功能非常有意义，可以将功能贡献到Vela库，完成企业对开源社区的反哺。同时，外部生态也可被轻易扩展。
如果要在多云环境、基础设施极其复杂的环境做云原生应用的转型，首先需要做应用抽象，通过应用抽象实现关注点的分离。同时，还需建立一套属于自己企业的云原生应用交付运维范式，并能够兼容历史，实现平滑过渡。最后，技术路线需要满足高度插件化，架构才能长期演进，才能助力企业的云原生转型。
未来云原生应用的一个阶段可能是云原生化的SaaS，SaaS企业不一定会构建自己的PaaS，但肯定会构建自己的应用管理平台。因为公有云或云厂商提供的应用管理平台无法端到端地、无缝贴合 SaaS服务企业应用管理的诉求。
如果SaaS生态异常开放，SaaS企业发展蓬勃，则意味着云原生应用管理平台有着宽广的技术赛道，相信OAM与KubeVela会是赛道中的选项。
