浅谈微服务架构、容器技术与K8S

关注嘉为科技，获取运维新知

 

企业应用系统：从单体应用走向微服务架构；从裸金属走向容器。

 

若是在诸多热门云计算技术诸如容器、微服务、DevOps、OpenStack等之中，找出一个最火的方向，那么可能非微服务莫属。尽管话题煊赫一时，但对传统行业来讲，微服务落地和方法论目前处于起步阶段。

 

单体架构

对于传统企业来讲，数字化转型的需求日益迫切，其IT架构面临着互联网融合业务中海量用户和快速迭代的巨大挑战。当前，咱们所开发的应用，无论是运行在局域网中仍是部署在云端的，都采用了单体架构、分布式架构或微服务架构其中的一种。

 

其中，采用单体架构的应用数量最多，咱们将这种应用简称为单体应用。咱们能够将单体应用理解为主要的业务逻辑模块（咱们编写的代码模块，不包括独立的中间件）运行在一个进程中的应用，最典型的是跑在Tomcat中的Java Web应用，无论这个应用在内部划分了多少模块，以及是否采用了MVC的分层架构，它都是一个单体应用，由于全部模块都运行在一个Tomcat容器中，位于一个进程里，如图所示是目前应用最为普遍的基于Sping Framework的单体应用的架构图。

 

 

单机应用有哪些好处和劣势呢？

 

好处

• 技术门槛低

• 编程工做量少

• 开发简单快速

• 调试方便

• 环境容易搭建

• 容易发布部署及升级

• 不管是开发仍是运维，其整体成本都很低且见效快

   

劣势

• 单体应用的系统比较膨胀与臃肿，致使进行可持续开发和运维很困难。

  例如：一开始，咱们的系统只有10个模块，随着业务的扩展，一年后变成了30个模块，两年后达到80个模块。项目的工程代码因为过于庞大，不少代码被不断修改，整个系统的源码已经很难被理解和掌握了。

   

• 单体应用在基因上的缺陷致使它很难经过水平扩展、多机部署的方式来提高系统的吞吐量，通常只能经过纵向不断堆单个机器或者群集的性能配置来提高。

  这样的结果就是系统难以承载迅速增加的互联网用户引起的请求，也就是说，在用户规模增长后，即便不断升级服务器硬件并进行各类性能调优，系统也会动不动就“挂了”。

   

• 单体应用的多个模块在代码级别没有明确的接口与界限划分，在修改已有代码时，常常牵一发而动全身。在传统单体架构下，应用若是频繁升级更新，开发团队很是痛苦。企业的业务应用通过多年IT建设，系统很是庞大，要改动其中任何一小部分，都须要从新部署整个应用，敏捷开发和快速交付无从谈起。

   

• 随着单体应用模块不断增长和代码不断被修改，面对一个庞然大物的单体应用，新人很难应对，即难以继续用老技术、老框架去维持这个旧系统，也很难用新技术、新框架来全面升级这个老旧的单体应用。

 

• 待应用自己已经难以经过修修补补知足当前业务模式的需求以后，这种老旧的单体应用即被全面抛弃，在推翻和转型过程当中的阵痛仍然在所不免。

 

分布式架构、SOA架构

面对上述的单体应用存在的如此多的问题，怎么解决呢？咱们天然而然可以想到：拆。

 

没错，确实是这样。咱们能够将一个庞大的单体应用拆分红多个服务模块，而后再将这些服务模块按照业务逻辑串起来，对外提供应用服务。这就是SOA（面向服务架构）的思路。

 

SOA：即面向服务的架构（SOA），是集成多个较大组件（通常是应用）的一种机制，它们将总体构成一个彼此协做的套件。通常来讲，每一个组件会从始至终执行一块完整的业务逻辑，一般包括完成总体大action所需的各类具体任务与功能。组件通常都是松耦合的，但这并不是SOA架构模式的要求。

 

下图是一个典型的SOA架构的应用。

 

然而SOA架构也存在一些问题：好比单个拆分出来的模块可能依然比较大，包含多个服务，没法实现更小的服务单元的敏捷交付；而且服务与服务之间耦合性依然比较强；再好比，ESB总线很容易成为整个系统的性能瓶颈等等。

 

微服务架构

怎么办呢？继续拆，而且在拆的同时改变了所使用的底层承载的技术以及服务之间的关联方式。

 

这就是微服务架构+容器技术。

 

容器和微服务相辅相成，两大技术成熟的时间点很是契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境，微服务应用只有在容器环境下才能保障运维效率的提高。同时，微服务应用架构对外在组件的管理会变得困难，须要用容器平台去管理中间件，才能发挥出更大价值。

 

在分布式技术发展早期，出现过一个基于RPC技术的“伟大的分布式平台”，这个平台的梦想是实现全部语言、全部平台、全部厂商的各类IT系统的分布式互联互通，这就是CORBA，惋惜这个由IBM、Sun Microsystems、苹果、微软等IT公司联手发起的伟大创举最终失败。

 

以后，一些CORBA技术专家汇集在一块儿，继续沿着CORBA的梦想前进，最终打造出一款优秀的分布式架构基础平台——ZeroC ICE。ICE基于高性能的RPC通讯技术，跨语言，跨平台， 拥有杰出的性能。凭借强大的技术实力，ZeroC公司屹立至今，虽然当年的IT霸主SUN早已不在，但ZeroC公司依然由于拥有不少关键领域的大客户而健康成长。同时，ZeroC公司于2005年发布的ICE 3.0首次实现了IceGrid。在如今看来，IceGrid具有了微服务架构平台的全部关键特性，可被认为是第一个公开发行的、支持多语言的、功能完备的微服务架构基础平台，如图所示是IceGrid的完整示意图。

 

 

从图能够看到，IceGrid具有微服务架构的核心特性。

• 服务编排：IceGrid采用XML方式定义服务及服务的部署拓扑，经过命令行工具一键发布。

• 服务托管：IceGrid中的“微服务”运行于IceBox这个容器中， 由容器托管整个服务的生命周期，包括启动服务、中止服务、升级服务等过程。

• 服务注册：Ice Registry实现服务注册功能，支持静态配置与动态注册两种机制，而且能够配置一主一从的集群，避免单点故障。

• 服务路由与负载均衡：采用客户端负载均衡机制，在客户端SDK里内嵌实现，无须编程，具备基于主机负载、轮询等多种负载均衡方式。

• 平台运维：基于命令行与Java GUI工具，经常使用的运维命令都已经内置实现，用户也能够根据ICE提供的管理API来实现定制化的Web运维工具。

 

整体上，微服务架构平台的核心组成就是上述组件，下图所示为典型的微服务架构平台的结构示意图。

 

 

在IceGrid以后，比较有影响力的开源微服务架构框架有Dubbo与 Spring Cloud，二者都是Java语言体系内的微服务框架，并不支持其余语言。与IceGrid相比，其完备性还达不到平台（Platform）的高度，目前只能被称为框架（Framework）。下表给出了Dubbo 与Spring Cloud的主要功能对比。

 

 

Spring Cloud相对而言更加全面，开源更有保障，同时开创性地实现了微服务架构框架中诸如断路器、流量仪表板、服务网关等特性，同时提供了在分布式开发中所需的不少基础组件（API），例如配置管理、全局锁、分布式会话和集群状态管理等。Spring Cloud的核心是原来在 Netflix 公司内部普遍使用、通过实践考验、很是成熟的微服务框架——Netflix OSS，因此，Spring Cloud一度吸引了不少人的眼球。

 

基于K8S的容器平台

在Spring Cloud以后成功的微服务架构基本都与容器技术挂钩了，其中最成功、影响也最大的当属Kubernetes平台了，与之类似的还有Docker公司推出的Docker Swarm（在2017年年末，Docker Swarm 也支持Kubernetes了）。

 

 

对比Kubernetes与IceGrid，咱们会发现二者有不少类似性。

• 每台主机上的Kubelet Daemon进程至关于Ice Node守护进程。

• Kubernetes API Server进程至关于Ice Registry。

• 每一个运行的容器至关于一个IceBox进程。

• Kubernetes中的微服务Service至关于IceGrid中的Service。

• Kubernetes的YAML资源定义文件至关于ICE中的grid.xml。

• kubectrl客户端命令行工具至关于Icegridadmin工具。

 

Kubernetes与IceGrid在微服务架构基础设施方面有如下两个显著区别。

• Kubernetes没有提供一个用于服务调用的“RPC框架”，这样的好处是任何语言和网络协议（只要是TCP/UDP之上的协议）均可以在Kubernetes微服务架构平台上建模与运行，缺点是缺失的这一层须要应用本身去解决。

• Kubernetes里的服务路由与服务负载均衡是经过“代理”来实现的，便是由位于每一个Node节点上的kube-proxy来完成的，而非客户端的负载均衡机制。

 

那么，在采用微服务架构模式后都有哪些好处呢？以下所述。

• 经过把巨大的单体应用分解为多个微服务组件的方式解决了复杂度的问题。在功能不变的状况下，整个应用被分解为多个基于接口驱动的可独立设计、施工的子工程，这样一来，每一个微服务工程的规模变小、功能内聚，技术相对单一化，更容易去理解和并行开发。

   

• 微服务架构使得每一个服务均可以由专门的开发团队并行独立设计、开发、升级及运维，开发者能够自由选择开发技术甚至开发语言，以更好地实现目标。最为关键的是，这种自由意味着开发者不须要被迫使用该项目在一开始时采用的过期技术（好比3年前的旧框架），能够选择如今主流或流行的新技术。甚至，由于服务的功能相对简单、单一化，代码量并不复杂，也不难准确理解服务的业务逻辑，即便用如今的技术重写之前老旧的代码也不是很困难的事情。

   

• 微服务架构模式能够作到每一个微服务独立部署，这种改变能够加快部署。开发者再也不须要协调其余服务部署对本服务的影响，UI团队能够采用A/B测试，快速部署新版本以加速测试。微服务架构模式使得持续化集成与发布部署成为可能，所以DevOps的实施在更多 的时候须要首先将系统微服务化。

 

咱们知道，任何技术都有两面性，即优势与缺点并存，那么，微服务架构的最大缺点是什么呢？

 

答案是大大增长了开发工做量并带来了固有的复杂性。好比，开发者须要掌握某种RPC通讯技术，而且在

客户端的逻辑中增长远程服务的调用代码，在某些状况下，他们必须经过写代码来处理RPC速度过慢或者调用失败等复杂问题。

 

相对于在单体应用中仅需在编程层面进行方法调用就能够访问其余服务，微服务架构中的服务调用方式则显得更加复杂和难以捉摸。所以，一个单体应用或者简单的分布式系统要想完全微服务化，其代价仍是很大的。

 

所以企业在判断本身的应用是否须要微服务化的时候，须要综合考虑应用的重要性、改造的代价与收益、技术风险等，综合考虑是否有必要将某个单体应用或者通常的分布式架构应用改形成微服务架构的应用。毕竟，改造是有成本的，并且改造完毕以后，也没法保证可以解决全部问题。

 

咱们知道，在当下而言，微服务基本上是和容器绑定在一块儿的，微服务化以后的应用通常而言是须要运行在容器上的。而一个具备必定规模的单体应用，微服务化以后，可能对应成百上千个微服务，这些微服务的资源调度、更新发布、运维管理、销毁回收、自动扩缩容等等综合起来会变成一个很庞大的工做量，如何应对呢？

 

答案是使用K8S为核心的构建的容器平台，来进行总体的用来支撑微服务化应用的容器的管理。这里面涉及到资源的管理，例如计算资源、网络资源、存储资源、镜像资源；同时还涉及到微服务应用层面的管理，例如应用的建立、应用的部署管理、应用的弹性伸缩管理、应用的日志管理和监控管理；另外，还包括与其余流程或者工具链的打通，好比与DevOps流程的集成和打通，与企业现有日志管理平台的集成与打通，与企业监控和告警平台的集成与打通，与企业备份系统的集成和打通，以及与企业的大数据、数据挖掘等平台的集成与打通。

 

事实上，在腾讯蓝鲸研发运营一体化平台中，已经集成了基于K8S深度定制的容器管理平台，而且该平台与蓝鲸总体PaaS平台的其余功能模块，好比CMDB、做业平台、编排引擎、大数据平台、管控平台、DevOps工具链等原生集成，构建了针对容器和微服务应用生命周期管理的完整工具箱，助力企业实现容器和微服务应用的全方位管理。

 

在后面的文章中，将与各位讨论，基于K8S的容器平台是可以实现哪些方面的管理，以及是如何实现的。

 

蓝鲸平台试用Tips

蓝鲸社区版

若是您想先简单了解蓝鲸研发运营一体化平台，或者企业规模较小但想用更为先进的自动化运维管理方式进行IT运维管理，推荐您先试用蓝鲸社区版。

蓝鲸社区版已经开源，您能够登陆蓝鲸智云官网免费下载。网址：

http://bk.tencent.com/download/

 

蓝鲸企业版

固然，蓝鲸企业版拥有更为丰富的功能，更适合企业级客户使用。如您有须要试用或者测试，联系嘉为吧！​​​​