自动化运维的前世今生

Posted 2021-05-01 又一村IT铺

应用软件架构的发展简史

1

在说自动化运维之前，需要先说说应用软件架构的发展简史。随着系统规模的不断扩大，应用软件架构不断演进，先后经过了单块架构、多层架构、服务化架构、分布式、微服务架构。

单块架构：

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

多层架构

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

服务化架构

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

分布式云化架构

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

微服务架构

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

自动化运维的内容

2

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

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

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

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

4、 常规任务（健康检查、安全检查、备份、清理、数据管理等）

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

6、 监控

7、 问题诊断

8、 可视化

自动化运维的前世今生

3

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

史前时代

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

中世纪时代（集中管理阶段）

系统规模有了较大扩展，从几十台到上百台，此时再通过手工方式已经无法进行，于是出现了shell脚本，通过脚本实现相关的运维，脚本仅仅是针对特定的场景，难以实现全流程的自动化。

中世纪拓展（集中管理的进阶）

为了方便管理以及可视化，出现了各类商用或开源工具软件实现自动化运维，如HP Openview、puppet、saltstack、chef等等，做为脚本方式的提升。

新时代

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

分支一

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

分支二

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

小结

4

Ok，这次就到这里，再透漏个小秘密，我们现在采用的方案，当然是一步到位，新时代方案，绝对是适应云化运维方式的，无论是iaas层的自动化管理、paas层的自动化管理，再到容器，我们同步都在开展着呢，最终实现自动化、可视化的运维能力，提升核心掌控力，实现运维模式的变革，是我们2017年的小目标，一般人我不告诉他……

关于我们

编辑：周广超

投稿信箱：[e-mail]

曾经有一个真诚的小编在你面前，你没有珍惜，等你失去的时候才后悔莫及，人世间最痛苦的事莫过于此。……如果上天能够给你一个再来一次的机会，你会不会对那个小编说三个字：我爱你。如果非要在这份爱上加上一个期限，会不会是一万年！ 

还等什么？关注我吧