微服务、容器发展史与关系整理

最新推荐文章于 2023-03-01 14:48:53 发布

小艳子同学

最新推荐文章于 2023-03-01 14:48:53 发布

阅读量2.6k

点赞数 2

分类专栏：微服务与容器文章标签：微服务容器

微服务与容器专栏收录该内容

1 篇文章 0 订阅

订阅专栏

最近看到微服务的一篇论文，也同时在学习容器，对此查阅了很多好的文章，稍微整理一下。原文链接在最后。

微服务与容器发展史

最大的区别：微服务是一个架构，容器是一个工具

微服务发展史

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

单体架构

采用单体架构的应用数量最多，称为单体应用。可以将单体应用理解为主要的业务逻辑模块（我们编写的代码模块，不包括独立的中间件）运行在一个进程中的应用，最典型的是跑在Tomcat中的Java Web应用，不管这个应用在内部划分了多少模块，以及是否采用了MVC的分层架构，它都是一个单体应用，因为所有模块都运行在一个Tomcat容器中，位于一个进程里。在单体应用程序中，所有这些服务都在同一个应用程序层上运行。如图所示是目前应用最为广泛的基于Sping Framework的单体应用的架构图。

单体架构的好处：

技术门槛低
编程工作量少
开发简单快速
调试方便
环境容易搭
容易发布部署及升级
无论是开发还是运维，其总体成本都很低且见效快

随着市场的发展，用户数、数据量、业务模式的增长，传统模式存在一些缺点：

很显然，随着服务数量的增加，应用程序的规模将不断增长。这可能会让构建和维护应用程序代码库的开发人员不堪重负。
难以更新当前的技术栈，即使是在当前技术栈中修改一点内容也会是一场噩梦。
每一项变更都要求开发人员重建整个应用程序，十分浪费资源。
随着客户群的增加，我们将有更多的请求需要，这将需要更多的资源。因此，建立可扩展的产品时至关重要的。对于单体应用程序，我们只能在一个方向上进行伸缩，即垂直伸缩，而不是水平伸缩。这意味着我们可以通过添加更多硬件资源（如内存和 CPU）在单台计算机上扩展应用程序，但横向扩展（跨多台计算机）仍然是一项挑战。

SOA架构

面对上述的单体应用存在如此多的问题，怎么解决呢？自然而然能够想到：拆。可以将一个庞大的单体应用拆分成多个服务模块，然后再将这些服务模块按照业务逻辑串起来，对外提供应用服务。这就是SOA（面向服务架构）的思路。

SOA：即面向服务的架构（SOA），是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。用于构建大型的企业应用程序，这些应用程序通常要求集成多种服务，而每种服务使用不同的平台和编程语言来构建，并通过通用的通信机制进行交互。以下是面向服务架构（SOA）的简单图示：

关键点

SOA 是大型软件产品（如企业应用程序）的首选。
SOA 侧重于将多个服务集成到单个应用程序中，而不是强调模块化应用程序。
在 SOA 中，用于服务间交互的通用通信机制被称为企业服务总线（Enterprise Service Bus，ESB）。
基于 SOA 的应用程序本质是单体。也就是说，单个应用程序层包含了用户界面或表示层、业务逻辑或应用程序层，以及数据库层，这些全部都集成到一个平台中。

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

微服务架构

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

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

微服务架构可以被认为是对 SOA 的特殊化，也是一种可以克服单体架构缺陷的替代模式。在微服务架构中，我们专注于将应用程序模块化，将其分解成较小的独立服务，这些服务可独立于其他服务或整个应用程序本身而构建、部署、伸缩和维护。这些独立服务被称为微服务，因此这种架构被称为微服务架构。

每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

关键点

微服务架构和 SOA 虽然不一样，但它们确实存在一些相似之处。都专注于构建具有松散耦合的服务。这些服务具有明确的界限，并且每个服务都具有独立的功能集。
不同之处在于，SOA 可能意味着其他很多东西。例如，SOA 适用于单体架构，重点是将系统集成在一个应用程序中，并确保代码的可复用性。但对微服务架构来说并不是这样的，微服务架构的重点是通过构建独立服务和确保产品的可伸缩性来模块化应用程序。

微服务的独立能力或独立性带来了以下好处：

引入关注点分离的理念，在软件应用程序开发中实现敏捷，不管是在简单的还是复杂的领域。
将开发人员分成小团队来降低复杂性，每个小团队负责构建和维护一个或多个服务。
允许部署分块，而不是每次发生变更都要重新构建整个应用程序，以此来降低风险。
增量更新或升级一个或多个服务的技术栈，而不是在一个时间点更新整个应用程序，以此降低维护难度。
可以使用任意的编程语言来构建服务，除此之外，还可以为每个给定服务维护单独的数据模型。
可以构建全自动的部署机制，确保个体服务的部署、服务管理和自动伸缩。

容器的发展史

第一张图显示的是一台物理机器或一台硬件服务器。通常，我们在构建应用程序时使用的是宿主操作系统提供的资源，在部署应用程序时也使用了相同的模式。但如果你想扩展应用程序该怎么办呢？在某些时候，你可能需要另一台硬件服务器。而随着数量不断增加，成本和其他资源（如硬件和能源消耗）也会随之增加。

此外，你可能会想，是否有必要在任何时候都使用所有的硬件资源和操作系统？当然不是。既然这样，那么为什么还需要这么庞大的基础设施呢？

这个问题促成了硬件虚拟化的发展，于是虚拟机（VM）出现了，我们通过虚拟机来优化 IT 基础设施。如你在第二张图中看到的，虚拟机具有自己的客户操作系统，运行在单个物理机或宿主操作系统中。我们因此能够运行多个应用程序，而无需安装大量物理机。宿主操作系统可以确保在不同虚拟机之间进行系统性的资源分配和负载均衡。

虚拟机降低了软件维护的难度和成本，不过仍然可以进一步优化。例如，并非所有的应用程序在客户操作系统环境中都会按预期运行。此外，即使是运行简单的进程，客户操作系统也需要大量资源。

这些问题促成了下一个创新：容器化。与特定于操作系统的虚拟机不同，容器特定于应用程序，因为更加轻量级。此外，虚拟机可以运行多个进程，而容器作为单个进程运行。于是：

我们可以在物理机上运行多个容器，或者甚至可以考虑在单个虚拟机上运行容器。无论是哪种情况，它都可以解决应用程序相关的问题。
容器化与虚拟化之间并不是竞争关系，而是一种互补，用以进一步优化 IT 软件基础设施。

三者之间的关系：

Dockers

Docker 是一个开源应用容器（当然目前也分为CE和EE版本，不完全开源化，也存在收费版本），让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

Docker 作为容器工具可以把业务逻辑容器、数据库容器、储存容器、队列容器等拆分成若干个标准化容器，然后像搭积木一样组合起来，让彼此通信，从而形成微服务。

因此微服务很适合用 Docker 容器实现，每个容器承载一个服务。一台计算机同时运行多个容器，从而就能很轻松地模拟出复杂的微服务架构。

借助 Docker，可以使应用程序独立于主机环境。因为采用了微服务架构，所以现在可以将每个服务封装到 Docker 容器中。Docker 容器是轻量级的，并且资源是隔离的，通过它可以构建、维护、发布和部署应用程序。

优点：

Docker 是一款非常流行的软件，有强大的社区支持，并专门为微服务而构建。
与虚拟机相比，它是轻量级的，在成本和资源消耗方面颇具优势。
它为开发和生产环境提供了一致性，非常适合用于构建云原生应用程序。
它为持续集成和部署提供了便利。
Docker 可与 AWS、Microsoft Azure、Ansible、Kubernetes、Istio 这些流行的工具和服务集成。

基于K8s的容器平台

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

感谢这些作者，原文链接：

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

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

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

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

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

答案是大大增加了开发工作量并带来了固有的复杂性。比如，开发者需要掌握某种RPC通信技术，并且在客户端的逻辑中增加远程服务的调用代码，在某些情况下，他们必须通过写代码来处理RPC速度过慢或者调用失败等复杂问题。

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

因此企业在判断自己的应用是否需要微服务化的时候，需要综合考虑应用的重要性、改造的代价与收益、技术风险等，综合考虑是否有必要将某个单体应用或者一般的分布式架构应用改造成微服务架构的应用。毕竟，改造是有成本的，而且改造完毕之后，也无法保证能够解决所有问题。

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

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

作者：嘉为科技
原文链接：https://www.jianshu.com/p/23ffc7f1f466
来源：简书