阿里巴巴的云原生应用开源探索与实践

时间 2019-11-21

原文原文链接

做者 | 司徒放（姬风）阿里巴巴技术专家docker

本文整理自司徒放（姬风）题目为《开源的黄金时代，阿里巴巴云原生开源的探索与实践》的演讲。
关注“阿里巴巴云原生”公众号，回复关键词“开源”便可下载本文 PPT。api

导读：从拥抱开源、贡献开源、自主开源，到赋能开源，开源已升级为阿里技术战略之一，且正为开发者源源不断地输送切实可见的价值。云原生是阿里开源的重要领域，短短几年，以 K8s 为核心的云原生开源生态迅猛发展，这是全世界开发者合做杰出成果，也是开源力量的结晶。安全

阿里巴巴的应用架构演进

你们好，我是司徒放，目前在阿里巴巴负责阿里云的应用平台和微服务产品线。在和你们分享咱们在云原生应用方面的探索以前，先和你们介绍一下阿里巴巴在整个应用架构方面的演进历程。性能优化

今年是阿里巴巴成立的二十周年，二十年前，阿里巴巴使用的这个应用的架构，仍是单体应用模式，它有不少的业务模块都在一个应用里面，各个业务都在一个应用里面开发，这个架构的一个好处是简单，也很是容易部署，对小的创业公司来讲是很方便的。它的缺点在于团队变大变多以后，不能知足快速迭代要求，由于每个业务它须要去发布的时候，都须要在同一个应用上作修改、发布，当这个业务迭代很是快的时候，它同时的一个并发修改就很是多。架构

因此在 2008 年的时候，阿里巴巴就引进到了微服务架构，只是当时并不叫微服务，而是叫服务化架构。各个业务模式就按照服务的边界来拆分，这是比较松耦合的一种方式，一个微服务应用是无状态的，能够快速扩展实例。并且某个实例有异常好比宕机时会能够自动下线，不会影响整个服务架构的稳定性。微服务架构也比较容易推进整个互联网公司的快速迭代需求。并发

大概三年前，阿里巴巴就走向了云原生的架构。这是一个自然适合云的、可以充分利用云的弹性能力和标准云服务，给整个阿里巴巴的电商下降机器的准备成本，特别是相似于在大促双十一须要不少机器去支撑，可是大促结束以后，这些机器有一半以上就能够归还到云上。app

这个时候，阿里巴巴就在往云原生的方向去迈进，并且经过整个云服务可以更快地加快整个阿里巴巴的技术构建。并且云原生架构，是一个比较开放、标准、没有侵入性的技术架构。负载均衡

阿里巴巴在云原生的开源进程

在阿里巴巴进入到了云原生以后，咱们看一下阿里巴巴在开源方面作了一些什么样的事情呢？框架

运维领域

首先，整个云原生架构里面最重要、最关键的一个基石就是 Kubernetes。
阿里巴巴在两年前，就在大规模的落地 Kubernetes 的整套技术用来作咱们机器资源的调度和管理。在内部有数十万台级别的机器以及上百万级别的容器规模，直接拿开源的 Kubernetes 到这种生产规模下是用不起来的，因此咱们在上面作了不少性能优化，包括针对规模上的改造，使得整个 Kubernetes 在阿里巴巴内部可以很顺畅地 run 起来，阿里巴巴也在不断地向上游去贡献咱们内部实践和优化的代码。
除了 Kubernetes 以外，在整个云原生生态里还有像容器、etcd，咱们也在不停地优化它的规模能力以及安全隔离方面的一些能力。同时，也开源了内部使用的蜻蜓（Dragonfly）用来作大规模的镜像快速分发。运维

开发领域

在开发领域，阿里巴巴很早就已经使用了微服务架构，也对外进行了开源，好比说 Apache Dubbo，这个是比较知名的 RPC 框架；还有去年开源的 Nacos ，做为阿里巴巴集团支撑大规模的服务注册发现、配置推送一个组件；另外，还有 Spring Cloud Alibaba，基于阿里开源的组件提供了一整套 Spring Cloud 最佳实现；还有像支撑整个阿里巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息队列，都是咱们在开发领域作的开源。

这些组件其实随着阿里巴巴进入云原生时代以后，也在逐步结合云原生作一些改进，好比说 Apache Dubbo，会更好地去适配咱们将来的微服务 Service Mesh 架构，它会理解 Istio 的 xDS 协议，成为一种数据面；好比 Nacos，它为 Service Mesh 的 Istio 提供 MCP 协议的对接，成为云原生微服务和传统微服务互通的桥梁。

应用

在开发领域和运维领域之间，其实我认为还有一个很大的空缺，就是专门用来链接整个开发和运维的应用这一块。

对于开发阶段，写完代码以后交付的是一个应用包，而这个应用包也是整个运维系统上运行的一个基础颗粒。咱们认为如今在云原生阶段，缺乏了一个很好的应用交付和运维标准，你们在不一样的公司会看到每一个公司都有不同的运维平台，应用的部署和交付都没有办法被标准化。咱们如今进入云原生时代，推崇的是标准、开放，因此咱们认为在这一块上面还有很大的机会去作进一步的应用标准建设，这是我接下来想要和你们重点分享的一个话题。

云上应用交付和运维的痛点

先看一下云原生在交付和运维方面有哪些痛点呢？

刚刚也讲到了，在进入到了微服务以后，咱们面临的一个问题就是应用的实例数会愈来愈多，会到成百上千的规模不断往上增加；另外还有咱们部署的环境也变得愈来愈多，好比说如今有不一样的云厂商，以及咱们有不少专有云的自建机房的输出；另外还有不少自建的环境，这些环境多样化以及咱们应用在运行时它会以容器的方式去运行，可能仍是以传统的虚拟机的方式去运行，或者它会以函数的方式去运行，可是运行时也会有不少不一致，好比不一样的环境、或运行时的不一致，会致使整个分布式运维体系变得愈来愈复杂，它的监控、日志采集也是一个很大的挑战。

当这些应用已经放到云上去运行的时候，因为不少的云服务并无被标准化，不少这种云的能力须要集成到应用上的时候，也会有很大集成的困难。而这些云上应用运维的痛点之前也有相似的，咱们能够跟过往的解决方案作一个对比。

过往解决方案

首先，是相似 Ansible、Puppet 这些基础设施运维自动化的工具。这些工具对整个运维效率起到了很大的提高做用，减轻了运维同窗的工做量，可是它使用的是一些自应用的模块，并且它的概念是偏向于脚本运维的方式，很是的底层。

随后出现了相似 Cloud Foundry 、Heroku 这种比较经典的应用平台，这些应用平台是以应用为中心去作运维和交付，往上把运维的工做进行了一个抽象，按照 buildpack 的方式去作运维和交付，经过 buildpack 的方式，能够简化整个应用运维的工做，可是 buildpack 自己覆盖的范围比较窄，在运维和交付方面，缺少一些运维交付的标准，因此它的可扩展性是比较差的。

随着 Docker 容器的横空出世，打破了传统基于 buildpack 的应用交付模式，因此就出现了新一代的容器管理平台，而 Kubernetes 成为了云原生时代一个新的容器平台事实标准。Kubernetes 自己提供了不少基础服务抽象，好比说 Deployment、Service。在社区里面它有一句很著名的定位：“Kubernetes is the platform for platforms.”也就是说，Kubernetes 定位是构建平台的平台，可以简化构建应用平台的复杂度，它不会再去作上层基于应用的抽象。你们能够发现历史老是那么类似，从过去的运维工具到后来基于应用的抽象，到如今容器出现打破运维格局，从新对这个领域进行洗牌，天然，在云原生时代须要一个对应交付和运维应用的平台。

从过往解决方案引起的思考

关于云原生时代的应用抽象，咱们要作一个思考：咱们须要什么样的应用抽象呢？

首先，它须要解决咱们运维交付的一个复杂度，以及屏蔽底层细节差别。不管何时，都是应用平台须要解决的问题。另外，参考咱们过去比较传统的应用平台的问题，好比说 buildpack 这种方式，它存在不通用/不易于扩展的问题，咱们认为接下来的应用抽象，它应该要具有在应用运维方面更加通用、可扩展的描述能力。

除此以外，咱们在推广应用抽象的时候，仍是要采用开源和社区的方式去推动，由于将来必定是更加标准和开放的，咱们推广这个应用抽象，就是但愿有更多开发和运维工做者，可以给这个标准提供更多的建议，可以经过整个社区进一步推进整个应用交付和运维标准的发展。

Open Application Model - 开放应用模型

在上个月中旬，阿里云和微软联合发布了“Open Application Model（开放应用模型）”这一个开源项目。咱们但愿经过这个开放应用模型，解决“在云原生时代缺少一种应用交付标准”的问题。（“Open Application Model -开放应用模型”后面简称为“OAM”）

OAM 的三种角色

OAM 里面有三种不一样的角色。

首先是应用开发。很明显，应用开发是负责编写业务逻辑的。好比说它会写 Spark、Wordpress、Spring Cloud 等微服务的程序，它写完这个微服务的程序以后呢，会按照 OAM 标准编写一段应用定义；
第二个是应用运维的角色，就是负责应用的交付与运维；
第三个角色是基础设施平台。基础设施平台在 OAM 里的一个重要定位，在于它要将本身的基础服务能力抽象成可被复用、被重用的模块，并提供给开发和运维人员去使用。

OAM 核心概念解读

下面为你们解读以上的三个角色对应的三个核心概念。

首先是 Component。它是被开发人员定义的一个可被重用的应用组件，这个应用组件描述的就是这个应用它运行的方式；
第二个重要概念是 Trait。它是一种应用的运维特征，是由基础设施平台这个角色定义的，而这个定义它包含了可组合的应用运维特征，这个特征是实际上是这个平台能够提供出来的某种运维能力抽象；
最后一个是 ApplicationConfiguration。运维人员负责把 Component 和 Trait 两个绑定在一块儿，而且做为一个具体的实例化，生成了这个应用配置（ApplicationConfiguration）以后，就能够把应用部署起来。

用 OAM 描述的应用配置示意

接下来是一个具体的用 OAM 描述的应用配置文件（上图文件作了必定内容简化，具体如下面的 yaml 文本为准）。

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: wordpress
spec:
  workloadType: core.oam.dev/v1alpha1.Server
  containers:
    - name: test
      image: docker/wordpress:latest
      env:
        - name: key1
          fromParam: test-key
      ports:
        - type: tcp
          containerPort: 9999
          name: http
    parameters:
    - name: test-key
      type: string
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: wordpress-app
spec:
  components:
    - name: wordpress
      instanceName: wordpress-instance
      parameterValues:
        - name: replicas
          value: 3
        - name: test-key
          value: value-from-ops
      traits:
        - name: service
          parameterValues:
            - name: portMapping
              value: 
                - protocol: "TCP"
                  port: 52014
                  targetPort: 9999
        - name: rollout
          parameterValues:
            - name: canaryReplicas
              value: 1

由运维人员编写的 ApplicationConfiquration 文件，它将 Component 和 Trait 两个概念绑定在一块儿。首先里面描述运维要部署一个叫 wordpress-app的应用，它引用了一个叫 wordpress 的 Component。这是开发人员在另外一个配置文件 Component 定义的，他除了定义 wordpress 应如何运行（好比配置镜像位置）之外，还容许运维配置运行实例的副本数以及运行时环境变量 test-key 的值。在 ApplicationConfiquration 里同时引用了两个运维特征，运维人员会填写这个应用须要一个负载均衡，要作外网的端口映射，部署时须要采用金丝雀发布策略。这个文件对应到实际上的部署阶段会变成如上图右侧所示，上面会有一个负载均衡，好比在云上运行时，就会使用 SLB 去作负载均衡的自动分发，会给它配置外网 IP 和内外端口映射。

经过这个简单的 yaml 文件，你们就能够了解到这个应用怎么作快速部署，而且描述运维要具有什么能力。

OAM 的设计理念

给你们总结一下，我所认为的 OAM 的重要的设计理念。

首先第一个是配置即代码。全部的 OAM 上面的运维和交付的操做都会使用配置的方式，彻底经过 yaml 文件去完成全部的交付运维配置；
第二个是依赖倒置。这个依赖倒置有点像 JAVA Spring 开发者使用 IoC 或者 DI 的这种模式，在写这个应用配置的时候，只是依赖应用标准抽象，而这个标准抽象背后的实现其实是由 OAM 的运行时去作“注入”，经过这个方式就使得咱们的应用运维不依赖于咱们具体的运行环境；
第三个是重要的设计理念就是角色关注点分离。刚刚上面讲过 OAM 里的三种不一样的重要角色：开发、运维以及基础设置平台。这三种角色只须要编写对应不一样的配置文件，互相解耦。这样开发不须要关心应用是怎么运维的，只须要把运行时须要的配置暴露并描述出来；基础平台只须要把平台能力提炼成 Trait；最终由运维人员把开发须要的参数和运维须要的能力进行结合。
第四个就是整个 OAM 的设计是一个可组合可扩展的方式。它会经过让咱们刚刚说到的 Traits 可以按需组合、重用、移植和扩展。

EDAS & OAM

上面咱们说了这么多其实都是比较一些概念性的东西，接下来咱们看一下，在阿里巴巴的云产品 EDAS 对 OAM 所作一些落地方面的尝试，这也是第一个在实际生产上面基于 OAM 对外可开放使用的云产品。

下面会用 EDAS 为例，给你们作一个介绍，讲解一下 OAM 具体怎么运做。

EDAS 是什么？

首先介绍一下 EDAS 是阿里云上面的一个云产品，它扮演着我刚才讲到的相似于一个应用平台的一个角色：

EDAS 从开发方面就提供了开发框架给咱们云上的开发者去使用；
开发者开发完程序以后，会把应用交付到 EDAS 上面去进行部署；
与此同时 EDAS 会对这个应用进行监控诊断，根据容量状况进行实例弹性伸缩；
EDAS 会对上面的微服务进行注册发现、服务治理；
提供应用的高可用保护，好比限流降级、熔断等。

这些是 EDAS 做为应用平台在阿里云上的产品定位。

EDAS 支持 OAM 的运行示意图

那么它在支持 OAM 在运行的时候又是什么样的呢？

如图所示，一个开发人员，他首先须要去编写一个按照 OAM 标准为参考去定义一个 Component。这个 Component 里面会定义如开发应用类型是什么样子，好比它的镜像路径、它须要多大的存储空间，以及它的环境变量是什么样子，这些都是开发人员在开发的时候须要去描述的内容。

对于阿里云来讲，它是一个基础设施平台的身份。它在上面其实有不少运维的能力，好比说像监控报警、块存储、须要发布策略和弹性伸缩的策略。EDAS 会把这些平台能力抽象成一个一个独立的 Trait，开放给运维人员使用。

在须要部署应用的时候，运维人员会选择 EDAS 上提供的 Trait 并填写相关参数，同时也设置好开发人员的 Component 的参数，这做为一次应用部署，生成了 ApplicationConfiguration 提交给 EDAS。

EDAS 做为 OAM 的运行时，在读取到这份部署配置后，它会去实现 Trait 提供相应的运维特征动做，好比说运维描述须要一个块存储，那么 EDAS 会在阿里云上面去申请一个具体的块存储对象，并绑定到这个应用上面。同时 EDAS 会提供一个容器环境（如 Kubernetes）去运行开发者定义的 Component 的工做负载，好比购买 ECS，配置好容器环境，把环境变量传给容器，使 Component 可以正常运行。

以上就是整个 EDAS 支持 OAM 的一个运行示意图。

EDAS 支持 OAM 的对比

那么 EDAS 在支持 OAM 以后，它的使用状况又会发生怎样的变化呢？

在没有使用 OAM 的时候，客户须要和系统解释我要作些什么事情、我要怎么作这个事情。好比说，他须要申请 5G NAS 存储，而且要把它挂载到某个机器的某个目录上面；或者他还有一个监控的需求，他须要告诉系统如今有一个业务指标文件，须要被监控采集，他要去设置这个文件的指标处理规则，最后把这个指标存储成时间序列数据，而且设置报警阈值。在使用 OAM 以后，它就变成了描述式，他只要描述我须要什么东西就够了。好比开发者能够说这个目录上面须要有 5G 的外置可读写存储就够了，具体这 5G 存储怎么申请是由 OAM 运行时去帮助解决的。另外，在监控的时候，他只须要描述本身的这个应用须要被监控、哪一个指标须要被监控并报警就够了，他不须要了解对接到具体是哪个监控系统，他不须要去关心这些事情。

原来不少云产品或者原来不少自定义运维平台都是须要依赖特定的 API 或者 CLI 这种模式去作运维的，这个时候应用要迁移到另一个运维平台，它的代码、镜像、二进制包能够带走，可是它的不少运维的设施、运维的配置包括监控的配置，这些东西都是只能留在这个平台上的，没有办法很容易地迁移到另一个平台上面。而经过 OAM，能够将平台全部的运维配置以 yaml 导出，而且可以很快地导入到另一个环境、甚至是另外一个应用平台上，整个系统会变得更加标准。

在使用 OAM 之前，运维人员须要去学习不少知识，好比使用的是 Kubernetes，他须要去了解整个容器和 Kubernetes 的使用方式，他要作定制和拓展就须要去学习 Kubernetes。若是他是从虚拟机的模式切换到容器的运维模式，这个时候他就须要不少时间去理解容器和虚拟机运维之间的差别。迁移到 OAM 以后，至关于 OAM 屏蔽了整个平台底层的细节，因此使得整个运维平台的 OAM 配置没有多大差异。

最后一点就是定制的难度上面。刚刚也讲到过，这个是 OAM 的一个重要的目标，让整个运维的扩展可以更容易的被发现、被组合、被替换。在使用 OAM 以前，运维的逻辑都散落在脚本里面，或者说都在运维平台内部，这个时候很难去统一管理。而一套 OAM 的运行环境是能够自描述的，能够很是容易把平台提供的 Trait、Component 工做负载罗列出来，使用者能够替换或增长新的 Traits，在运行应用时能够自由选择和组合这些 Traits。

OAM 后续规划，欢迎社区贡献

以上讲了 OAM 相关的一些基本内容，实际上 OAM 刚刚开源还有不少须要补充和完善的地方，这里也列出了 OAM 上最近这半年的计划，但愿你们可以参与社区，在上面贡献更多的想法。

主要有几个规划：

易用性方面
- 提供 Kubernetes 一键导入工具；
- 增长应用之间的依赖描述；
- 不断完善 OAM 的标准定义（Spec）；
- 社区提供更多的 OAM 上的实践案例；
OAM 开发方面
- 尽可能进一步去作开发的简化，包括一些字段的校验工具、编写 Controller 框架，方便更高效的开发 Trait 等实现；
- 另外，OAM 它自己不只仅是一个标准，它还提供了一个名为 Rudr 的参考开源实现；
功能方面
- 提供新的基础 Traits 去简化应用运维管理，好比常见的流量管理、蓝绿发布；
- 能对接更多的应用平台，好比说像 Windows、IoT 这样的平台。

最后，个人演讲就到这里，谢谢你们！喜欢 OAM 的朋友能够扫描下方二维码，谢谢！

原文连接

本文为云栖社区原创内容，未经容许不得转载。