演讲视频
在业务不断扩张的当下，每个企业都在不断演进中开发了更多工具以及应用服务。这些应用有内部的，也有外部的，应用的底层基础设施也都各不相同。而这些应用在演进的过程中，需要不断地被更新，但这些应用的更新逻辑也不尽相同。
这就要求我们的运维人员不但需要管理各个更新逻辑不一致的应用，还需要管理这些应用底层的基础设施的变更，如：集群的重启等等。
人手动的更新和管理不仅容易出错，还十分消耗人力，所以我们希望能有一个自动化的流程去管理这些应用的部署以及更新。
以淘宝这个应用为例，淘宝是个功能十分丰富的应用，其内部也分为了许多功能模块。我们举一个简单的例子，淘宝内部可能需要一个管理用户信息的组件，一个管理订单系统的组件，两个组件对应的数据库，以及一个前端。
而这些内部组件的部分配置可能是类似的，比如说用户信息和订单系统这两个组件都可以被认为是同一类的后端组件，而其对应的数据库也有一大部分配置是可以复用的。
除了这些组件本身以外，这些组件还需要一些额外的资源，比如说一个负载均衡器。
而在我们手动部署的过程中，我们首先需要部署三个服务，然后去云厂商的页面上开启两个云上的数据库，并且为服务配置负载均衡器。而在一个应用上线的过程中，我们将面对着许多不同的环境：开发环境、测试环境、预发环境、生产环境等等。
如果没有一个统一的自动化流程，同样的部署更新步骤需要我们在不同的环境中不断重复，这是一件十分繁琐且容易出错的事。
但这么多配置不同的组件和应用，我们应该如何自动化部署呢？
使用 KubeVela 的应用部署
以下是 KubeVela 对应用自动化部署提出的解决方案。
要想自动化去纳管整个流程，我们首先需要一个统一的应用模型，利用模型里面的抽象，去纳管各个配置不同的组件，这也正是我们提出的 OAM。
OAM 是阿里与微软推出的开放应用模型，而 KubeVela 则是 OAM 的官方实现，目前也是 CNCF 中的项目之一。
KubeVela 将应用中的资源划分成两大块，组件和运维特征。组件指实际上需要被部署的服务，在下图中，最左边的一栏是组件。在这个例子中，组件指的是订单服务，订单数据库，商品服务，商品数据库以及前端服务。
除此之外，应用自动化部署还需要运维特征帮助描述额外被运维的资源。应对不同配置的服务，每个组件以及运维特征背后，都有一个类型，对应实际服务的定义。KubeVela 使用 IaC 的方式，来完成组件的抽象与定义。有了这层抽象之后，不管是组件还是运维特征，可插拔性都能大大提高。在生产环境中，可以将需要的组件进行下发，并且指定对应的版本号。由于生产环境中要经常进行审批才能进行下发，我们还能够加上人工审核的步骤来配合工作。
为了防止配置时出错，我们可以在策略中加上安全或者合法校验的策略，保证每一次部署都是可信的。而在整个应用的部署过程中，KubeVela 会自动生成工作流完成部署，这个过程可以是隐式的，也是可以是显示的。
普通的用户只需要完成资源下发，但是当出现高阶的需求，需要管理每一个步骤时，便可以在工作流中声明步骤，帮助完成更好的部署，这就是 KubeVela 在应用交付层给到的答案。
在交付策略层，不管是集群分发策略、健康检查策略，还是防火墙规则，任何部署前需要遵守的规则，都可以在这个阶段进行声明和执行。同时在工作流定义层，当我们需要蓝绿部署，流量渐进式部署时，便可以在工作流中一步一步的去完成流量分发。目前 KubeVela 提供了 CLI 以及 UX 两个方式帮助用户进行部署。
接下来我会将使用 UI 进行演示，（详见视频8分20秒），如何在 KubeVela 上对多环境进行可靠的部署。视频中的页面可以看到左侧的工具栏分为应用环境、集群，交付目标以及插件，目的是完成多环境的应用交付。
首先，在环境以及交付目标中进行配置，比如目前需要交付一个简单的demo应用。将应用交付到两个环境，第一个是开发测试环境，在这个环境中需要对应用进行不断的迭代，直到完成预期的版本。而在实际的生产环境中，定义两个交付目标，比如第一个是杭州的集群，第二个是北京的集群，在 KubeVela UI 初始化时，会默认生成 default，用 default 来作为开发环境，有了开发环境，还需要生产环境，首先在 target 这一栏建立两个部署目标。具体操作请查看视频。
这个 demo 演示的比较简单，但是已经包含了正常开发上线到最后投放在生产环境中的全部过程。KubeVela 除了这些功能之外，还有许多功能在这里没有详细的讲解，比如插件体，对 AI 场景的集成，以及一些在安全方面所做的策略等。
以上是关于如何在 KubeVela 上对多环境进行可靠的部署的演示，欢迎在评论区发表你的见解。
