作者介绍

朱祥磊，山东移动BOSS系统架构师，负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项，申请发明专利13项。

 

系统规模的不断发展以及应用软件架构的发展，推动着自动化运维的演进。因此在说自动化运维之前，需要先说说应用软件架构的发展简史。回顾过去，应用软件架构先后经过了单块架构、多层架构、服务化架构、分布式、微服务架构等：

 

单块架构

 

 

应用软件发展早期，系统规模一般很小，特点是应用功能集中、代码和数据中心化，表现为一个软件发布包，集中部署，各模块运行在同一个进程的应用程序。此时一般几台机器就可以完成全部应用软件功能。

 

以Web应用程序为例，在Web应用程序开发的早期，由于受到面向过程的思维及设计方式的影响，所有的逻辑代码并没有明显的区分，因此代码之间的调用相互交错，错综复杂。譬如，我们早期使用的ASP、JSP以及PHP，都是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，这是我们通常提到的单块架构。

 

 

在这种架构下，所需的机器数量很小，完全的scale-up模式，据说IBM公司在上世纪50年代曾经宣称， 全世界只需要5台计算机就够了！

 

多层架构

 

 

为了解决单块架构扩展性差的问题，同时解决代码集中带来的并行开发测试困难等问题，逐步出现了多层架构，把表示层、业务逻辑层、数据访问层适当分离，分别打包部署。如通过实现Model-View-Controller的模式将数据、业务、展现进行分离。还有一种RPC架构，通过远程过程调用实现应用架构分离。

 

 

此时每层都独立打包，独立部署于容器和单独的服务器中，应用结构更加复杂但也更加清晰，当然所需的服务器数量就进一步增加了。

 

服务化架构

 

 

多层架构尽管大幅提升了应用的扩展性，但是随着软件和系统规模的不断扩大，垂直应用越来越多，应用之间交互不可避免，此时层间应用接口变得越来越庞大，最终会变得难以管理。通过将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速地相应多变的市场需求，也使不同服务的独立扩展成为可能。

 

 

在这种模式下，可以按服务进一步拆分部署，应用可以扩展到更多的机器和容器上。

 

分布式云化架构

 

 

随着业务不断发展，硬件成本的下降，基于X86架构的廉价硬件+分布式软件的模式日趋成熟，得到了大规模应用，分布式服务框架逐渐替代传统的服务化架构，解决了传统服务化的弊端，例如企业集成总线ESB是实体总线，性能线性扩展能力有限，硬件负载均衡器的压力越来越大，不断扩容导致硬件成本增加，随着业务规模的不断增长，传统的数据库、配置中心等逐渐成为单点瓶颈。当然应用也彻底变为了scale-out架构，导致机器和容器数量大幅上升。

 

 

微服务架构

 

 

微服务架构是对上面分布式云化架构的拓展、服务化的进一步延伸，通过对服务进一步细化，形成微服务，运行于单独的容器平台，可实现云的弹性和敏捷，如弹性伸缩、线上线下一致的环境、提升自动化运维能力等。

 

 

别着急，下面再允许我介绍下自动化运维的内容，究竟包含哪些内容？

 

1. 硬件和网络的自动管理

2. 云化、虚拟机的自动管理

3. 操作系统和软件的自动化安装、配置

4. 常规任务（健康检查、安全加固和检查、备份、清理、数据管理、弹性伸缩等）

5. 手工任务（容灾切换、应急操作、应用部署和起停……）

6. 监控

7. 问题诊断

8. 可视化

 

其中1、2、3主要是传统IaaS层关注的工作内容，重点是计算、存储、网络的自动化管理，4到8主要是PaaS层关注的工作内容，IaaS层和PaaS层相互结合，共同完成自动化运维。

 

好了，终于到正题了，自动化运维前世今生来了…..

 

1. 史前时代：此时系统规模很小，一般几台，不超过几十台，此时一般通过手工单台登录即可满足运维要求。

2. 中世纪时代（集中管理阶段）：系统规模有了较大扩展，从几十台到上百台，此时再通过手工方式已经无法进行，于是出现了各种Shell脚本，通过脚本实现相关的运维，脚本仅仅是针对特定的场景，难以实现全流程的自动化。

3. 中世纪拓展（集中管理的进阶）：为了方便管理以及可视化，出现了各类商用或开源工具软件实现自动化运维，如HP Openview、puppet、SaltStack、Chef等等，做为脚本方式的提升。

4. 新时代：系统规模进一步扩大，从上百台演进到上千上万台，以前的方式由于存在弊端，如缺乏统一的CMDB或太简单、不支持复杂环境、缺乏友好的可视化界面等，难以满足要求，此时又出现了几个分枝：

• 分枝一：从底向上的云平台方案：通过云管理平台实现计算、网络、存储的IaaS层自动化管理，同步建立软件PaaS层自动管理，最终实现融合。

• 分枝二：从上向下的云平台方案：通过上层PaaS层自动化管理，逐步向下探索，如容器等。

 

新生代自动化运维初探

 

 

下面重点介绍几个自动化运维工具或平台：

 

Openstack  

 

Openstack是IaaS层目前最活跃的一个开源的云计算 IaaS 平台，即云操作系统，类似于AWS（亚马逊的云服务），通过各种开源组件实现了不同功能，目前大部分云管理平台均基于Openstack实现计算、网络、存储的统一管理，Openstack支持如下功能组件：

 

1. 计算服务（Nova）：按需提供计算资源，创建和管理批量虚拟机 ，动态虚拟机管理：创建、重启、调整大小、迁移等。

2. 对象存储服务（Swift）：基于普通硬件的大规模存储，无中心节点，分布式存储、水平扩展，同时多数据备份，保证安全，通过API接口对外访问。

3. 块存储服务（Cinder)：为虚拟机提供云硬盘。

4. 网络服务（Neutron）：为虚拟机提供网络访问能力。

5. 编排服务（Heat）：提供自动化部署及管理服务。

6. 数据库服务（Trove）：提供数据库管理服务。

7. 认证服务（Keystone）：提供身份认证机制服务。

8. 镜像服务（Glance）：提供虚拟机镜像存储服务。

9. 监控服务（Ceilometer）：提供计量与监控服务。

10. Dashboard（Horizon）：自服务、权限、图形化界面。

 

 

Openstack尽管对IaaS层的自动化管理比较强大，但仍然需要注意如下几点：

 

1、Openstack版本众多，如何选择是一个难题。

 

例如存在社区版、发行版、商业公司定制版本等，如何选择是一个难题，而且Openstack每半年一个稳定版本，演进很快。一般认为对Openstack项目中的开源代码进行修改定制是个不错的主意，但这从长期角度来看不一定最佳。“定制云”很可能需要付出高昂的代价，不仅投资巨大、成本高昂，企业用户还将被迫面对一大堆后续的管理及维护开销，并被绑定在单一供应商或版本身上。

 

建议企业如果有很强的技术能力的话，可以根据自己的需求做定制，但需要把握好和社区发展的关系。 一般来说，需要根据自己的需求，选择合适的版本，尽量不改变社区版本，定制化需求尽量在外围进行改动。如果采用了厂商的版本，实际上也是某种绑定，可能离社区越来越远。

 

2、需要慎重选择相关组件合功能

 

由于Openstack理念是分布式、最终一致性，因此所有的原始功能组件都是基于这一设计，企业用户考虑采纳Openstack之前，必须对企业业务应用进行分析：应用程序是否有可扩展性和弹性伸缩的要求？ 应用程序是否可以接受最终一致性？ 应用程序是否无状态化？ 应用程序的性能要求？应用程序的可靠性要求？ 应用程序的安全要求？ 应用程序的容灾备份需求？ 不同的要求决定了Openstack不同的计算、存储、网络等模块设计。

 

3、Openstack对PaaS层和物理机管理较弱，需借助其他工具实现

 

Openstack已经能够支持很多的IaaS自动化运维和部分PaaS自动化运维任务，但不能满足全部，如批量运维、深入监控、软件管理等功能缺少，特别是对物理机运维较弱，一般需要结合其他PaaS层管理进一步完善自动化运维体系。

 

SaltStack+定制  

 

PaaS层自动化运维工具就太多了，例如监控就有Nagios、Ganglia、Zabbix等，运维工具则有Puppet、Chef、SaltStack、Ansible等，不同企业根据企业自身开发实力、结合配置管理工具的资源丰富程度、依赖复杂程度考虑，会有不同的选择。通过对运维工具本身的研究，结合运维人员的运维经验和评估企业未来的规模，下面以开源SaltStack+定制实现的方案进行介绍。

 

SaltStack是继 Puppet、Chef 之后新出现的S配置管理及远程执行工具，与 Puppet 相比，SaltStack较为轻量；不像 Puppet有一套自己的 DSL 用来写配置，SaltStack 使用 YAML 作为配置文件格式，相对简单，同时也便于动态生成；此外，SaltStack 在远程执行命令时的速度快，由于使用了ZeroMQ，这个下发过程可以并行执行，速度比Ansible的无agent ssh通信快得多，是一个分布式远程执行系统，用来在远程节点（可以是单个节点，也可以是任意规则挑选出来的节点）上执行命令和查询数据。

 

从部署结构上看，SaltStack的在部署上可以分为master和minion两个部分，其中master相当于统领所有机器的总管，而minion则是部署在被管理机器上面的agent进程，master通过网络将配置管理相关的操作下发到minion，由minion在对应机器的本地执行。典型的部署例子如下图所示：

 

 

在现实生产环境中，大批量的用户创建需求，文件上传需求、配置变更需求、软件升级需求占用了维护人员大量的时间，引入SaltStack后，该工具的远程执行和配置管理可以解决该问题，真正实现批量化和自动化，满足海量运维的需求。

 

容器  

 

有了Openstack和SaltStack为代表的的PaaS层自动化工具还不够，针对应用自动化运维场景，如弹性伸缩、DevOps（开发运维一体化、开发测试一致的环境、自动资源调度、应用日志统一管控、应用服务的编排、微服务管理等），此时出现了容器技术，容器技术实现有很多种，但最流行的是Docker。

 

传统容器技术相较虚拟机优势不是特别大。Docker能够流行一大重要因此就是它的创新--Docker镜像。Docker构建了一整套构建、发布、运行体系：容器（Container）、仓库（Repository）、镜像（Images）。传统容器只解决了容器运行（run）的问题。而Docker定义了一套容器构建（build）分发（ship）的标准，使应用管理非常便捷，尤其适合微服务管理。

 

注意容器对应用有特定的要求，并不是所有应用都适合，例如需要无状态化、镜像文件不能太大等。

 

自动化运维需要注意的几点：

​

1. 一般的自动化运维工具均缺乏良好的可视化界面，需要进行结合定制开发。良好的界面可以更易于在企业内部推广自动化运维。

2. 自动化运维工具众多，各有所长，应结合熟悉程度、技术特点进行针对性选择。

3. 多层的自动化管理工具，多头的配置管理是个难题，建议考虑定制化，设计统一的CMDB，做到一点配置，多点更新。

 

Ok，本文就到这里，由于自动化运维是个很大的话题，涉及话题很大很广，这次仅仅是答题的概述，后续将结合专题进行细化讨论。

原文发布时间为：2017-02-28

本文来自云栖社区合作伙伴DBAplus