独家交付秘籍之招式拆解（第一回）

简介：上一回说到经历种种交付难题的王小锤一行人，意外发现一本交付秘籍，打开了新世界。本次他们带着具体交付场景来到阿里云，与交付宗师阿莫探讨秘籍中的招式以及招式背后的秘密。

作者：吕莫、新钰

前情介绍

大家好，我是“交付哪里有问题就锤哪里”的王小锤。不知道大家是否还记得我们交付铁三角（专注软件交付的我、头发略显稀疏的开发老哥铁子以及售前大佬强哥）去年被各种交付问题折磨的故事。好在去年我们惊喜的发现一本“独家交付秘籍“。通过一段时间的招式学习与了解，我们发现：

整体交付流程变得格外清晰，交付效率大幅提升。
减轻繁重的复杂环境适配、自搭组件运维平台等研发工作，交付流程缩短。
通过模拟线下环境演练使交付质量得到改善。
交付后的问题排查和运维工作也变得格外轻松。

交付的提速以及交付质量的提高，也着实惊艳到了客户，第一次让我在客户面前挺直了腰板。

虽说铁子的研发团队着眼于业务自身发展，但秉持着技术人员的严谨与探索欲，铁子对这些招式为何能以一敌十，轻松提效到小时级交付，产生了强烈的好奇心。带着这样的疑问，我们通过云原生应用交付平台 ADP（简称 ADP）的产品交流群（钉钉群号：35138456），联系上 ADP 团队的技术小哥阿莫。下面带大家一起回顾下那天的场景，看看阿莫是如何为我们拆解秘籍中的招式，以及如何把不胜其烦的软件交付难题逐个击破的吧！

与 ADP 团队的第一次握手

那时已是寒冬腊月，不过再冷的天也抵拦不住我们交付铁三角对于知识的渴望，所以我们趁着年前不是那么忙的时候（绝不是借机划水/滑稽脸）来到了阿里云进行拜访。抱着就具体的软件交付难题进行深入探讨，以及了解更多技术细节（绝不是借机偷学招式）的目的，我们一行人与阿莫相遇了。

见面那天，我一个箭步上前，握住了阿莫的手。以这次握手为开端，我们一行人与 ADP 结下了不解之缘。握手后我连忙介绍道：“阿莫您好，我是王小锤，主要负责软件应用交付工作，旁边这两位是负责研发的铁子，和我们的售前强哥，之前用 ADP 产品的时候咱们线上沟通过。今天，我们主要是抱着学习的心态，想请您更为全面地介绍下 ADP 交付秘籍中的招式。另外，我们还想请教些实际碰到的交付问题。接下来先向您先介绍下我们的公司情况吧！”

铁子介绍道：“我们是一家大数据产品的软件应用供应商。因为我们的数据产品可用于各行各业，所以我们现在交付的环境五花八门。而且从开始成单到软件交付部署完成，再到最后的运维保障，在这些阶段我们各个角色均会遇到些烦心事。”

烦心事一：产品适配成本高

一些金融行业的客户出于数据安全性的考虑，会要求将我们的产品部署在他们本地运行。
一些企业进行 IT 转型时甚至还会提出信创要求。
一些客户出于节约成本的考虑，需要我们用他们本身已有数据库、云服务。

这些情况导致整个研发团队需要投入大量精力，基于不同的运行环境、OS 以及 CPU 架构去做适配。在业务应用改造的同时还需适配应用所依赖的繁多的中间件。这些中间件在不同环境中运行是否能够满足业务，如果出了问题该如何运维，这些问题在我们进行产品改造时深深的困扰着我们。”

烦心事二：部署环境极复杂

我补充道：“对于我们交付团队亦是如此，交付环境、资源配置各异，产品非标准化等都可能导致产品交付易出错、效率低、周期长，每次去交付都提心吊胆。如果产品还没成单，售前强哥还需到客户现场先进行 POC，他出差耗时耗力，这些都花了公司很多钱，好在他是售前大佬，这些成本老板才没有和他格外计较。

烦心事三：运维低效且门槛高

“而且客户环境存在较多的不确定性，比如硬件故障，机房突然停电等都可能造成应用无法重启、中间件无法自动恢复、数据丢失等不可逆影响。如何提前发现、快速恢复、高效运维等问题令我们头疼已久。好在 ADP 改变了我们的交付方式，这些问题有了很大的改善。”

重大改变

简要描述完我们的改变后，我继续道：“对于我们现有软件交付问题 ADP 基本均可涵盖，但根据强哥现在在谈的一些项目情况来看，今年我们可能会遇到更为复杂的软件交付场景，就这些交付痛点咱们看下如何应对可好？”。

软件交付秘籍介绍

阿莫听完，面露喜色，激动得说道：“听到 ADP 真正切切的帮助你们解决了难题，真替你们高兴。我们的秘籍招式就是为了解决这些问题而生的，接下来先和大家聊聊什么是 ADP。对于这次的碰面我特地准备了很多干货，这也是我们服务客户的态度，定让你们满载而归！

ADP 简介

ADP 是一套完整的“软件产品”私有化交付秘籍，帮助大家解决软件在私有化部署交付时存在的异构适配难、部署环境杂、云服务依赖重和运维效率低等诸如此类的交付难题。

先和大家解释几个名称，咱们统一口径便于理解：

一张图带你们看懂 ADP，👇 ADP 分为在线化平台和本地运行平台两个模块。

在线化平台：由 ADP-online 和服务目录两部分组成。为软件产品、服务组件提供从接入、集成验证、私有化软件交付的全栈在线化服务。

本地运行平台：由集群镜像 Sealer、应用管控、ADP 底座三部分组成。为保证软件交付一致性和实现异构 IaaS 交付负责。

介绍到这里时，不知是为了让我们消化下，还是看到了铁子欲言又止的表情。阿莫顿了顿继续道：“咱们有了基本的认知之后，看看接下来你们有什么想要具体了解的模块和问题呀？”

招式一：全栈式在线化服务

借着这个机会，铁子急忙问道：“我们公司现在有个数据产品，进行改造时发现需要依赖较多中间件。我看过你们服务目录中的服务组件，很丰富也满足我们产品要求，但我们仍然担心中间件的稳定性。因为之前我们用的开源软件，其稳定性让我们很是头疼，这个部分你们是怎么保障的呢？”

中间件适配

阿莫解释道：“中间件的稳定对业务正常运行以及后续运维都至关重要，这点我们有做深度的保障，均可在线化实现。

首先，我们服务目录中所提供的中间件、数据库等服务组件是由阿里云一方和我们的合作伙伴提供的，均经过大规模验证，验证过程如下，经过这一系列验证后，满足条件的服务组件才可以上架服务目录。

将服务组件通过二进制工具 zlink 上传到 ADP 在线化平台。
组件验证平台会对组件进行规范校验、镜像校验、镜像安全扫描、可安装性校验、监控告警支持校验等一系列操作，全方位对组件可靠性进行验证。
将组件部署到验证环境中利用通用能力中心的能力对组件进行一系列故障注入演练来验证服务组件的稳定性，如：主机断电、磁盘打满、副本重启等。
最后还会通过几种代表性配置的环境压力测试给出性能报告。

不仅如此，咱们企业的软件产品上传到在线平台后也是走同样的流程来保证质量的。对了，听完上面的介绍是不是放心些了呢？” 这时看到铁子不住的点头，我与强哥对视一眼表示诧异，作为逻辑缜密问题度极多的铁子居然还有频频点头表示认可的时候？平时讨论技术方案他总是会站出来提出质疑的呀？今天怕是不好意思问？果然还是那个他，他发问了，不愧是铁子！铁子问道：“你刚才提到说服务组件和我们的软件产品都是走一样的流程进行稳定性保障，那这两者是否有差异？”

阿莫解释道：“ 从整个在线化平台的角度来看，对软件产品和服务组件提供的这部分验证能力确实是一致的。但是主要差异在于：

服务组件提供商的目标是组件上架到服务目录被其他产品被复用。比如咱们企业，或者其他企业。
自身软件产品走这个流程更多的是为软件应用提供更充分的验证方式，能够快速的在从私有化环境交付到客户环境。”

强哥站了起来问道：“你看 POC 环境现在通过 ADP 我自己点一点就可以快速搭建好，可以看出你们为软件交付变得高效、简单做了不少努力。不仅如此，我看铁子他们交付的速度也变快了。请问 ADP 是如何做到让软件交付变得高效、简单的呢？”

简化交付流程

阿莫轻轻一笑，身体微微战术后仰，喝了口水说道：“什么是软件交付秘诀？这就是软件交付秘诀中绝学所在，也是我们最具创新的部分。

ADP 平台利用的公有云弹性能力、Sealer 集群打包以及创建 K8s 集群的高效性，配合工作流引擎的合理调度和驱动，已实现 15 分钟就能拉起一套验证环境。
为了让客户尽量全面的验证，我们同时还支持信创环境的拉起。确保交付出门前都得到重复验证的。
通用能力中心提供压测能力、安全能力以及故障演练等确保产品的稳定性和鲁棒性，确保产品适配各种复杂场景。容量规划能力还 100% 模拟了 K8s 调度器逻辑，结合客户提供的资源信息能够分钟级得出是否可以实现交付。
对于部分可以用公网或者提供了远程登录方式的环境，还可以利用远程交付能力实现快速交付。”

一口气说完这些，阿莫又喝了口水，好似意犹未尽，准备继续持续输出。nice～

招式二：异构环境全覆盖

趁着访谈气氛的持续升温，我们立马抛出更多交付问题，我提出：“你讲的太好了，ADP 平台上面提供的功能我们用了，确实效果也和你描述的一致。但是很多时候交付到不同的环境，我明明看平台上利用的是公共云的环境，但当我拿着包去客户现场交付的时候也没什么问题。我们还有个客户让我们交付到阿里云容器服务 ACK 集群上，也是成功的。甚至 MySQL 我想用公有云的 RDS 切换也很方便，这些你们都是怎么做到的？”

阿莫继续介绍道：“太优秀了你们，发现了我们产品很多用心打造之处。我们在异构交付上面也下了较多的功夫。比如软件交付效率提升和软件交付一致性的问题，ADP 主要是利用集群镜像技术从集群的维度将ADP底座和客户软件产品统一封装来解决的。”

集群镜像技术（Sealer）实现异构 IaaS 交付。Sealer以集群的维度保证软件交付一致性的同时负责异构 IaaS 软件交付。
应用管控组件实现异构 K8s 交付。应用管控组件负责软件产品的安装、运行、销毁生命周期管理，以及负责无 ADP 底座的场景下，软件产品的异构 K8s 软件交付。
服务组件的 BaaS 化实现组件基本的异构交付。

异构 IaaS 交付之集群镜像（Sealer）

Docker 可以通过 Dockerfile 构建一个 Docker 镜像，使用 compose 就可以运行容器。
而 Sealer 是通过 Kubefile 构建一个 CloudImage，使用 Clusterfile 启动整个集群。

通过与 Docker 的类比，可以一目了然的看到集群镜像是集群维度的 Build Share Run，ADP 则是利用 Sealer 的集群创建高效性和集群维度的打包能力将 ADP 底座和软件产品Build为集群镜像，以解决交付效率和交付一致性问题。

Sealer 作为 ADP 对外开源的项目，已有众多企业深入使用并输出成功案例，这里就不过多介绍。你们感兴趣可以进一步了解：

https://github.com/alibaba/Sealer

异构 K8s 交付之应用管控组件

接下来我们来聊聊通过应用管控组件是如何实现异构 K8s 交付的？

ADP 的应用模型其实是 ADP 软件产品的顶层抽象，基础信息包括元数据、设施依赖、组件（服务组件与用户组件）等。

在线平台围绕该模型经历编排、集成验证、演练、资源规划等不断完善软件产品的模型信息，最终成为可交付产品。
本地运行平台则通过申明式 API 来描述该模型，应用管控组件的软件交付工作流会精细化管控软件产品的交付、升级流程，同时，时时回吐产品的组件状态、产品状态、异常信息等，但需要注意的是 ADP 的组件主要通过 helm chart 进行包装。

应用管控主要由两部分组成。

operator 核心为 K8s controller + 软件交付工作流引擎，分析处理组件间的依赖关系有序完成产品软件交付、升级、运维等操作。
利用 K8s 作为公共抽象层可实现应用的高度一致，但不同 Kubernetes 环境不免会存在存储配置、网络插件、镜像仓库等等一系列微小差异，而 webhook 利用 mutate webhook 机制来抹平这部分差异，实现异构 K8s的软件交付。

面向开放生态

看了上面的架构可能会联想到目前社区很火的 OAM+kubevela 。以更加开放的体系，更方便的服务更多用户，我们确实也认可这个趋势，目前已经和 Kubevela 的同学积极交流合作，架构上慢慢会往 kubevela core + kyverno 方向演进。

另外，Backing Service 一直是云原生领域的热门话题，ADP在私有化交付领域可以实现用户只需声明一份服务组件定义即可实现到处交付，在不同场景下可由不同的provider提供一致的服务，就离不开Backing Service这项技术的功劳。具体怎么实现的你们可以猜一猜，下次来再给你们揭秘哦～

招式三：稳定可运维底座

看着越聊越起劲的阿莫，我们没有打断他。他继续介绍道，近日你们可能也关注到阿里云容器服务向 ACK Anywhere 升级，针对异构 IaaS 推出了阿里云容器服务发行版（以下简称 ACK Distro）。

这里咱们就不具体介绍 ACK Distro 了，如果感兴趣的话链接我发给你们

1、产品官网：

容器服务ACK发行版_kubernetes_kubernetes集群_云原生-阿里云

2、Github 地址：

https://github.com/AliyunContainerService/ackdistro

而 ADP 底座则是针对产品私有化交付领域的商业化版本，在 ACK Distro 基础上做了诸多增强。

阿莫这时终于停了下来，准备缓一缓再讲，但是铁子听到这么多干货，一时没忍住。望向阿莫脱口而出道：“那么 ADP 底座针对私有化交付领域具体做了哪些增强呢？”

阿莫快速的把手中的水一饮而尽解释道，不急，你听我慢慢道来。

基于阿里开源的集群应用打包软件交付工具 Sealer，一定程度上已经非常好的解决了软件交付效率和软件交付一致性问题，但如何让应用运行得更好，资源规划更合理，都是需要大量的软件交付经验才能积累起来的。ADP 通过 Sealer 的插件能力将阿里云多年的交付经验结合到了 Sealer 中，包括环境网络存储等预检、机器时钟同步、OS 参数调优以及存储设备的智能分区等。

前面提到的环境不确定性可能导致不可逆影响，那这时数据备份恢复能力就变得尤为重要。ADP 底座中的运维能力中心 ADP - Local （以下简称ADP - Local）利用Kubernetes 的卷快照能力（存储插件 Open Local 实现）、Velero 的卷快照 K8s 资源备份能力、restic 的文件快照备份及恢复能力结合 S3、NSA 等远端存储或本地硬盘再加上统一调度引擎的配合实现了组件、软件产品、K8s 集群等维度的备份及恢复能力。

ADP- Local 则是私有化环境统一的监控、运维、故障诊断入口。