共计 6505 个字符，预计需要花费 17 分钟才能阅读完成。
作者：吕莫、新钰
前情介绍
大家好，我是“交付哪里有问题就锤哪里”的王小锤。不晓得大家是否还记得咱们交付铁三角（专一软件交付的我、头发略显稠密的开发老哥铁子以及售前大佬强哥）去年被各种交付问题折磨的故事。好在去年咱们惊喜的发现一本“独家交付秘籍“。通过一段时间的招式学习与理解，咱们发现：
- 整体交付流程变得分外清晰，交付效率大幅晋升。
- 加重沉重的简单环境适配、自搭组件运维平台等研发工作，交付流程缩短。
- 通过模仿线下环境演练使交付品质失去改善。
- 交付后的问题排查和运维工作也变得分外轻松。
交付的提速以及交付品质的进步，也着实惊艳到了客户，第一次让我在客户背后挺直了腰板。
虽说铁子的研发团队着眼于业务本身倒退，但秉持着技术人员的谨严与摸索欲，铁子对这些招式为何能以一敌十，轻松提效到小时级交付，产生了强烈的好奇心。带着这样的疑难，咱们通过云原生利用交付平台 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 是如何做到让软件交付变得高效、简略的呢？”
简化交付流程
阿莫微微一笑，身材微微战术后仰，喝了口水说道：“什么是软件交付秘诀？这就是软件交付秘诀中绝学所在，也是咱们最具翻新的局部。
1、ADP 平台利用的私有云弹性能力、Sealer 集群打包以及创立 K8s 集群的高效性，配合工作流引擎的正当调度和驱动，已实现 15 分钟就能拉起一套验证环境。
2、为了让客户尽量全面的验证，咱们同时还反对信创环境的拉起。确保交付出门前都失去反复验证的。
3、通用能力核心提供压测能力、平安能力以及故障演练等确保产品的稳定性和鲁棒性，确保产品适配各种简单场景。容量布局能力还 100% 模仿了 K8s 调度器逻辑，联合客户提供的资源信息可能分钟级得出是否能够实现交付。
4、对于局部能够用公网或者提供了近程登录形式的环境，还能够利用近程交付能力实现疾速交付。”
一口气说完这些，阿莫又喝了口水，好似意犹未尽，筹备持续继续输入。nice～
招式二：异构环境全笼罩
趁着访谈氛围的继续升温，咱们立马抛出更多交付问题，我提出：“你讲的太好了，ADP 平台下面提供的性能咱们用了，的确成果也和你形容的统一。然而很多时候交付到不同的环境，我明明看平台上利用的是公共云的环境，但当我拿着包去客户现场交付的时候也没什么问题。咱们还有个客户让咱们交付到阿里云容器服务 ACK 集群上，也是胜利的。甚至 MySQL 我想用私有云的 RDS 切换也很不便，这些你们都是怎么做到的？”
阿莫持续介绍道：“太优良了你们，发现了咱们产品很多用心打造之处。咱们在异构交付下面也下了较多的功夫。比方软件交付效率晋升和软件交付一致性的问题，ADP 次要是利用集群镜像技术从集群的维度将 ADP 底座和客户软件产品对立封装来解决的。”
- 集群镜像技术（Sealer）实现异构 IaaS 交付。Sealer 以集群的维度保障软件交付一致性的同时负责异构 IaaS 软件交付。
- 利用管控组件实现异构 K8s 交付。利用管控组件负责软件产品的装置、运行、销毁生命周期治理，以及负责无 ADP 底座的场景下，软件产品的异构 K8s 软件交付。
- 服务组件的 BaaS 化实现组件根本的异构交付。
异构 IaaS 交付之集群镜像（Sealer）
1、Docker 能够通过 Dockerfile 构建一个 Docker 镜像，应用 compose 就能够运行容器。
2、而 Sealer 是通过 Kubefile 构建一个 CloudImage，应用 Clusterfile 启动整个集群。
通过与 Docker 的类比，能够高深莫测的看到集群镜像是集群维度的 Build Share Run，ADP 则是利用 Sealer 的集群创立高效性和集群维度的打包能力将 ADP 底座和软件产品 Build 为集群镜像，以解决交付效率和交付一致性问题。
Sealer 作为 ADP 对外开源的我的项目，已有泛滥企业深刻应用并输入胜利案例，这里就不过多介绍。你们感兴趣能够进一步理解：
https://github.com/alibaba/Se…
异构 K8s 交付之利用管控组件
接下来咱们来聊聊通过利用管控组件是如何实现异构 K8s 交付的？
ADP 的利用模型其实是 ADP 软件产品的顶层形象，根底信息包含元数据、设施依赖、组件（服务组件与用户组件）等。
- 在线平台围绕该模型经验编排、集成验证、演练、资源布局等不断完善软件产品的模型信息，最终成为可交付产品。
- 本地运行平台则通过申明式 API 来形容该模型，利用管控组件的软件交付工作流会精细化管控软件产品的交付、降级流程，同时，时时回吐产品的组件状态、产品状态、异样信息等，但须要留神的是 ADP 的组件次要通过 helm chart 进行包装。
利用管控次要由两局部组成。
1、operator 外围为 K8s controller + 软件交付工作流引擎，剖析解决组件间的依赖关系有序实现产品软件交付、降级、运维等操作。
2、利用 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、产品官网：
https://www.aliyun.com/produc…
2、Github 地址：
https://github.com/AliyunCont…
而 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 则是私有化环境对立的监控、运维、故障诊断入口。
- 它联合 Prometheus、Loki、Grafana 等成熟的云原生计划实现监控、告警能力。
- 同时联合轻量化 FaaS 框架可插拔式的实现组件、集群的运维及故障诊断能力。
- 且基于故障诊断后果实现智能运维。
ACK Distro 的平安可靠性、麻利易用性、体验一致性、多样兼容性再联合环境调优、稳定性、可监控、可诊断、可运维等方面的加强很好的解决了私有化软件交付畛域异构环境反对难、运维难的问题。
讲到这里，阿莫带着略显沙哑的嗓音说道，如果这部分如果你感兴趣，咱们下次再聊。
我扭头看向铁子，之前铁子紧皱的眉口曾经皱缩开来，好似压在心头的不解已云消雾散。再听阿莫从清脆嘹亮的嗓音跟咱们聊到了略带沙哑，我心中暗想这次干货不整顿下来帮他们好好宣传宣传怎么行。于是我将这个想法和阿莫进行了沟通，并与他约定下次访问再来求教运维那些事，就这样咱们带着满满的干货称心如意的来到了。
对了，听到咱们说想帮忙 ADP 团队宣传，阿莫无比认真的说，认真听课的孩子有惊喜哦～
上面是阿莫的广告工夫：
如果您看懂下面所形容的招式。那么祝贺您，您把握了全新且先进的软件交付理念，快去拿着这份武林秘籍去与软件交付难题过招吧！
通过 ADP 平台，您将取得
- 软件交付提效，客户夸赞的眼神屡次。
- 节约人力与软件交付老本，老板称许的必定屡次（兴许存在升职加薪可能哟～）。
- 缩小加班次数，更多的工夫陪伴家人，失去老婆爱的抱抱屡次。
惊喜大礼：
1、您已清晰的理解并可疾速上手通过 ADP 产品实现软件交付啦。
2、现 ADP 为了更好的助力客户胜利，将继续凋谢试用流动至 3 月底。上次试用流动没有赶上的小伙伴们这次可不要在错过了哦，同时也欢送大家向小锤团队学习，来找咱们理解更多技术细节呀～
大家能够点击下方此处进行试用流动报名。
对于小锤他们之前遇到过哪些软件交付难题，点击下方链接查看，我深信小锤与咱们 ADP 之间的故事仍将持续，让咱们一起期待下次的第二次握手吧，未完待续，敬请期待。。。
（本文纯属虚构，如有雷同纯属巧合）
