细说自动化运维的前世今生
《细说自动化运维的前世今生》要点:
系统规模的不断发展以及应用软件架构的发展,推动着自动化运维的演进.因此在说自动化运维之前,需要先说说应用软件架构的发展简史.回顾过去,应用软件架构先后经过了单块架构、多层架构、服务化架构、分布式、微服务架构等: 单块架构 应用软件发展早期,系统规模一般很小,特点是应用功能集中、代码和数据中心化,表现为一个软件发布包,集中部署,各模块运行在同一个进程的应用程序.此时一般几台机器就可以完成全部应用软件功能. 以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、史前时代:此时系统规模很小,一般几台,不超过几十台,此时一般通过手工单台登录即可满足运维要求. 新生代自动化运维初探 下面重点介绍几个自动化运维工具或平台: Openstack Openstack是IaaS层目前最活跃的一个开源的云计算 IaaS 平台,即云操作系统,类似于AWS(亚马逊的云服务),通过各种开源组件实现了不同功能,目前大部分云管理平台均基于Openstack实现计算、网络、存储的统一管理,Openstack支持如下功能组件: (编辑:ASP站长网) |