文章

解读微服务、DevOps、容器和K8S

2019-07-05e-works 熊东旭

15128阅
传统软件应用开发和部署的弊端非常明显:开发周期长、系统紧耦合、扩展性差等,无法根据应用需求的变化实现快速的更新和迭代。微服务架构的出现能很好解决这些问题。

    随着移动互联网的发展,传统PC独大的局面已经被打破,为适应多元化的平台应用需求,企业往往需要为同一个应用开发多个版本,以适应不同系统的部署需求。同时随着云计算的发展,软件部署方式开始变得多样化,包括本地部署、私有云、公有云等多种部署形式,多元化系统平台和多样化的部署方式让传统的软件应用开发不堪重负,不但成本越来越高,周期越来越长,而且平台架构之间的不兼容导致应用迁移困难。

    另一方面,在工业领域为支撑越来越复杂的工业应用场景,工业APP正在成为新的开发需求。这些工业级应用会部署在服务器、智能终端、嵌入系统或者是边缘计算系统中,大多是分散和异构的微系统环境,代码开发简单但功能专业,传统的软件开发方式无法满足这种小而专的应用开发和迭代需求,而且大部分以云应用为主。因此,企业需要找到一种新开发方式,既能满足碎片化的云应用开发需求,还能及时响应客户需求实现应用的快速开发、部署、更新和迭代。

微服务,将应用由大变小

    传统软件开发是一个庞大的工程。从评估需求、编程语言,框架搭建到开发、测试和部署,需要的人力和资源非常多,在开发完成后,应用会被打包在一个WAR包里面部署,特点是系统紧耦合、整体部署、局部修改,整体更新。但这种应用存在两个问题:一是横向扩展时需要整体扩展,资源分配最大化,不能按需扩展和分配资源;二是如果一个业务模块出现问题,就会是全局性灾难,因为所有业务跑在同一个实例中,发生异常时不具备故障隔离性,会影响整个业务运转,整个入口都会存在问题。

    传统应用开发和部署的弊端非常明显:开发周期长、系统紧耦合、扩展性差以及不具备故障隔离性,无法根据应用需求的变化实现快速的更新和迭代。

    微服务架构的出现能很好解决这些问题。微服务架构通过将大应用拆分为多个业务应用组件进行开发,这些小应用本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。

    微服务的优势非常明显:首先,传统应用出问题可能要先把整个包先停掉,然后再去修改,而微服务只需逐步修改和更新即可;其次,传统应用出现任何故障会影响整体的运行,但微服务可在不影响整体功能前提下对故障进行隔离,业务可持续性都非常高;第三,微服务可按需分配资源,资源利用率非常高。

    由于微服务数量众多,每个微服务都独立的开发、测试、编译、打包流程,可以采用不同的语言和框架,在应用实施过程中还需要进行频繁的迭代和更新。如果依靠人来完成显然是不现实的。这时候就需要一种方法把微服务的开发过程管理起来,这就是DevOps。

DevOps,微服务开发流程与方法

    在讲DevOps之前,为了避免枯燥抽象的概念讨论,我们可以讨论一下水稻的种植收割流程。作为一个地地道道的武汉农村人,从小就帮着大人参与水稻的栽种和收割。从播种、插秧、施肥、除虫、收割、晾晒到出米,这每一个阶段都可以看成是一个微服务,每一个微服务都包括了不同的工作任务。以往农村人力充足,都依靠人来完成所有的过程,但农村人口普遍偏老龄化,所以很多工作都采用机械式收割,以自动化和流水线的方式完成栽种和收割的整个流程。这就是DevOps,一种帮助微服务开发和实施的方法。

    在微服务开发和实施过程中必然会涉及到需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等工具链,就像工业产品设计过程中的PLM系统,管理着产品开发过程的所有版本和数据。可以把DevOps看成微服务开发的流水作业线,为微服务的开发、管理和实施提供全套的工具链,保证微服务能快速的开发、测试、实施、更新和迭代。

容器,打包和运行微服务

    微服务的具备独立功能的组件和服务,能够独立部署。但是微服务运行时需要平台环境的,这就像应用需要部署到系统上运行一样。所以微服务和容器是需要绑定到一起才能提供对外服务功能的。但是为什么是要在容器中打包和运行?为什么不是虚拟机?

    关于虚拟机和容器的比较已经有很多文章。简单来说,微服务很小,而虚拟机很大。虚拟机的运行需要先启动来宾操作系统(Guest OS),这就要耗费很大的系统资源,而且虚拟机资源的调度都是以CPU核心为单位,对微服务这种细粒度的应用,虚拟机的粒度还太粗,通俗点说就是“大马拉小车”,资源浪费严重。

    容器就不同,可以直接运行在物理机操作系统上,有着比虚拟机更少的抽象层,减少了加载操作系统内核的时间和资源的消耗,因此,在CPU、内存等资源利用率上更有优势。因此容器启动时间是秒级,而虚拟机都是分钟级,虚拟机都是GB的空间占用,而容器都是MB的空间占用,单机就能支持上千个容器,远多于虚拟机的几十个。

    简单来说,容器通过将微服务及其应用环境打包,为微服务的运行提供了一个与底层完全隔离的运行环境,无论是放到哪个平台环境都能正常运行。到了这一步,我们就只需要对大量的容器进行管理。

K8S,容器编排和调度平台

    微服务是和容器绑定在一起的,微服务化之后的应用一般而言是需要运行在容器上的。而一个具有一定规模的单体应用,微服务化之后,可能对应成百上千个微服务,这些微服务的资源调度、更新发布、运维管理、销毁回收、自动扩缩容等等综合起来会变成一个很庞大的工作量,如何应对呢?

    答案是使用K8S容器编排和调度平台。这里面涉及到资源的管理,例如计算资源、网络资源、存储资源、镜像资源;同时还涉及到微服务应用层面的管理,例如应用的创建、应用的部署管理、应用的弹性伸缩管理、应用的日志管理和监控管理;另外,还包括与其它流程或者工具链的打通,比如与DevOps流程的集成和打通,与企业现有日志管理平台的集成与打通,与企业监控和告警平台的集成与打通,与企业备份系统的集成和打通,以及与企业的大数据、数据挖掘等平台的集成与打通。

责任编辑:程玥
本文为e-works原创投稿文章,未经e-works书面许可,任何人不得复制、转载、摘编等任何方式进行使用。如已是e-works授权合作伙伴,应在授权范围内使用。e-works内容合作伙伴申请热线:editor@e-works.net.cn tel:027-87592219/20/21。
读者评论 (0)
请您登录/注册后再评论