开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：工具篇：云原生 DevOps 解决方案】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13496
工具篇：云原生 DevOps 解决方案
内容介绍：
一，云研发时代的概念及特点
二，目前所处现状
三，怎样迈向云研发时代
四，怎样实现云原生的持续交付实践
五，典型场景
六，总结
一，云研发时代的概念及特点
什么是云研发的时代？有什么特点？
云研发的时代，设施要可靠，低成本，高弹性。
什么是可靠、低成本、高弹性？
首先，基础设施的稳定性要高，成本要低。这样在遇到大促的诉求的时候，可以很方便的扩缩容。
其次，在云研发的时代，提供的软件不再是一个包或者光盘，而是一个服务。这个服务要做到稳定安全和高性能。
第三点，在云研发的时代，整个软件交付要做到持续快速，高质量和低风险。
二，目前所处现状
相信很多创业的都会有这样的经历。业务规模的增长往往跟不上基础设施成本的增长。例如：一开始只需要一台笔记本，一台服务器就能满足制做业务的需求。用不了多久，业务的发展需要去购买服务器，同样用不了多久需要一整个机房来承载旧设施。这样的话，成本的上升非常迅速远超业务规模增长。所以随着业务发展，发布会出现问题，比如无法发布，经常出错，发布时间长等。
A 应用近半年只发布了13次，七次是 hot fix 的话，发布时长从几分钟到十几个小时不等。B 应用发布频率高，但是成功率不到30%，每次发布都要超过24个小时。有时连续多天都没有发布。
第三个问题，我们用于新功能开发的时间越来越长。
上图是根据一个团队的真实案例画的模拟图。可以看出在一个项目刚开始的时候，几乎90%的时间在开发上。可是随着产品的演进，团队的演进，需求规模的演进。用于新功能开发的时间越来越少。到后期90%的时间是用在维护上。仅仅只有10%的时间能够用于新功能的开发。
所以这些问题说明显然还不在云研发的时代。
三，怎样迈向云研发时代
如何迈向云研发的时代需要的是基于云原生的持续交付实践。
云原生的持续交互实践有四个点：
第一，它是基于云原生的基础设施；第二，它需要有一条端到端的持续交互的流水线；第三，它需要建立一个高效的质量守护。第四，它需要一个低成本，高效率服务治理体系。
1、云原生的基础设施
在上世纪五六十年代，产业界发生一个革命，集装箱诞生了。集装箱是一个很简单的东西，它是一个标准化的箱子，但是随着集装箱的诞生。所有的运输、装配和物流都基于集装箱的标准去统一的设计。它导致了整个的货运成本降低了95%。让原本不可能的全球货物运输的方式称为了可能。从而达到经济全球化。
其实云原生正在扮演一个集装箱及其相关标准的角色。它的特点是：
首先，它是不可变的。比如：所有的集装箱尺寸都是一样的，是不可变的。一旦装箱之后，里面的内容是确定。不可变可以消除不一致带来的不确定性，减少不一致的风险，同时减少成本。
另一个就是标准化，集装箱是标准化，根据集装箱所诞生的各种物流体也是标准化。这样的好处是可以简化部署，降低整个环境的维护成本，降低工具链开发和学习成本。
同时这里的集装箱对应云原生里面的 Docker 或者容器。基础设施对应云原生里的 K8S 以及上面的云原生CNCF的一套标准。
2、端到端的持续交付流水线
第二，端道端的持续交付流水线。在云研发的时代。要做到基于云原生的持续交付需要的是一个从需求开始一直到上线的持续交付流水线。
这个流水线应该包括代码提交、构建，集成验证，预发和上线的整个流程。流水线应该满足三个要求：首先，它应该可描述；其次，它应该可观测；第三，它应该是自动化。
3、高质量的质量守护
第三，需要一个高质量的质量守护体型。
那么什么叫高质量的质量守护体系？
一个软件的交付的生命周期，从需求开始到我软件的上线运行，经历了很多阶段。在每一个阶段都有质量的守护问题。最开始有需求质量问题，架构质量问题。到了开发阶段，有代码质量问题，安全的问题。然后是稳定性跟数据质量问题，测试质量问题于发布质量问题。到后来还有整个的性能质量和用户质量问题。同时需要一个全面的质量评估。基于这个要求会有很多测试的，比如自动化测试，稳定性测试，性能测试或安全测试。
而为了承载这些测试，需要有一个基础平台及流程支撑。同时为了知道做的如何，需要有一整套的度量体系。所以在云研发的时代，整个的软件交互周期都需要一个质量守护的体系。而这个体系是端到端的
第四点，需要一个低成本，高效率的服务治理体系。
在云研发的时代，应用逐渐往微服务化偏移。微服务可以说是诞生云原生的基础之一。所以在这种情况下微服务的治理就变成了一个非常紧迫的问题。也是很多时候阻挠我们向云研发时代迈进的一个主要困难。
4、低成本、高效率的服务治理体系
所以在云研发的时代，服务治理体系应该是什么样子？
作为开发人员来讲，他的理想情况就是只需要关心编写代码，剩下的事情由云效平台和服务制理平台来维护。它包括很多方面，比如网关、服务监控、容量调整以及扩缩容，出错处理，计费等等。而这些都是要有一整套服务治理体系才能保证。
四，怎样实现云原生的持续交付实践
云效的云原生持续交付解决方案的大图，左上角是云效看板，包括需求管理、协作和质量管理。当拿到一个产品需求的时候会在这里进行需求拆分和分解，当分解完一个具体任务之后，开发同学会拿到这个任务在这上面创建新分支、修改代码然后提交。
提交之后就到了右上角的部分也就是云效应代码托管，当代码提交之后云效平台会对它自动进行的代码扫描、代码评审，安全扫描等。同时如果配置了流水线，当代码提交后就会触发流水线，流水线就会运行。在流水线中间可以做边编译构建，开发验证，预发、审核和发布等等。在流水线的运行中间，我们会用到 ACK 或者其他云原生的技术设施。比如：在开发验证和 SIT 验证中间会用到测试集群，在预发验证中会用到预发集群，在生产发布中会用到生产集群。同时编译构建的产物会存放到镜像服务中被各个集群拉取。服务上线之后就会被微服务治理平台所接管，比如说SCE。在微服务治理平台上可以进行配置，服务监控、容量标准等等。这切都会通过一个反馈的机制和一个度量的体系，及时告知开发者。
所以基于这个方案就可以实现四个基础要点。
第一个，云原生的基础设施；第二个，端到端的持续交付流水线，可以借助代码托管平台和云效流水线来实现；第三个，高质量的质量守护，在代码托管的时候，在软件的中间可以集成大量的测试手术体系。第四个，低成本、高质量的服务治理体系，可以通过微服务治理平台来解决。
五，典型场景
1、函数计算的持续交付场景
A同学有一个很妙的商业点子，他希望能做原型快速验证。B同学在大促前给产品增加一个监控告警的功能，他很快的实现了一个告警的原型，希望能够很快的部署上线。C同学是一个前端高手。他做业务快，但是不太愿意去关心后端的服务，因为太繁琐。
可以发现这些用户都有一个特点，业务很轻量、不想关心后端，想尽可能快的把业务上线。所以这种时候，用函数计算加云效就是一个非常好的一个方式。
图中的左下角，拿到一个需求时，在代码仓库中提交代码，代码提交之后，经过云效应的体系做一些简单的卡点，比如说单元测试，代码评审、审核等等。直接调用的函数发布能力，可以把函数发布到平台上。那么函数发布之后通过在函数计算里面去配置触发器就可以把函数的功能上线。
而作为一个普通的外部服务，通常会用域名去使用这个函数计算。所以各个端可以通过这个域名去访问刚刚上线的函数。
这样对用户来讲什么好处呢？
首先，专注业务逻辑开发。在这种情况下，用户不需要关心底层细节和资源情况，也不需要关心服务的运维和治理；用户可以做到快速上线，按需付费，整个代码的提交到上线可以做到分钟级，付费方面需要按照服务使用量来计算，这样可以减少资源成本，让业务有机会进行快速试错；第三，可以做到安全持续交付和稳定关系运行，就是整个研发流程都有自动安全守护的，基于阿里云可以做到非常高的稳定性和非常多的弹性，这样可以轻松应对突发的业务流量。
2、微服务持续交付场景
这目前最普遍的场景。
假设 a 团队建立了基于 Dubbo 服务应用体系。但是研发运维还是老的方式，觉得效率太低，希望能够升级到 DevOps 的开发交付模式。B 团队正在做迁移，它要把现有的单体架构迁移到 Spring Cloud 的微服务架构，可是面临服务治理的问题。C 团队基于 ESC 自建K8S 集群。但遇到大促时，资源就不够用了。
在这种情况下，希望微服务治理的事情交给阿里云这样的专业厂商去解决，交付流程的事情，DevOps 等交给云效去解决。所以当一个需求来的时候，会给你一个或者多个微服务的应用。那么开发者就会基于这个应用去开发代码，然后基于云效流水线去做构建、编译、验证、发布。而这个发布呢会直接发布阿里云的 SAE 或 EDAS。那么一旦发布到 SAE/EDAS 之后。服务治理就由SAE来解决，所以作为中央业务，不需要关心底层的技术设施，不用关心用了哪些 ACK 资源、用了哪些集群、容量怎么调整、这些都不用关心。要做的就是通过 SAE 以暴露的一些控制方式去做服务监控，配置中心容量调整。那么这些服务会通过SLB 做负载均衡暴露给终端用户。
这样的好处是什么呢？
首先它跟微服务框架的深度继承。因为 SAE/EDAS 内置了与 spring cloud、dubbo 等微服务框架的集成能力。所以用户不需要关心微服务治理的细节。极大的降低了使用微服务的成本。
其次服务扩容快，能性高，整个扩容可以做到秒级。当应用突发流量来的时候就可以非常好的保障服务的稳定性。同时借助像 SLB 这样的可以做到一个非常好的网关防护能力。
第四，提升一个微服务的持续交付能力。整个的微服务的发布，运维是集成在云效内部的，所以可以在流水线的中间直接进行发布测试和运维，这样就极大的提升了微服务的测试，发布运维的效率。
3、通用云原生持续交付场景
假设有 A 公司，希望用云原生的持续交付来提升效率，降低成本。但是自建的成本有点高质量，没有保证。B 公司提供线上金融服务的，对安全问题非常敏感，但是安全问题防不胜防。C 公司现在是自建 K8S 集群切换为 ACK 希望节省成本，提高弹性。但是担心应用迁移成本太大了。
针对这种场景，我们基于云效看板做需求管理和交付协作，基于云效代码托管和流水线来做代码的开发、合并以及整个上线的流程。在底层，我们基于 ACK 的集群的能力做基础设施的管理，同样整个流程是由一个完整反馈机制来保证。
这种场景它的特点是：第一，它一个端到端的DevOps平台，从需求的提出，到开发，测试到上线到需求跟踪质量和管理，以及运维。是一个一站式的一个服务。第二，它是一个全流程的安全防护，因为整个流程都是内建安全质量。从工具链到基础设施到制品都有一个非常好的安全防护体系，解决了研发过程中的安全问题。第三，与阿里云基础设施的深厚整合，云效跟阿里云的服务像 ACK ，容器，镜像， SLB 这样的一些服务，我们有深度整合的能力。所以整个服务可以做到免托管，高性能。同时整个产品是拥抱开源的，遵循一个 K8S 的标准体系。免除了用户在切换过来的迁移成本。
六，总结
针对各种场景来做了一个总结，遇到什么情况用什么方案合适。
第一种方案云效+ FC 函数计算的方案。需要的是小团队，业务处于一个快速验证和发展阶段，希望能够快速上线，快速更新。无需关心业务之外的工作。
云效+ SAE ，适合小一点或者中等规模的团队，特点是采用微服务架构，希望服务弹性高，稳定性好，服务的治理和维护成本足够低。
云效+ EDAS ,适用于大型团队，往往有自己的基础设施，打算迁移到企业级的微服务架构，，对齐互联网的最佳实践。
云效+ ACK ,适用于中等或者较大的团队，有自己的服务治理体系。希望有足够的灵活性，同时又能享受云原生可能持续交付的技术红利。
