SOA“简史”

在 2000 年初,我们目睹了面向服务架构(Service Oriented Architecture,SOA)的崛起,这是一种非常流行的软件架构设计范式。简而言之,SOA 是一种软件架构模式,用于构建大型的企业应用程序,这些应用程序通常要求集成多种服务,而每种服务使用不同的平台和编程语言来构建,并通过通用的通信机制进行交互。

以下是面向服务架构(SOA)的简单图示:

微服务与容器技术发展史_java

关键点

  1. SOA 是大型软件产品(如企业应用程序)的首选。

  2. SOA 侧重于将多个服务集成到单个应用程序中,而不是强调模块化应用程序。

  3. 在 SOA 中,用于服务间交互的通用通信机制被称为企业服务总线(Enterprise Service Bus,ESB)。

  4. 基于 SOA 的应用程序本质是单体。也就是说,单个应用程序层包含了用户界面或表示层、业务逻辑或应用程序层,以及数据库层,这些全部都集成到一个平台中。

关于“单体架构”

让我们以网店为例。我们知道,很多电商网站都可以通过多种设备访问,所以这些网站通常都为笔记本电脑和移动设备提供了不同的用户界面。

我们也知道,多个操作或服务彼此依赖,以确保应用程序的正常运行。其中一些服务负责创建账号、显示产品目录、建立和验证购物车、生成账单、确认订单、完成支付等。

在单体应用程序中,所有这些服务都在同一个应用程序层上运行,因此这个电子商务网站的软件架构如下所示:

缺点

  1. 很显然,随着服务数量的增加,应用程序的规模将不断增长。这可能会让构建和维护应用程序代码库的开发人员不堪重负。

  2. 难以更新当前的技术栈,即使是在当前技术栈中修改一点内容也会是一场噩梦。

  3. 每一项变更都要求开发人员重建整个应用程序,十分浪费资源。

  4. 随着客户群的增加,我们将有更多的请求需要,这将需要更多的资源。因此,建立可扩展的产品时至关重要的。对于单体应用程序,我们只能在一个方向上进行伸缩,即垂直伸缩,而不是水平伸缩。这意味着我们可以通过添加更多硬件资源(如内存和 CPU)在单台计算机上扩展应用程序,但横向扩展(跨多台计算机)仍然是一项挑战。

救星“微服务”来了!

微服务架构可以被认为是对 SOA 的特殊化,也是一种可以克服单体架构缺陷的替代模式。

在微服务架构中,我们专注于将应用程序模块化,将其分解成较小的独立服务,这些服务可独立于其他服务或整个应用程序本身而构建、部署、伸缩和维护。这些独立服务被称为微服务,因此这种架构被称为微服务架构。

关键点

  1. 微服务架构和 SOA 虽然不一样,但它们确实存在一些相似之处。微服务架构被称为 SOA 的变体,甚至是 SOA 的一种特殊化。换句话说,SOA 可以被认为是微服务架构的超集。

  2. 人们之所以能够在这些架构之间找到相似性,主要是因为它们都专注于构建具有松散耦合的服务。这些服务具有明确的界限,并且每个服务都具有独立的功能集。

  3. 不同之处在于,SOA 可能意味着其他很多东西。例如,SOA 适用于单体架构,重点是将系统集成在一个应用程序中,并确保代码的可复用性。但对微服务架构来说并不是这样的,微服务架构的重点是通过构建独立服务和确保产品的可伸缩性来模块化应用程序。

优点

  1. 引入关注点分离的理念,在软件应用程序开发中实现敏捷,不管是在简单的还是复杂的领域。

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

  • 将开发人员分成小团队来降低复杂性,每个小团队负责构建和维护一个或多个服务。

  • 允许部署分块,而不是每次发生变更都要重新构建整个应用程序,以此来降低风险。

  • 增量更新或升级一个或多个服务的技术栈,而不是在一个时间点更新整个应用程序,以此降低维护难度。

  • 可以使用任意的编程语言来构建服务,除此之外,还可以为每个给定服务维护单独的数据模型。

可以构建全自动的部署机制,确保个体服务的部署、服务管理和自动伸缩。

技术的演变

除了软件架构模式的发展之外,我们还看到 Docker 和 Kubernetes 等新技术的出现,用于支持我们的软件基础设施,实现对可伸缩产品和服务的高效管理。我们已经从硬件虚拟化发展到容器化。

或许你会想,这意味着什么?

让我们借助下图来理解 IT 基础设施领域的发展:

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

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

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

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

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

  1. 我们可以在物理机上运行多个容器,或者甚至可以考虑在单个虚拟机上运行容器。无论是哪种情况,它都可以解决应用程序相关的问题。

  2. 容器化与虚拟化之间并不是竞争关系,而是一种互补,用以进一步优化 IT 软件基础设施。

Docker

我们已经了解了 IT 软件基础设施的演变,接下来可能想知道如何实现之前讨论过的微服务架构和容器化?答案是:Docker。

Docker 是全球领先的软件容器化平台,它将微服务封装进我们所说的 Docker 容器,然后进行独立的维护和部署。每个容器都将负责一个特定的业务功能。

为了更深入了解 Docker,让我们以前面讨论过的电子商务网站为例。我们知道它拥有多项业务和服务,例如创建账号、显示产品目录、建立和验证购物车等。在微服务架构中,所有这些都可以视为微服务并封装在 Docker 容器中。但是,为什么要这样做?

其中一个原因是为了确保开发和生产环境之间的一致性。例如,假设有三位开发人员正在开发此应用程序,他们每个人都有自己的开发环境。其中一个开发人员可能在他的机器上运行 Windows 操作系统,而第二个开发人员可能运行 Mac OS,第三个开发人员会更喜欢基于 Linux 的操作系统。他们每个人都需要花费数小时的时间将应用程序安装到各自的开发环境中,并且需要做额外的工作将它们部署到云端。这一过程并不那么顺畅,在将这些应用程序部署到云基础设施上时,他们之间总是会发生摩擦。

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

优点

  1. Docker 是一款非常流行的软件,有强大的社区支持,并专门为微服务而构建。

  2. 与虚拟机相比,它是轻量级的,在成本和资源消耗方面颇具优势。

  3. 它为开发和生产环境提供了一致性,非常适合用于构建云原生应用程序。

  4. 它为持续集成和部署提供了便利。

  5. Docker 可与 AWS、Microsoft Azure、Ansible、Kubernetes、Istio 这些流行的工具和服务集成。