作者：VMWare大中华区应用现代化部门的资深云原生应用架构师 罗治年

大家可能都听过 Netflix 的故事，在 AWS的某个Region 发生了故障的时候，Netflix的服务仍然没受到什么影响，能继续对外提供流媒体服务。Netflix遵循的就是云原生应用与云平台的契约：即使云平台再可靠，也不会 100%可用，而上层应用需要通过架构设计来保证业务连续。

具体而言，就是云原生应用要具备 12 要素才能满足以上契约。Netflix 也贡献出自己内部使用的框架，通过与 Pivotal 合作Spring Cloud Netflix 项目，在广大的 Java/Spring 开发者社区普及了云原生应用的 12 要素。

无论应用是部署到公有云还是私有云，无论是否容器化部署，都应该尽可能满足这 12 要素，这样应用才能更充分的利用底层云平台，而底层的云平台也才能更好的调度应用，提供更好的云服务。

Kubernetes 的应用模型

现今，很多企业新开发的应用基本都会选择部署到 Kubernetes 平台，而不是直接部署到云平台之上，因为 Kubernetes 屏蔽了底层云平台的细节，提供了更高层的抽象，包括应用模型，也契合了云原生应用 12 要素的要求。但与此同时，企业也已经意识到Kubernetes 对开发人员而言太复杂了，要做到生产就绪真心不容易。

假设一个微服务的开发人员，当他好不容易实现了业务逻辑，要把应用部署到 Kubernetes 的时候，起码还要做两件事：构建容器和配置部署。当他在准备这些 Kubernetes 的 yaml 文件的时候，其实就是在利用 Kubernetes 的原生抽象模型，然后交给 Kubernetes 去做调度和部署。很多开发人员其实不知道可能还需要考虑一些更高级的配置才能生产就绪。

Knative 的应用模型

社区也意识到 Kubernetes 对开发体验不够友好，所以出现了类似 Knative 这样更高层次的抽象，底层仍然利用 Kubernetes 的 Deployment，ReplicaSet，Pod 等原生抽象。

从部署的 yaml 文件来看，Pod 部分基本上保持不变，总体而言，比原生 K8s yaml 要配的内容少一些，并且短一些，比如不需要单独配置服务访问的方式，而是通过 Knative 的 Route 来自动生成访问域名；也不需要配置实例数量，而是依赖 Knative 自动伸缩。

Cloud Foundry 的应用模型

在 Kubernetes 没有成为容器调度的事实标准之前，上一代的 PaaS 平台以 Cloud Foundry 为代表，在 Cloud Foundry 的用户中一直流传这样一句格言：“这是我的代码，帮我在云上部署运行应用，我不关心到底是怎么实现的 (Here is my source code, Run it on the cloud for me, I do not care how…)”，用来形容 Cloud Foundry 比较友好的开发者体验。开发者只需指定应用的名字、应用的代码或部署包的路径、资源的需求（内存）、实例的数量、绑定的服务、环境变量等，剩下的就由平台来自动配置了。同时，开发者还可以做更多配置比如访问路由的域名、健康检查的方式、启动命令等。

Tanzu Application Platform的应用模型

Tanzu Application Platform（TAP）作为新一代 PaaS 平台，主要基于 Kubernetes 技术体系，以 Knative 作为云原生运行时，同时也继承了 Cloud Foundry 的开发体验，试图博采众长，青出于蓝而胜于蓝。TAP 的开发体验更接近于 Cloud Foundry，都需要指定指定应用的名字、资源的需求、绑定的服务、环境变量。不一样的是，TAP不需要指定应用的部署包的路径，而是指定代码在版本库或镜像库的位置，相当于覆盖了 CI/CD 的完整流程。当然，如果只需使用 CD 部分的功能的话，也可以直接指定 CI 流程构建出的 jar包或镜像在镜像库的位置。TAP 同时也支持 GitOps 的部署模式，自动拉取版本库的变化，并在集群中应用执行并确保一致。

除此之外，TAP的 workload yaml 并没有像 Cloud Foundry那样指定应用实例的数量，而是依赖于 Knative 的自动伸缩特性。对于不采用缩容到零的需要长期运行的应用，其实可以通过指定实例数量的上下限来调整伸缩的范围。为保持与 Cloud Foundry的向下兼容，TAP 有一个专门的 Cloud Foundry 的适配器（Adapter）,可以直接使用 Cloud Foundry 的 manfest.yaml 来部署到 TAP 上。需要特别指出的是，在 label 中指定应用类型（workload type），可以自动选择 TAP 中的供应链，即：

在做实际部署的时候，默认使用 Knative Service 的方式部署，当然也可以沿用原来的方式选择以原生 Kubernetes 的方式部署。

总结与展望

TAP 是VMware新一代的云原生平台产品，2022年初正式发布并且还在持续的迭代和发展中，其应用模型支持的抽象也会越来越丰富。比如现在支持的主要应用类型之一web 应用，实现了 source-to-url 和 image-to-url；TAP很快就会扩展支持更多类型的应用，以及 Jenkins/ArgoCD 集成等场景。我们会在后续的系列文章中进一步介绍 TAP 的其它特性和使用场景，敬请关注与期待！