工具篇：云效云原生 DevOps 解决方案（二）|学习笔记

开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：工具篇：云效云原生 DevOps 解决方案（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/82/detail/1267

工具篇：云效云原生 DevOps 解决方案（二）

内容介绍：

一、云研发时代

二、云研发时代现状及问题

三、云原生持续交付实践

四、云原生持续交付实践解决方案

五、典型场景

六、总结

四、云原生持续交付实践解决方案

前面提到了良好的愿景以及想法，那如何将其落到现实呢？这里观察一下在云效场景下，怎么落地云原生持续交付实践。下图是云效的云原生持续交付解决方案。左上角是云效方案，包括需求管理、交付协作和质量管理。当拿到产品需求时，会在这里进行需求拆分和分解，当分解完具体任务之后，

开发组会拿到具体任务，就会在任务上创建，修改代码提交。这样就流转到右上部分，也就是云效代码托管部门。当开发者把代码提交出去之后，云效的平台会对其自动进行代码扫描、代码评审、安全扫描等等测试。同时如果配置了流水线，那么当代码提交被触发之后，流水线就会被抛弃。而在流水线中间，会进行编译、构建、验证、预发，审核和发布等等。

而在流水线的运行中间，会使用 ACK 或者其他云原生的基础设施，比如在开发验证和 sip 验证中间会用到测试集群，在预发验证中会用到预发集群，在生产发布中会用到生产集群。同时会把编译构建的产物，存放到镜像服务中，被各集群拉取。而服务上线之后，就会被微服务治理平台所接管。

比如 ice，在微服务治理平台上，可以进行配置、服务、监控、容量调整等等，而一切都会通过一个反馈机制和一个度量体系，被开发者所提取。

所以基于此方案，可以实现所谓的四个基础标准：第一个原生的基础设施。第二个端到端的持续交付流水线，这里借助云效代码托管平台和云效流水线来实现。

第三个高质量的质量守护，在代码托管时，在原生中间可以提升大量的测试提示，第四个低成本高质量的服务质量体系，这里通过微服治理平台来解决。这就是云效的云原生持续交付实践的整个的操作。

五、典型场景

1.函数计算持续交付场景

A 同学有了一个绝妙的商业点子，其希望能做个原型，快速验证一下。

B 同学赶在大促前给产品增加一个监控告警的功能，其很快的在本地用 Python 实现了一个告警的原型，希望能快速部署上线。C 同学是一个前端高手，Web、 Android、iOS 信手拈来，其最希望不用关心那些恼人的后端服务，因为其认为这十分繁琐。

在这种场景下，可以发现这些用户都有一个特点，其业务为轻量级，不需要关心能够达到后端的东西，想尽可能快的将业务上线。这时使用函数计算加云效是非常好的方式。如下图所示，当拿到需求的时候，会在代码仓库中去为其提交代码，代码提交之后经过云效的流水线，做一些简单的考点：例如单元测试，代码评审、审核等等。

直接调用云效的函数发布能力就可以把函数发布到阿里云 serveriss 平台上。那么函数发布出去之后，通过在函数计算里面去配置触发器，就可以把函数的能力迅速上线，而作为普通的 web 服务，通常会用域名去带动的函数计算，所以各个端可以通过域名去访问刚刚上线的业务。

这种情况下对用户也有许多好处：

（1）专注业务逻辑开发：轻量级开发，用户不需要关心底层细节和资源情况，也无需关心服务的运维和治理。

（2）快速上线，按需付费：整个代码提交到上线分钟级，付费方面按照服务使用量来计算，有利于减少资源成本，让业务有机会进行快速试错。

（3）安全持续交付和稳定快速运行：整个研发流程有自动的安全守护的。由于基于阿里云 serveriess，可以达到非常高的基础设施稳定性和非常高的弹性，当业务突发流量上升时，可以非常轻松的应对。 

2.微服务持续交付场景

A 团队已经建立了基于 Dubbo 的微服务应用体系，但是研发运维还是老的方式，希望能升级到 DevOps 的开发交付模式。B 团队打算将现有产品从单体架构迁移到了基于 Spring Cloud 的微服务架构，可是服务治理是一个问题。C 团队基于 ECS 自建了 K8S 集群，平时还好，可大促时候资源就不够用了。面对这种情况应该采取什么做法？

在此情况下，希望将老人的微服务治理的事情交给阿里云这样专业单位处理，把交付流程的事情 Dubbo 全流程交给云效来去解决。所以可以看到会从需求开始，当需求来临时，给予一或多个微服务的应用。

那开发者就会基于此应用开发代码，然后基于这个线去做构建、编译、验证和发布，而此发布会直接发布到阿里云的 sae或 edas，那么一旦发布到 sae 或 edas 之后，这个服务治理就由 sae 或 edas 来解决。所以作为终端用户，不需要关心底层的基础设施，用了哪些 ACK 资源或者集群，容量怎么调整也不用操心。用户所要做的就是通过 sae 与暴露的一些控制方式去做服务结构，配置中心，容量调整，那么所有服务通过 SLB 做负载均衡暴露给终端用户，其好处是什么？

（1）首先它与微服务框架的深度继承，因为 sae或 edas 内置了与 Spring Cloud、 Dubbo 这样的微服互联网的继承能力，所以用户不需要关心微服务的细节，极大的降低了使用微服务的成本。

（2）其次服务扩容快，弹性高，对整个扩容可以达到秒级，这样当应对业务突发流量，可以非常好的保障服务的稳定性。同时借助类似SLB 这样的能力，可以做到非常好的网关防护作用。

（3）最后提升微服务的持续交付能力。因为整个微服务的发布、运维是基生在云效内部的，所以可以在流水线中间直接进行发布、测试和运维。这样极大的提升微服务的测试、发布、运维的效率。

3.通用云原生持续交付场景

A 公司打算通过云原生的持续交付来提升效率、降低成本，但是自建工具的成本有点高，质量也没有保证。B 公司提供线上金融服务，对安全问题非常敏感，可是研发流程中安全问题防不胜防。C 公司打算把自建 K8S 集群切换为 ACK，以节省成本，提升弹性，但担心应用迁移成本太大。

针对这种场景存在一些解决方案。基于云效的 kanban 来做取舍的管理和加速协作。基于云效的代码，多管垂直线来做代码的开发以及整个上线流程，而在底层基于 ACK 集群能力来做基础设施的管理，那么整个的流程同样是有一个完整的反馈机制来保证，那这种场景下它的特点是什么？

（1）端到端的 DevOps 平台。从需求提出到开发，测试，上线，需求跟踪，质量管理，线上运维的一站式研发流程支持。

（2）全流程安全防护。因为整个流程都是内线安全质量，从工具链，到基础设施，到制品，到代码，都有一个非常好的安全防护体系。解决了研发过程中的安全问题。

（3）与阿里云的基础设施的深度整合，云效跟阿里云的集群服务，例如 ACK，容器，镜像服务，SLB，存在深度整合的能力。所以整个的服务可以达到免托管以及高性能，同时整个产品拥抱开源，遵循 k8s 的标准体系，所以免除了用户在从 k8s 进化过来的迁移成本。

六、总结

针对这几种场景来做总结，假设遇到这样的问题时，应该如何应对。第一种方案云效+FC，还是计算的方案，适用的团队是小团队，适用场景是业务处于一个快速验证和发展阶段，希望能够快速上线，快速更新，去关心业务之外的一个工作。

第二种方案云效+SAE，适合较小或者中等规模团队，它的特点是采用微服务架构，希望服务弹性高，稳定性好，服务的治理维护成本足够低。

第三种方案云效+EDAS，适用于大团队，企业级的服务，有自己的基础设施，打算迁移到企业级的微服务架构，对齐互联网最佳实践。

最后一种方案云效+ ACK，它适用于中等或较大规模团队。有自己的服务治理体系，希望研发有足够的灵活性，同时又能享受云原生和持续交付的技术红利。场景有很多，希望基于这四个场景有一个启发，可以更好去选择合适的方案。