知乎上曾经有一个热榜问题：“中国程序员数量是饱和还是过剩？”
twdfbx的答案之一是“初级过剩，高级短缺”。
稀缺性是最重要的，在BOSS中直接搜索“建筑师云盛远”排名前三。有两个书商月薪3万，最高月薪6万，这两个一个14工资，一个15工资。
不要只记得羡慕工资。请参见下面一行标签：“熟悉分布式”、“DevOps”和“容器云”.
果然，没有金刚钻，就做不了瓷器工作。
不要只看到别人有钱的手，而忽略了别人的汗水。
在这一行，知识和收入总是成正比的。为了让你成为架构师，早日赢得心上人，4月1日，京东云与AI云产品研发架构师fqdqtd系，做了《六周玩转云原生》第三讲：DevOps和持续交付诞生在云端。让我们回顾一下本质！
概念和介绍
关于云原生有很多解释，这篇PPT列举了两个俗语，一般意思是云原生是DevOps微服务的容器化。
也就是说，云原生是一个概念的集合，包括微服务、容器和更多的管理方法，比如持续交付、DevOps和重组。
那么如何定义云诞生呢？下图是CNCF官网对云原生的定义，比较靠谱。想要了解云原性，首先要了解K8S，因为它是云原性的基石。
K8S
K8S是CNCF的第一个项目，云原生的整个生态都是K8S打造的。云的原生代表技术包括容器、微服务、服务网格、不可变基础设施、声明式API等。
DevOps
每当人们提到DevOps，他们总是把它比作盲人触摸大象。许多公司称之为不同。有的企业会把内部在线平台描述成自己搭建的DevOps。
但首先，让我们看看维基百科的定义：即通过自动化“软件交付”和“构建变更”的过程，软件可以更快、更频繁、更可靠地构建、测试和发布。
持续集成、持续交付和持续部署
持续交付可以使软件交付更快、更频繁，即可以随时发布。它的目标是使软件的构建、测试和发布更快、更频繁。要保证效率，我们只能更快交货，但更快交货的前提是保证质量。说到持续交付，很多人也听说过持续集成和持续部署。如下图所示，三者之间存在一些差异。
在传统的软件开发中，开发人员需要在项目结束后进行集成，这至少需要几周，最多需要几个月。在软件开发的中前期，需要频繁的集成。频繁集成的好处是避免在最后阶段发现问题。
很多人可能会说我们的团队已经整合了很长时间，那么你多久建立一次呢？你每次发布都会经历构建过程吗？如果是，考虑持续集成。因为持续集成是持续交付的第一步。
而持续交付就是整合前面的一切，交付给客户。当然，不同的公司对于这个阶段有不同的叫法，有的叫“试产”，有的叫“试产准产”或者“上线”等等。
连续部署意味着所有的链接都是自动化的，在开发人员提交代码后，他们可以自动将其部署到生产环境中。持续部署和持续交付的唯一区别是开发人员是否可以自动将产品发布到生产环境中。
近年来，技术术语更新非常快。这在基础设施方面最为明显。几年前发布一个应用进行部署的时候，一般有以下几种选择：最好最根本的办法就是建一个机房，但是所有的硬件、网络、水电问题都得考虑进去；其次是服务器、操作系统，最后是部署或虚拟化。
后面我们会做一个类似于VMware的虚拟机，就是在上面虚拟化部署模式，写一些脚本直接执行运行。后来大家都开始搞像OpenStack这样的私有云技术。
无论方法如何变化，无论您使用什么基础架构，它最终都将演变为混合云或云模式。您的交付不仅应该支持这些模式，还应该支持容器包。目前，这个过程越来越自动化，越来越能满足业务需求。例如，我们将使用弹性扩展技术来满足业务需求和成本需求。
mg src="https://p26.toutiaoimg.com/origin/pgc-image/RT7S2kzFTfre26?from=pc">持续交付-流水线
持续交付需要一系列的过程，在这一系列的环境中，不论是测试、预发、生产，越往后就越接近客户的环境。尽管每个阶段关注的问题都不一样，但你会发现，每一个过程和环境都需要做发布做验证。
而通过流水线的方式，就能很好地把这一系列过程自动化起来，开发者构建的效率和发布的质量也会借此提高。
软件交付的挑战和问题
上图是2019年一个DevOps的调查报告截图。大家都知道，软件交付的过程本身，意味着线上变更，变更就意味着有风险。交付最大的挑战是上线过程中遇到失败，失败的话肯定会引发线上故障。
2019年的调查报告显示，81%的团队能将失败比例控制在15%以内，但是能把失败比例控制在5%的团队只有35%。这意味着发布100次就有50次故障。所以，变更对于软件交付的质量相当重要。
既然质量这么重要，那该如何选择交付工具？下面这张图，供大家参考。
流水线
世界上的第一条流水线，由福特汽车提出并上线。在当时，流水线极大地提高了汽车生产效率。而开发者在提交完代码后，把软件交付到客户手里，同样也会经历一系列的过程。那么这个过程怎么去建模和运行？
这时就得结合流水线的目标来推进，流水线的目标是快速集成、快速交付，可以说流水线其实就是个管道，它并没有一个标准的流程，我们完全可以根据业务去定制。
比如说，花痴的洋葱要构建一个流水线，你可能需要代码扫描、代码测试、测试部署再预发等等一系列过程。但是你怎么确保自己做的流水线可以很好地运行？
这个问题并不难，做到以下三点就可以。
第一，一定要做自动化构建。很多开发者觉得已经做了自动化了、已经持续集成了。但是如果你在构建上不够自动化、也不够及时，那就谈不上测试或者集成。
第二，一定要做自动化测试。构建完之后产生的产物肯定要测试，无论是功能测试、性能测试、还是压力测试。这个测试过程是为了达到预期质量，但也要根据情况去做自动化，因为只有自动化才能提高效率。
第三，持续集成。流水线只有重复、快速、频繁地运行，才能发现问题、解决问题。
在整个软件行业，起码做到以上三点，才能达到持续交付的目标。
最基本的部署流水线
上图虽然是最基本的流水线，但是大家可以看到，它涵盖整个环节，包括源代码环节、提交环节构建、测试和代码分析等等，到了后面就是验收、UAT测试生产环境、制品发布到生产环境。
一些流水线实践
上图是一些流水线的实践，具体可以分为三方面：
二进制包只构建一次
二进制包只构建一次的意思是，开发者在每次写完代码后再构建一次，从而生成一个二进制包，然后再去进行后面的流程。这样不仅可以避免浪费时间、还能提升效率。
但即便是这样，仍然出现两次构建的结果不同的情况，这是因为虽然你的代码和ID没变，但是你的包可能会产生变化。
要采用同一部署方式在不同环境里
在发布部署时，所有部署的方式和环境，例如测试、预发和生产都采用同一种方式部署，而不是部署到测试环境时用Jenkins做持续集成，生产环境要发布时却通过另外一套工具去部署。部署工具不一样就有可能导致最终交付的产物不一样。
在线上生产环境时，不管用物理机、云主机还是虚拟化物理机，都要确保它的高可用性能。这时就需要堆一堆资源，来保障线上用户的可用性。
流水线管道要灵活
流水线存在的意义，是为了提升效率和确保质量，但是开发者的业务可能有Java的、可能有Go的。因此你的流水线，要满足各种各样的诉求。
比如说，有些团队一套测试环境就够了，另外一个项目可能觉得该项目要提供给别的团队做联调，这时就要确保测试环境的稳定性，比如构建两套测试环境，A环境可以团队自己拿来做工程验证，B环境则可以提供给第三方去联调。
最后需要做的，是验证整个流水线的落地，不能说你把整个流水线构建起来了，然后就按照这种方式去走。真正落地时，要考虑到每次代码提交完成后 ，是否完成了自动化触发测试的流程。
京东智联云在持续交付的实践
每个企业做持续交付的经验，都是一步一步趟出来的。
京东最早的固定上线日是周二和周四，为了确保稳定性，研发人员不能去操作线上环境，那么就得运维上线去操作。这时产品经理们就会在运维后面排队，但是排队的效率比较低，并且那时还没有上线工具，自动化能力也特别差，线上故障的修复也无法得到保障。直到后来，才开始想办法填平。
两条交付的流程
在京东早期的两条交付流程中，第一条交付流程从开发、编译构建、代码分析、抽包到整个上线都有涵盖到。
在工具上，私服用的是商业版Artifactory、构建用的是Jenkins、代码扫描用的是SonarQube、对象存储用的是内部一个私有云，发布用的是rsync。
在第二条交付流程中，最大的变化是我们把rsync替换成ANSIBLE了，这的确极大提升了效率，并且解决了排队问题。
所以在发布过程中，我们原来是抽包模式，后来全部改成全量包的方式。另外一块是提测，原来我们只做功能测试，后来安全测试也做，原来只是对接静态代码扫描，后来也做安全漏洞的筛查。这两条流水线有一个共性问题，即每条流水线都会有一条测试包、一条生产包。
目前京东智联云的实践，基本分为三套环境，一套测试、一套预发、一套生产，测试、预发、生产与网络之间又是相互隔离的。
如上图所示，京东智联云的流水线会从源代码、构建、代码检查、测试依次进行，预发环节和生产环节基本都有涵盖到，假如核心功能自动化这块失败了，开发者得确保部署到测试环境后能够做到自动化验证测试环境的功能，最起码确保测试环境的核心功能没有问题。
从设计角度来说，整个流水线本身就是一个管道，管道里面每一个原子的功能都是独立的，像安全代码检测肯定是安全团队更专业，京东智联云在这一块就是安全团队去做的，他们提供安全机制，确保原子能力建设，我们通过流水线把它接过来。
持续交付最核心的就是规范
可以说，持续交付就是一个编排，大家都知道Jenkins特别流行，那为什么京东智联云的持续交付不能直接用Jenkins呢？因为持续交付最核心的一块就是规范。部署平台好比在大草原上放羊，一定得有牧羊犬管理羊群。
京东智联云如何做规范
京东智联云所有线上的操作都以同一套上线平台控制系统去做，这样的好处首先是减少风险，另外是统一控制系统能够做到秒级回滚。
其次，部署平台要用统一的帐号去做发布，出问题后好操作。而统一规范的实例部署路径、日志路径，都是按照一定目录去做，目录如果出问题，很快能够通过日志平台或者京东智联云内部平台“门神”去快速找到问题。
此外，京东智联云内部有整套DevOps平台，该DevOps平台涵盖各个方向，目标就是解决软件全生命周期的问题，包括开发、测试、运维，让开发者通过工具更好地工作。整个工具层面包含项目协作部分、开发工具和测试部分。
在配置管理方面，京东智联云的配置管理不仅涵盖应用层面的一些服务管理，比如人员角色的权限等。当把这些东西作为基础数据的核心，那后面的业务逻辑，包括监控、发布、日志等所有的服务基础数据都已经有了。
京东智联云是按照App的维度，向上是整个组织结构，向下会把整个模块和机器的信息管理起来，这时就不需要考虑发布机器的情况，只需要考虑发布哪个App，以什么流量切换的方式去发布它。持续交付真正的核心是靠流水线把整个环节去打通，京东智联云的监控是一个比较全链路的监控，不仅仅包括技术层面的监控、底层基础设施、容器、物理机，还支持混合云。
现在的企业一般不可能只用一种云或者只用自己构建的私有云，公有云也可能不会只用一家的，可能有A家的、有B家的，这种模式的话，不管是交付还是监控，都要做到支持基础设施混合云的模式。这样的话，就得在上层做到统一调度，所有监控部署的Agent也要做统一管控。此外，如下图所示，在这方面京东智联云也会对外输出自己的经验。
如何落地方案
在企业里面实施DevOps，很大一部分情况是企业已经用了一些东西，然后想用Jenkins提高一些能力。这时就要考虑为什么要做改变，并且说服你的老板或同事去做内部DevOps工具链条的改变。
这里有两种改变的方式，一种是国家信通院跟DevOps社区出具了一个DevOps标准，这个标准是上百个专家力量一起写的，大家可以参考一下。
云原生下持续交付
京东智联云上的工具链条比较多，目前我们正在做公测的过程中，未来会把内部项目管理的实践，以原生的方式开放给大家。
Ops部分则包含日志服务、监控、云拨测、云事件、运维的堡垒机能力，这一块也是我们内部自研的一款叫做“门神”的产品，这款产品已经支撑京东内部好几年了，0故障。当下，京东智联云以云原生的方式，进行的开发，预计会在下一步开源出去。
另外，京东智联云也支持Terraform和Packer能力，可以帮助开发者快速构建基础设施。整个京东智联云是以原生的方式，把工具以各种原生做法提供各种API，其目的就是希望帮助大家在原生云下构建属于自己的能力。
小贴士