微服务架构 - 简介

微服务是一种基于服务的应用程序开发方法。在这种方法中,大型应用程序将被划分为最小的独立服务单元。微服务是通过将整个应用程序划分为互连服务的集合来实现面向服务架构 (SOA) 的过程,其中每个服务仅满足一个业务需求。

走向微型的概念

在面向服务的架构中,整个软件包将被细分为小型的互连业务单元。每个小型业务单元将使用不同的协议相互通信,以向客户提供成功的业务。现在的问题是,微服务架构 (MSA) 与 SOA 有何不同?简而言之,SOA 是一种设计模式,而微服务是一种实现 SOA 的实现方法,或者我们可以说微服务是一种 SOA。

以下是我们在开发面向微服务的应用程序时需要牢记的一些规则。

  • 独立 − 每个微服务都应该可以独立部署。

  • 耦合 − 所有微服务都应该彼此松散耦合,以便一个微服务中的更改不会影响另一个微服务。

  • 业务目标 − 整个应用程序的每个服务单元都应该是最小的,并且能够实现一个特定的业务目标。

让我们以在线购物门户网站为例,深入了解微服务。现在,让我们将整个电子商务门户网站拆分成小的业务单元,例如用户管理、订单管理、签到、付款管理、交付管理等。一笔成功的订单需要在特定时间范围内完成所有这些模块。以下是与一个电子商务系统相关的不同业务单元的综合图像。

电子商务解决方案

每个业务模块都应该有自己的业务逻辑和利益相关者。它们会与其他第三方供应商软件进行通信以满足某些特定需求,也会相互通信。例如,订单管理可以与用户管理进行通信以获取用户信息。

现在,考虑到您正在运行一个包含前面提到的所有这些业务单元的在线购物门户网站,您确实需要一些由不同层(例如前端、后端、数据库等)组成的企业级应用程序。如果您的应用程序没有扩展并完全在一个 war 文件中开发,那么它将被称为典型的单片应用程序。根据 IBM 的说法,典型的单片应用程序应该在内部拥有以下模块结构,其中只有一个端点或应用程序负责处理所有用户请求。

Database

在上图中,您可以看到不同的模块,例如用于存储不同用户和业务数据的数据库。在前端,我们有不同的设备,我们通常在其中呈现用户或业务数据以供使用。在中间,我们有一个包,它可以是可部署的 EAR 或 WAR 文件,它接受来自用户端的请求,在资源的帮助下对其进行处理,并将其呈现给用户。一切都会很好,直到业务需要对上述示例进行任何更改。

考虑以下您必须根据业务需求更改应用程序的场景。

业务部门需要对"搜索"模块进行一些更改。然后,您需要更改整个搜索过程并重新部署您的应用程序。在这种情况下,您将重新部署其他部门,而无需进行任何更改。

Business Unit

现在,您的业务部门再次需要在"结帐"模块中进行一些更改以包含"钱包"选项。您现在必须更改"结帐"模块并将其重新部署到服务器中。请注意,您正在重新部署软件包的不同模块,而我们尚未对其进行任何更改。这就是面向服务架构的概念,更具体到微服务架构。我们可以这样开发我们的单体应用程序,即软件的每个模块都将作为一个独立的单元运行,能够独立处理单个业务任务。

考虑以下示例。

在上述架构中,我们没有创建任何具有紧凑端到端服务的 ear 文件。相反,我们通过将软件的不同部分公开为服务来划分它们。软件的任何部分都可以通过使用相应的服务轻松地相互通信。这就是微服务在现代 Web 应用程序中发挥重要作用的方式。

让我们在微服务中比较我们的购物车示例。我们可以将购物车分解为不同的模块,例如"搜索"、"过滤器"、"结帐"、"购物车"、"推荐"等。如果我们想构建购物车门户,那么我们必须以这样的方式构建上述模块,使它们可以相互连接,为您提供 24x7 良好的购物体验。

优点和缺点

以下是使用微服务而不是使用单片应用程序的一些优点。

优点

  • 体积小 − 微服务是 SOA 设计模式的实现。建议尽可能多地保留您的服务。基本上,一个服务不应该执行多个业务任务,因此它显然比任何其他单片应用程序规模小且易于维护。

  • 专注 − 如前所述,每个微服务都设计为仅交付一项业务任务。在设计微服务时,架构师应该关注服务的焦点,即其可交付成果。根据定义,一个微服务本质上应该是全栈的,并且应该致力于仅交付一种业务属性。

  • 自治 − 每个微服务都应该是整个应用程序的一个自治业务单元。因此,应用程序变得更加松散耦合,这有助于降低维护成本。

  • 技术异构性 − 微服务支持不同的技术在一个业务单元中相互通信,这有助于开发人员在正确的地方使用正确的技术。通过实施异构系统,可以获得最大的安全性、速度和可扩展的系统。

  • 弹性 − 弹性是隔离软件单元的属性。微服务在构建方法中遵循高水平的弹性,因此无论一个单元发生什么,都不会影响整个业务。弹性是实现高度可扩展和低耦合系统的另一个属性。

  • 易于部署 − 由于整个应用程序被细分为小块单元,因此每个组件本质上都应该是全栈的。与其他同类单片应用程序不同,它们都可以非常轻松地部署在任何环境中,并且时间复杂度较低。

以下是微服务架构的一些缺点。

缺点

  • 分布式系统 − 由于技术异构性,开发微服务的不同部分将使用不同的技术。需要大量熟练的专业人员来支持这种大型异构分布式软件。因此,分布式和异构性是使用微服务的头号缺点。

  • 成本 − 微服务成本高昂,因为您必须为不同的业务任务维护不同的服务器空间。

  • 企业就绪 − 随着技术日新月异,微服务架构可以被视为不同技术的集合。因此,让微服务应用企业准备好与传统软件开发模型进行比较是相当困难的。

SOA 上的微服务

下表列出了 SOA 和微服务的某些特性,突出了使用微服务而非 SOA 的重要性。

组件 SOA 微服务
设计模式 SOA 是一种计算机软件设计范例,其中软件组件以服务的形式暴露给外部世界以供使用。 微服务是 SOA 的一部分。它是 SOA 的一个专门实现。
依赖关系 业务部门相互依赖。 所有业务部门相互独立。
大小 软件大小比传统软件大。 软件大小小。
技术 技术堆栈小于微服务。 微服务本质上是异构的,因为使用精确的技术来执行特定任务。微服务可以看作是多种技术的集合。
自主和专注 SOA 应用程序旨在执行多项业务任务。 微服务应用程序旨在执行一项业务任务。
性质 本质上是单片的。 本质上是全栈的。
部署 部署非常耗时。 部署非常简单。因此,它将节省时间。
成本效益 更具成本效益。 成本效益较低。
可扩展性 与微服务相比更低。 完全可扩展。
示例 让我们考虑一个在线 CAB 预订应用程序。如果我们想使用 SOA 构建该应用程序,那么它的软件单元将是 −
  • GetPayments 和 DriverInformation 和 MappingDataAPI
  • AuthenticateUsers 和 DriversAPI
如果使用微服务架构构建相同的应用程序,则其 API 将是 −
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService