图片 1

复盘!2017 懂这些Linux运维技术面的运维人都加薪了!,2017linux

复盘!2017 懂这些Linux运维技术面的运维人都加薪了!,2017linux

http://www.infoq.com/cn/news/2017/05/2017-devops

图片 1

**

近些年来,软件领域发生了翻天覆地的变化。从操作系统、数据库等底层基础架构,到分布式系统、大数据、云计算、机器学习等基础领域,从单体应用、MVC、服务化,到微服务化等应用开发模式,从
IaaS、PaaS、CaaS 到
FaaS,运维技术(特别是大规模复杂分布式系统的运维)也变得越来越重要,它已成为
IT 类企业提升生产力的核心。

随着运维受到越来越多的重视,运维体系也逐步丰富,出现了 DevOps
等理念将研发、测试、运维等流程连接起来。而容器技术更是从底层重构了运维,连接了开发、测试、部署、运行和监控全流程,进一步推动了运维体系从工具化逐步往平台化、自动化和智能化方向迁移。

本文将对运维技术从底层到顶层做一个彻底的梳理和盘点。

微服务

近些年来,软件领域发生了翻天覆地的变化。从操作系统、数据库等底层基础架构,到分布式系统、大数据、云计算、机器学习等基础领域,从单体应用、MVC、服务化,到微服务化等应用开发模式,从IaaS、PaaS、CaaS到FaaS,运维技术(特别是大规模复杂分布式系统的运维)也变得越来越重要,它已成为IT类企业提升生产力的核心

我们正步入瞬息万变的信息时代,“快人一步”正成为企业的核心竞争力之一。如何让企业的业务创新和客户响应等快起来、敏捷起来?数字化重构是企业发展的必由之路,构建一个敏捷、高效的IT系统是最重要的基础。然而,当前业界主流的企业IT应用仍然以功能和流程作为核心来驱动的应用开发模式,不但成本高而且敏捷性很差,越来越难以为继,必须对IT应用开发的方法论和实现技术进行一场变革。

随着运维受到越来越多的重视,运维体系也逐步丰富,出现了DevOps等理念将研发、测试、运维等流程连接起来。而容器技术更是从底层重构了运维,连接了开发、测试、部署、运行和监控全流程,进一步推动了运维体系从工具化逐步往平台化、自动化和智能化方向迁移。本文将对运维技术从底层到顶层做一个彻底的梳理和盘点

传统企业IT应用开发模式面临挑战

微服务

分段式的研发模式,业务上线周期太长

微服务是近几年提出的概念,它通过将应用解耦成多个服务的方式来改善其模块化程度,使其更容易被理解、开发、测试和部署,更适用于小团队快速迭代式协作开发。同时,每个服务也能够采用不同的技术,便于持续进化。业界前沿互联网公司都构建了微服务框架(例如基于Spring
Boot/Spring
Cloud等开源项目)来应对其业务复杂性以及快速迭代过程中的效率问题。最近,微服务配置管理、容器化部署、自动化测试、微服务治理、微服务监控、安全、故障容忍等领域也受到越来越多的关注

目前,业界主流企业普遍采用基于瀑布式的研发模式,这种模式主要存在以下弊端:首先,业务需求是分段的,企业业务部门从企业运营的视角对IT提出需求,IT部门进行应用的开发;其次,IT应用开发是串行的,从需求分析、方案设计、编码测试到部署上线是按顺序开展的。一般一年只有1~2个版本上线,如果加上组织部门墙导致的开发流程断裂,上线周期会更长,一旦出现需求大量变更,周期就会严重拖延,甚至陷入交付的泥潭。

SRE

这与互联网应用快速试错、快速上线以及开发运维一体化的DevOps模式形成了强烈的对比,为此企业的IT应用开发纷纷开始借鉴互联网的DevOps模式。但在实践中也发现,仅仅理念的转变是远远不够的,更需要有一个良好的架构和先进的开发模式来支撑。

SRE(Site Reliability Engineering,
网站可靠性工程)是来自于谷歌的一个最佳实践,它用于服务的容量规划和实施、保障服务的可靠性和性能,更多的在软件基础架构层面构建自动化工具来取代人工操作,从而更好地应对其业务复杂多变的需求。

架构陈旧且高度耦合,牵一发而动全身,效率低下

DevOps & CI/CD

从企业应用的软件架构发展看,近十几年来,主要经历了从单体应用到SOA模式、再到微服务的发展过程。

DevOps逐步成为软件开发的主流,容器也已在过去两年中迅速成长为DevOps的核心,在持续集成、持续部署和持续发布等方面也越发受到重视。随着新的DevOps自动化工具不断涌现、容器及其相关生态的成熟(特别是容器编排工具及其对有状态服务的支持)、微服务的广泛应用,越来越多的相关工具将会集成在持续集成过程中,同时自动化持续测试也会变得更加流行,从而更有效地控制质量、保障安全、降低成本、控制风险、提升效率,更加高效的支持复杂的大型分布式应用。

在单体架构中,应用核心的商业逻辑以及由其定义的服务、对象和事件都封装在不同的模块中,这些模块和组件整体打包和部署,高度依赖应用的语言和框架。单体应用的好处是项目初期构建非常快,但随着时间的推移、代码的不断膨胀以及人员的更换,会导致研发效率急剧下降。团队需要维持上百万行代码中的数以百计、千计的依赖关系,哪怕是很小的几行需求或者一个Bug修复,都会导致意想不到的问题发生。

容器优化与实践

为了解决单体模式紧耦合、难以扩展的问题,出现了以服务为中心的SOA架构,将紧耦合的系统划分成面向业务的、粗粒度、松耦合和无状态的服务,服务之间通常通过企业服务总线(ESB)连接在一起。目前,绝大部分的企业IT架构是基于SOA模式的,但是从本质上讲这种模式还是中心化的,ESB变成整个系统的核心组件甚至成为瓶颈,不能把企业应用带到面向未来的云化方向。

过去几年间,以 Docker
为核心的容器技术在持续进化,以其构建、分发和部署的简易性成为 IT
基础架构中的关键技术。容器技术通过标准化运行环境的方式来连接了应用的研发、测试和运维。它简单、轻量,具备很强的可移植性,能更高效的利用资源,还能够有效的解决软件依赖问题,提高研发效率,降低研发成本,因此产业界也持续通过容器来优化其软件发布流程,对已有应用进行容器化。

微服务是从SOA演进而来,更倡导服务的细粒度、分布式、扩展性和治理能力。每个微服务定义为独立、自包含和无外部依赖的应用程序服务,单个微服务可以独自开发特性、修改bug和升级,服务间无耦合关系。

然而,容器技术本身也面临了不少挑战。未来,在容器标准化、容器安全、容器网络、容器存储特别是对数据库等有状态服务的支持等方面还存在很大的改进空间,容器的可管理性及易用性也需要进一步提升

越来越多的企业认识到,在云时代要开发出Cloud Native(云原生应用),真正走向敏捷,微服务架构一定是首选。但同时微服务在运行和治理时带来了更大的复杂性,比如大量微服务之间的调用链管理和依赖管理等,这些复杂性由什么技术和平台承载呢?因此,由PaaS屏蔽复杂的资源分布和部署差异,向应用层提供统一的服务、微服务管理和运行框架就成为一种必然。

容器编排与管理

PaaS技术选择碎片化,难以形成合力,形成新的烟囱系统

随着Docker等容器技术的广泛应用,容器编排和管理也受到了越来越多的关注,涌现出了诸于
Kubernetes、Apache Mesos、Docker Swarm Mode
等优秀的开源生态和解决方案。它们试图将目前以资源为中心的管理方式过渡到以应用为中心的管理方式,并且试图对应用的基础构成组件(例如配置、服务、负载均衡等)进行标准化,从而获得更好的可管理性。随着CaaS的发展,私有或公有的容器云也越来越多,越来越成熟,用户体验越来越好,从而显著降低迁移成本。

当意识到PaaS平台的重要性后,企业中不同的部门近年来在这个领域加快了试点建设,但由于各部门立场不同,所做出的技术选择往往不统一,缺少统一的规划和章法。

然而,在大规模的实践中,在灰度发布、资源调度、隔离性、运维监控、日志等方面仍有待进一步成熟和标准化,在跨数据中心的应用管理,混和云环境支持,跨云服务迁移,安全性等方面仍然面临着困难和挑战

比如,有些企业开发部门希望业务创新要快,减少对环境的等待时间,希望选择像CloudFundry这样的技术,以具备较好的开发流水线、多语言支持和多种服务接入能力;而运维部门则希望各种应用对IT资源和对部署的依赖应该尽量统一、尽量标准化,这样整体运维(特别是跨数据中心和全球化运维)效率最好,所以他们倾向于选择以开源架构技术为代表的Kuberentes、DockerCompose
/Swam等……由此,在构建新的开发平台解决业务敏捷的同时,又形成了新的烟囱系统,不同的开发架构和不同的部署模式形成了制约敏捷、高效的新瓶颈。