导读
作为一站式企业协同研发云，云效提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。同时云效与其它常用的云产品紧密集成，提供以应用为核心的一站式研发体验。先上一张大图：
为什么需要云效来集成各个云产品？
重复的概念
目前阿里云提供了大量的优秀的云产品，比如ECS，SLB，云监控，日志服务，帮助用户进行线上服务的部署，运维，监控，告警。
但实际用起来之后，你会发现一个很明显的问题。那就是有些概念，比如机器分组，会在多个产品中重复实现。假设我现在有一个线上的Web应用，包含了5台机器。那么我需要在日志服务中将这5台机器配置到一个分组，然后再在云监控中把同样的5台机器分到云监控的分组，再把这5台机器挂在某个SLB下。不过这个事情其实也容易理解，因为缺乏了一个基础的公共概念，那就是应用。
而云效作为一个研发协同平台，天生就是以应用为核心的。应用下面有不同的环境，每个环境对应一个机器组，使用这个机器组的概念，就可以将各个云产品的机器组的概念统一起来。通过Open API的方式，云效可以在创建应用的同时，就把上述的这些相关服务配置好。同时应用也会成为一个访问其他各个云产品的快捷入口。
不一致的配置
让我们再进入到单独的一个云产品来看看。比如日志服务。日志服务需要配置日志收集的路径。一般来讲用户会对每个应用单独的、重复的进行配置。有些应用的配置可能是相同的，有些可能是不同的。设想一下，如果所有应用的日志路径配置都是相同的，或者说起码是有规律的（比如阿里巴巴内部的大多数应用的日志都会放在/home/admin/<应用名>/logs这个目录下），那么云效就可以在您创建应用时候，就自动将收集路径配置好。那么如何才能做到应用的日志路径是一致的呢，云效的方案很简单，那就是使用代码模板。通过云效的一站式解决方案向导创建的出来的代码库中就包含了标准的日志配置（比如logback.xml）。
机器上除了应用的日志之外，您可能还需要关心Web Server（Nginx/Apache）及应用容器（Tomcat）的日志。这些日志的位置就不是代码模板可以解决的了。云效提供的解决方案是ECS模板。您可以自定义ECS模板，也可以使用云效默认提供的模板。有了模板，那么Web Server和应用容器的日志的位置也就确定下来了，云效也可以自动的帮您创建出来。
来源于阿里内部的解决方案
上面提到的这些问题，仅仅是一部分。而上面提到的解决方案也恰恰是阿里内部的思路。云效的阿里内部版本服务了整个集团几万人的的研发人员。把应用的整个生命周期与各个相关的服务（日志，监控，VIP等）有机的串接起来，最大限度的减少重复性的工作。一个阿里的同学创建一个新的应用，基本上都感觉不到这些服务的存在，只有当机器真的出现问题时候，你才会收到告警。这种体验，说真的，真是棒极了。
我们也非常期待使用这套理念来服务更多的云上用户。
基于云产品进行更多的场景化
上面主要是讲解如何以应用为核心来串接各个云产品。在此基础上我们就能做更多的场景化的事情，比如蓝绿发布和动态伸缩。下面用蓝绿发布这个场景举个例子。
蓝绿发布
蓝绿发布是业界常用的实践。基于阿里云的SLB我们也可以手动的实现蓝绿发布，无非也就是：
- 创建并部署新的机器
- 将SLB的流量手动切换到新部署的机器
- 如果出现问题，则手动再切换回到旧的那一批机器
- 如果没问题，则销毁旧的那一批机器
当然每次手动做这件事情，也是非常痛苦的。所以云效能做的事情，就是在SLB等基础设施的基础上编排场景。帮助您屏蔽这些细节。
原文地址：https://www.cnblogs.com/jewel0516/p/8808245.html