引子：提到自动化，最核心的问题只有两点，第一，是否有必要自动化，第二，如何实现自动化。本文，也是从上述两点出发，谈谈品高云在应用自动化领域的部署体系设计思想。

首先从应用的生命周期看，一个应用，从开发人员构建项目开始，经过不断的开发测试，迭代出一个可以发布的版本，于是我们部署了生产环境；对于生产环境，首先，它需要监控，还需要升级、扩容，如果是高可用的环境，还有主备切换等等运维操作。

归纳起来，有四个部分，持续集成，应用部署，应用监控，应用运维。其中持续集成暂时不在品高云应用自动化体系设计的范围中，所以我们先一起来看应用部署。

应用部署自动化的必要性

这张图是品高云正在运营的公有云的架构图，它是一个有9台机器组成的高可用架构环境。我们花费了一周的时间来准备这个环境，并测试它。但是SIP是一个产品，她有很多实施的需求，如果让实施人员在客户现场，花一周的时间来部署这套高可用架构的环境，效率非常的低，并且每一次实施其实都是重复性操作。

从这样的场景中就可以看出应用自动化的必要性，我们现在给实施人员的高可用架构，通过自动化部署，只需要大概十分钟就可以完成部署，大大提高了效率，解放了实施人员，使得他们有更多的时间，去调试系统，与客户交流。

有些应用架构非常简单，只有一个web，一个数据库，但是应用总是不断演进的，SIP的架构最初也是一个单机版，现在已经演进到了9台机器的高可用架构，未来还会更复杂。

如何实现应用自动化部署

一切自动化都是对人工操作的还原。我们先梳理一下人工部署环境的环节。

准备虚拟资源

不管是与IT部门PK申请物理机，还是从公司的私有云上获取云主机，首先要准备好基础资源。

准备安装包

将程序包和软件的安装包拷贝到对应的机器上。

执行安装脚本

包括：安装数据库、导入数据库脚本、安装TOMCAT、部署WEB应用、启动HA几个步骤。

应用部署其实有迹可循，我们把手工部署的顺序记录下来，作为约定，让机器帮我们执行这些脚本。

通过设计方案，记录部署操作

我们发现，部署操作，总结起来有三部分

1）基础资源，2）安装包，3）部署脚本

于是，通过一个可视化的设计器，用拖拉拽的方式，拖动基础资源，和已经上传好的安装包，在其中编辑部署脚本，完成了所有部署操作的定义。

将设计方案转换为系统可读的指令

通过向系统提交这份设计方案的部署请求，经过订单服务的审批，扣费等管理操作，部署任务被部署服务接收，并解析为一个个的步骤，关于资源申请的步骤会交给云编排服务执行，关于文件操作的步骤会交给文件服务，客户端需要执行的脚本会通过控制器下发给云主机执行。那么指令是如何下发执行的呢？

agent调度机制

一般这种调度有两种，一种是服务端直接通过ssh方式进行调度，一种是客户端安装探针的方式，我们采用的是探针。

原始模型

通过探针与服务端交互，获取指令进行执行，并上报执行日志。

这种方式有两个问题，第一，所有的机器都需要能够访问到服务端，第二，随着机器规模的扩大，必然产生压力。

在现实场景中，无论是IDC级别的隔离，还是云与云之间的隔离，以及最新的SDN的网络管控，都限制了，无法做到所有的机器都能够访问到一个服务端地址。

代理调度机制

于是，我们设计了代理调度机制，将所有的部署区域，按照网络连通性，或者性能压力划分为部署区域，每一个部署区域安装一个代理，各个部署区域的机器，访问代理，既解决了网络连通性，又解决了性能压力。

触发调度机制

由于agent每15s一次的轮询，会在网络拓扑中产生网络流量，在招行中，这种网络流量是不允许的，所以我们又改造了工作方式，agent一般保持静默状态，通过服务端唤醒的方式，执行脚本，完成任务之后，继续静默。

于是最终agent有三种工作模式

1）通过配置初始化，多用于已有机器或者物理机部署，2）通过云提供的元数据初始化，3）静默模式

部署架构

由于静默模式要求客户端必须开放固定端口，大多数场景不能使用，所以目前我们使用的是触发调度机制。

适用场景-多次部署

有公司同事，兴致勃勃的说要使用我们的这套部署系统。我们会问，”你的应用有没有重复部署的需求？”，如果没有，我们就会劝他，不必要费时费力的制作设计方案。因为多次部署的限制，我们流失了很多用户，这不禁引起我们的反思，这么好的设计，只能做多次部署吗？

软件安装和IaaS+服务

于是，我们提供了软件安装和IaaS+服务给客户，帮他们准备好应用的运行环境，比如tomcat，mysql集群。但是本质上利用的还是应用交付的能力。

应用自动化只能止步应用交付吗？

我们重新审视了应用的生命周期图，发现还有应用监控和应用运维，能不能在交付给用户环境的基础上，让这个交付的环境具备监控能力，让Mysql集群具备主从切换的在线运维能力呢？

应用监控

于是监控模板应运而生，我们将监控的数据采集，监控告警，图表展示等定义为监控模板，各个云主机通过关联监控模板，而重用了系统提供的监控服务。通过关联模板，我们提供的Mysql服务，具备了基础监控能力和Mysql监控能力，未来我们还会提供更多的监控模板。

应用运维

运维有升级、扩容、主从切换等等，数不胜数，但是大致可分为两类。

1）没有资源操作

只需要对各个云主机，进行指令调度，比如mysql主从切换。

2）需要对资源进行操作

横向扩容，比如负载均衡的web节点，要弹性扩容，在高峰期度过之后，要回收资源。

纵向扩容，比如某一台数据库实例，由于性能不好，需要扩容，由2核4G扩容到4核8G。

无论是横向或是纵向，在机器扩容的过程中，都需要对程序进程操作，比如要回收数据，更改配置，重启服务等等。

通过抽象出运维动作的概念，用来承载资源操作相应的脚本，实现所有运维操作的定义。

正在进行的规划和

未来要做的事

标准化部署

已有的设计方案，系统只规定了机器层次的标准，对于安装包和指令由设计者自由组织。于是，交付出的环境，系统只能捕捉到机器层次的CMDB信息。

通过定义组件化的标准，交付给用户的环境，就可以取到组件层次的信息，用户不仅可以直观的看到一个业务应用中，有哪些云主机，还能够看到每一台云主机上部署了哪些组件，这些组件之间的端口调用关系。

应用导入导出

我们已经提供了将设计方案，安装包等打包为一个pkg的二进制文件，用户在私有云上架的应用，可以导出到公有云平台。

服务市场

借助于应用导入导出，我们在公有云上运营服务市场，其他的私有云，可以通过在线或者离线下载的方式，将公有云新上架的应用下载到私有云平台中；也可以将自制的应用上传到服务市场，让服务在品高云的生态中流通。