| 编辑推荐: |
本本介绍了介绍了应用交付的模型，面临的主要问题，以及如何使用云原生的方法实现应用的定义和交付，及多云和跨集群环境下的应用交付的核心要素、应用场景与业务收益。
本文来自于网易易盾，由火龙果软件Linda编辑、推荐。 |
|
CNCF 应用交付四层模型
如图是 CNCF 应用交付特别兴趣小组（SIG）定义的一个标准的应用交付模型，分成四个层次。
第一层包括应用定义（Application Definition）和应用封装（Application
Packaging），例如 Helm 是应用定义的软件，Docker 提供的 Docker Image
就是一种封装应用的很好的方法。
第二层 Application Deploy & Rollout，即如何把应用推送出去并部署到生产环境里边，主要包括应用的生命周期管理、配置的分发、下发和一些工作流，还有蓝绿部署或者是金丝雀的部署方式。仍以
Helm Chart 为例，就是通过 rollout controller 把应用部署出去，同时还可以通过
traffic management controller 决定 Ingress 流量的通路，决定是否采用蓝绿部署等配置。
第三层叫做 workload instance automation and operation，就是说应用实例在运行中可能会有一些问题，如故障自愈、弹性伸缩、Sharding、生命周期管理等，这些是在应用实例跑起来之后要解决的问题，常见的在
Kubernetes 里面，可能是一个 deployment 的 controller，负责一些 deployment
的管理或者是一些 operator 这种运维的工具。
第四层 platform 比较容易理解，所有的应用都跑在一个 platform 上面，云原生环境下最常见的
platform 就是 Kubernetes，Kubernetes 的生态提供了 resource
management、container life cycle management 以及 logging、monitoring、mesh
等各种各样的功能。
Harbor 支撑云原生应用交付
在应用交付标准模型的第一层，应用的定义主要是包括把应用的 artifacts、binary code、参数、运维设置等定义出来，然后交给系统去部署。比较典型的系统就是
Helm Charts定义这些事情。同时因为应用通常包括很多分散的文件，所以要打包交付给运维人员去部署到系统上，常见的有
Container Images、Buildpacks、CNAB 等形式， 可以帮助应用开发人员实现应用打包。开源项目
Harbor 的工作重心之一就是制品管理。Harbor 2.0 版本开始支持 OCI Artifact
，除镜像管理之外，该功能可以管理还可以管理 Helm Charts、CNAB、Open Policy
Agent 以及 Singularity 等各种各样的制品，这使得用户只需要一个 Harbor 仓库就能管理很多制品。Harbor
围绕制品的管理建立了一系列的功能，其中很多功能与应用交付是直接相关的，如镜像签名、安全漏洞扫描、远程复制、Webhook
等，都是应用交付过程中非常需要的功能。其中 Harbor 的远程复制特性不仅支持在两个 Harbor
之间进行镜像或者制品的高可靠复制，还可以跟公有云或者私有云中的各种Registries 和服务进行集成——大量开发者参与社区贡献，使得
Harbor 能够支持几乎所有的 Registries 制品的交付，并支持多云和多集群的部署，以及服务的支撑。
对于应用分发而言，镜像高效传输至所需的集群节点尤为重要。当某个镜像很大，同时又被很多个客户端节点需要，假如这些客户端节点在同一时刻去拉取该镜像，瓶颈就会产生，不仅是网络受不了，Registry
的 IO 也受不了。Harbor 采用了一种叫做镜像预热的技术方案来解决这个问题，即通过 P2P 技术把容器镜像以预加载的方式分发到所有需要该镜像的节点上，当应用需要的时候，该镜像就可以在非常短的时间内起来。Harbor
集成的 P2P 的分发项目包括 Dragonfly、Kraken 等，此类功能在下一版本的还将会有更多的增强。
网易轻舟面向交付过程的设计理念
从应用交付流程来看，创建一个应用的时候，首先需要围绕应用创建大量各种各样的资源，包括 Artifact、Strategy、Network、Middleware、Storage
等与运维或应用本身相关的资源，其次需要关注一些运维相关的概念，在云原生环境下的应用交付，Kubernetes
平台对 Workload 的定义是把研发和运维视为一个整体的，因此研发人员可能需要考虑如何分离研发和运维两种不同的角色，并将应用周边的资源作为一个整体管理好。
在资源定义好的前提下，应用交付实际上也是对资源的操作与分发。将资源分发到所需的集群需要三个保证，首先要保证分发的资源与创建出来的实例是一致的，其次需要资源分发过程有很多可选策略，以保证资源分发的效率和应用交付的可靠性，再次则要保证多云和多集群的环境下的应用交付——所谓云原生，计算资源应该是没有边界的，任何云计算资源都可以使用。
一个通用的云原生应用交付架构，底层是 IaaS 层，可以通过私有云、公有云或者是混合云抽象出一些资源，中间再基于这些资源去做一个
PaaS 层提供通用的能力，然后上层基于这些通用的能力和抽象形成的业务层，让用户直接可以灵活地操作自己的业务（应用）。其中的挑战是，研发人员需要面对应用的定义、应用的简单管理、应用的监控和应用的运维。
更有效地定义应用的资源，应用资源可以分为 Workload、Strategy、AutoScaling
等。网易的云原生应用交付实践的成果，已集成至网易轻舟云原生软件生产力平台，该平台主要提供微服务治理、DevOps、云原生中间件等能力，并通过网易数帆开放给行业客户使用。网易轻舟基于
Kubernetes 和 Helm Chart 将应用相关的资源聚合分类，定义在应用的概念下面，其中包括了轻舟
Deployment、轻舟 Router、轻舟 AutoScaling、轻舟 Config 等，把应用相关的资源划成
Kubernetes 上的 CRD，以便于用户定义资源和交付应用。
如图，网易轻舟是基于交付过程定义应用资源的，Workload 是应用交付的核心，围绕这个核心是路由规则、自动扩缩容等在应用交付过程中易变的资源，也是次核心资源，外围则是一些静态资源，如日志配置、网络配置等，一次配置完成之后基本上不会再变更。这是一个面向应用交付过程的设计，把交付过程中需要频繁干预的一些资源归为一类，不需要频繁干预的资源归为一类，通过这样的归类可以较好的组织交付流程。
网易轻舟应用交付平台设计要点
网易轻舟的实践，是通过模板（Template）来定义 Workload，把一些需要修改的点抽象出来，交给另外的角色去做——通常
Template 由运维工程师定义，由开发工程师使用，这样可以做到开发和运维的一些概念的分离。路由和自动扩缩容是应用交付过程中需要频繁干预的资源，网易轻舟在操作流程中就把这两种资源单独拿出来，分别定义为轻舟
Router 和轻舟 AutoScaling。轻舟 Config 则聚合了应用的配置、网络/存储的管理等一些固定不变的资源，最后由
Deployment 把所有的这些资源全部聚合起来，同时关联上一个应用，形成了一个完整的应用交付的定义。
完成定义的应用要交付到计算集群中，对此网易轻舟框架的整体设计包括两个部分，一个是管控集群，一个是计算集群。在管控集群中，用户把定义的
CRD yaml 文件部署到管控集群之后，Application Controller 会监控到资源的创建，然后生成一个升级流程，该流程定义需要部署的资源和相关的步骤。Upgrade
Controller 监控到升级流程之后，会下发一个任务给 agent。在计算集群中，收到任务的 agent
会创建一个相关的 Execution，该 Execution 包含需要部署哪些东西、部署成功的状态如何定义等。也就是说，agent
会把应用的定义转换成一些具体的资源，包括 Kubernetes 资源或者其他的一些资源，并且在监控到状态完成之后会反馈给
Upgrade Controller ，Upgrade Controller 收到反馈之后会继续驱动应用交付流程的后续步骤。
在整个应用交付的过程中，agent 除了前述实际操作之外还有一个功能，就是监控计算集群中的资源跟用户的定义是否一致，如果不一致则调整计算集群中的资源，以保证用户定义与实际交付的一致性。
与 CNCF 应用交付四层模型一致，网易轻舟在第一层清楚地围绕应用去定义了轻舟 Resource
Package；第二层网易轻舟有 Application Controller ，负责将业务方自己的
CRD 转换成 Kubernetes 的相关的 CRD 并形成一个流程，包括驱动后续的流程；第三层是轻舟
Execution CRD/Controller，以及原生的 Kubernetes Controllers，具体功能是操作
workload、instance 以及一些具体的资源；最后就是 Platform，网易轻舟基于 Kubernetes、Docker、Harbor
等开源技术研发了一个开放的基础架构，支撑上层的应用交付。
小结一下，网易轻舟应用交付平台的设计包括了6大关键点：
管控集群和计算集群分离 ；
采用渐进式交付；
支持灰度发布、蓝绿部署等不同的部署策略；
定义 Service 的流量与控制；
通过agent监控资源，让实际资源与定义保持一致；
支持多云和多集群的部署。
网易轻舟跨集群应用交付实践
根据上述架构设计，网易轻舟把一个应用交付到多个集群中的具体实践，首先定义应用的 package，以及相关的
Environment，包括集群、namespace、权重、workload 的占比、部署到哪些集群等。当
Application Controller 监控到应用资源创建，它就会形成一个 flow，里面定义了在哪个集群上面需要做哪些事情，Upgrade
Controller会将每个阶段定义的任务通过Agent下发到计算集群中。之后收到任务的 agent
会执行具体资源的部署，并把部署完成的结论反馈过去，然后由 Upgrade Controller 接着驱动后面的流程。这种实现的一个好处是用户实际上面对的是整个应用的视图，不需要关心应用的具体部署，对用户而言，应用和服务都是一个整体；另外一个好处，在运维的时候，运维工程师可以从应用的视角去管理不同集群上的资源，比较方便的看到这些资源的关联。
在流量控制方面，网易轻舟采用了 Kubernetes Service、Ingress、LB、Service
Mesh 等组件来实现，基于 Service 组合 Pods，采用 Ingress 把流量路由过来，最后通过
LB 聚合两个集群中的服务，以一个统一的 URL 对外提供具体的服务，这样业务就可以把这些服务当做同一个服务。
如图是应用交付和 Service Mesh 的一个集成。网易轻舟在两个集群里面部署了两套 Istio
控制面，并分别配置对应集群服务的相关信息，把这两个集群服务信息聚合起来，放到 sidecar 的里面，这样当业务需要访问这些服务时，不仅可以访问本集群的服务，还可以访问另一个集群里面的服务。
多云和跨集群应用交付的场景与收益
网易轻舟多云和多集群环境下的应用交付有什么样的应用场景和收益呢？
首先是容灾，利用网易轻舟支持多云部署的能力，实现跨机房部署业务应用，当其中一个机房宕机时，另外一个机房的服务仍然可以继续访问，从而保证服务的可靠性。
其次是资源弹性。在资源比较紧张的时候，用户可以借助网易轻舟轻松地把应用弹到任意一个公有云或者是私有云，从而可以利用更多的资源。
再次是区域相关性的访问和服务隔离。通过网易轻舟将应用部署在不同的集群中，再借助一些环境标识之类的信息去访问指定的服务。
第四是降低应用交付的复杂性。因为网易轻舟应用交付整个流程都是自动驱动的，所以可以有效地减少各种复杂的操作，同时应用交付的效率也可以得到提升。 |
