《Serverless 风起云涌为什么阿里微软AWS 却开始折腾 OAM？.docx》由会员分享，可在线阅读，更多相关《Serverless 风起云涌为什么阿里微软AWS 却开始折腾 OAM？.docx（8页珍藏版）》请在金锄头文库上搜索。
1、Serverless 风起云涌，为什么阿里，微软，AWS 却开始折腾 OAM？作者 | 张磊 邓洪超导读：近日，AWS ECS 团队在官方 GitHub 上发布了一个名叫：Amazon ECS for Open Application Model 的开源项目，越来越多的厂商开始探索 OAM 的落地实践。OAM 到底有什么魅力，让多家云厂商联合起来共同拥抱呢？Serverless 与 AWSServerless 这个词第一次被是 2012 年一篇名为Why The Future of Software and Apps is Serverless的文章。不过，如果你真去考古的话就会发现，这篇文章
2、谈到的内容是其实是持续集成和代码版本控制的软件工程理念，跟我们今天谈 Serverless 所提到的 “scale to zero”、“pay as you go”，FaaS/BaaS 这些东西，完全不是一个事情。在 2014 年，AWS 发布了一个叫做 Lambda 的产品。这个产品的设计理念很简单：它认为云计算最终是面向应用提供服务的，而当用户想要部署一个应用的时候，它只需要有一个地方放自己编写程序来执行具体任务，而不用关心这个程序运行在哪个机器或者哪个虚拟机上。正是 Lambda 的发布，才让“Serverless”这一范式提高到一个全新的层面。Serverless 为云中部署和运行应用
3、程序提供了一种全新的系统体系结构，强调用户不需要关心复杂的服务器配置，只需要关心自己的代码以及如何把代码打包成一个可以被云计算平台托管的“可运行实体”。在随后发布了一系列譬如根据实际流量扩展应用实例、按照实际使用量而不是预分配资源来计费等经典特性之后，AWS 才逐步奠定了 Serverless 领域的事实标准。2017 年，AWS 发布了 Fargate 服务，将 Serverless 的理念推广到了基于容器的可运行实体中，很快这个思想也被 Google Cloud Run 等进行了跟进，开启了“下一代”基于容器的 Serverless 运行时热潮。Serverless 与 Open Appl
4、ication Model (OAM)？那么 Open Application Model（OAM），跟 AWS 和 Serverless 又是什么关系呢？首先，OAM（开放应用模型）是一套由阿里云和微软共同发起、由云原生社区共同维护的应用描述规范（spec）。OAM 的核心理念是：“以应用为中心”，它强调研发和运维围绕着一组声明式的、灵活可扩展的上层抽象进行协作，而不是直接去使用复杂晦涩的基础设施层 API。比如，对于一个基于容器的、使用 K8s HPA 进行水平扩展应用，在 OAM 规范下会通过如下两个 YAML 文件定义出来。研发负责编写的 YAML 文件：apiVersion: cor
5、e.oam.dev/v1alpha2kind: Componentmetadata: name: web-serverspec: # 待部署的应用详情 workload: apiVersion: core.oam.dev/v1alpha2 kind: Server spec: containers: - name: frontend image: frontend:latest运维（或者 PaaS 平台）负责编写的 YAML 文件：apiVersion: core.oam.dev/v1alpha2kind: ApplicationConfigurationmetadata: name: hel
6、loworldspec: components: - name: frontend # 该应用运行所需的运维能力 traits: - trait: apiVersion: autoscaling.k8s.io/v2beta2 kind: HorizontalPodAutoscaler metadata: name: scale-hello spec: minReplicas: 1 maxReplicas: 10可以看到，在 OAM 规范下，研发和运维的关注点是完全分离开的。研发与运维只需要编写非常少量的、跟自己相关的一些字段，而不是完整的 K8s Deployment 和 HPA 对象，就可以
7、轻松的定义和发布应用。这就是“上层抽象”为我们带来的好处。像上述这样的 YAML 文件被提交给 K8s 之后，就会由 OAM 插件自动转换成完整的 Deployment 和 HPA 对象真正运行起来。由于 OAM 规范了“应用”、“运维能力”、“发布边界”等一系列云原生应用交付的定义标准，应用管理平台的开发者们就可以使用这个规范、通过更简洁的 YAML 文件描述各种各样的应用和运维策略，最后通过 OAM 插件把这些 YAML 文件跟 K8s 的实际资源（包括 CRD）映射起来。也就是说，OAM 给出了一个定义“上层抽象”的事实标准，而这个“上层抽象”最重要的作用，就是防止各种各样的基础设施细节
8、（比如 HPA、Ingress、容器、Pod、Service 等）泄露给研发同学，带来不必要的复杂性。所以说，OAM 一经发布，就被称作是开发 K8s 应用平台 的“神兵利器”。但更重要的是，这种从以应用描述中“剥离基础设施层细节、为开发者提供最友好的上层抽象”的思想，与 Serverless “去基础设施化” 的理念不谋而合。更确切地说，OAM 天生就是 Serverless 的。也正因为如此，OAM 一经发布，就受到了 Serverless 领域的重点关注。这其中，当然也少不了 AWS。极致体验：AWS ECS for OAM2020 年 3 月底，AWS ECS 团队在官方 GItHub
9、 上发布了一个名叫：Amazon ECS for Open Application Model 的开源项目。项目地址：https:/ AWS 团队基于 Serverless 服务对 OAM 进行支持的一次尝试。这个项目的底层运行时，正是我们前面提到的 Serverless 容器服务：Fargate。而这个 AWS ECS for OAM 项目给开发者带来的体验非常有趣，我们来看一下。准备工作有三步，一次性执行完即可。1.用户需要在本地有 AWS 账户的认证信息，这个可以通过 AWS 官方客户端 aws configure 命令一键生成；2.编译项目，然后你就可以拿到一个叫做 oam-ecs 的
10、可执行文件；3.你需要执行 oam-ecs env 命令来为你后面的部署准备环境。这条命令结束后，AWS 会自动为你创建 VPC 和对应的公有/私有子网。而准备工作完成后，你只要在本地定义一个 OAM 应用 YAML 文件（比如前面提到的 helloworld 应用的例子）那么你就可以通过如下所示的一行命令把一个完整的、带了 HPA 的应用在 Fargate 上部署起来，并且可以直接在公网访问到：oam-ecs app deploy -f helloworld-app.yaml是不是非常简单？在 AWS ECS for OAM 项目的官方文档中，它给出了一个更加复杂的例子，我们来讲解一下。这次
11、我们要部署的应用由三个 YAML 文件组成，依然划分成研发和运维两个关注点：1. 研发负责编写 server-component.yaml：这个文件里的内容是应用的第一个组件（component），具描述的是我们要部署的应用容器； worker-component.yaml：这个文件里的内容应用的第二个组件（component）， 具体描述的是负责检查当前环境的网络是否畅通的一个循环 Job。2. 运维负责编写example-app.yaml：这个文件里的内容是完整的应用组件拓扑以及各个组件的运维特征（traits），具体描述的是一个“手动扩容（manual-scaler）”的运维策略，它专门
12、用来扩容 worker-component。所以，上述 example-app.yaml 也就是完整应用描述的内容如下所示：apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata: name: example-appspec: components: - componentName: worker-v1 instanceName: example-worker traits: - name: manual-scaler properties: replicaCount: 2 - componentName:
13、 server-v1 instanceName: example-server parameterValues: - name: WorldValue value: Everyone可以看到，它定义了两个组件（worker-v1 和 server-v1），并且 worker-v1 组件有一个叫做 manual-scaler 的手动扩容策略。本 Demo 所有的三个 YAML 文件可以查看这个目录下的内容：https:/ app deploy -f examples/example-app.yaml -f examples/worker-component.yaml -f examples/se
14、rver-component.yaml上述指令执行完成后（在国内的同学因为特殊的网络问题可能需要一点耐心），你就可以通过 oam-ecs app show 命令查看到应用的访问信息和 DNS 名字。打开浏览器，输入这个访问信息，你就可以直接访问到这个应用了，如下所示：而如果你要修改应用配置，比如更新镜像或者修改 replicaCount 的值，那么只需要修改上述 YAML 文件然后重新 deploy 即可，完全是声明式的管理方式。实际上，上述操作如果通过 AWS 的 Console 来完成，至少需要在 5 个云产品页面之间互相跳转进行各种各样的配置；或者，你就需要学习 CloudFormation 语法然后编写一个非常非常长的 CF 文件，以便拉起应用运行所需的 Fargate 实例、LoadBalancer、网络、DNS 配置等等所有资源。但是通过 OAM 规范，上述定义和部署应用过程不仅变得极其简单，而且还把原来流程化的云服务操作直接转换成了更简洁、更友好的声明式 YAML 文件。而这里所需的实现 OAM 规范的具体工作，其实也就几百行代码而已。更重要的是，当 A
