微服务架构 - 简介


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

走向微观的概念

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

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

  • 独立- 每个微服务应该是独立部署的。

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

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

让我们考虑一个在线购物门户的例子来深入了解微服务。现在,我们把整个电商门户分解为用户管理、订单管理、签到、支付管理、配送管理等小业务单元。一个成功的订单需要在特定的时间内走完所有这些模块。框架。以下是与一个电子商务系统关联的不同业务部门的综合图像。

电子商务解决方案

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

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

数据库

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

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

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

事业部

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

考虑以下示例。

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

让我们比较一下微服务中的购物车示例。我们可以将购物车分解为不同的模块,例如“搜索”、“过滤”、“结账”、“购物车”、“推荐”等。如果我们想构建一个购物车门户,那么我们必须构建上述模块之间可以相互连接,为您提供 24x7 良好的购物体验。

优点缺点

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

优点

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

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

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

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

  • 弹性- 弹性是隔离软件单元的属性。微服务在构建方法中遵循高水平的弹性,因此每当一个单元发生故障时,它不会影响整个业务。弹性是实现高度可扩展且耦合度较低的系统的另一个属性。

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

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

缺点

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

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

  • 企业准备就绪- 微服务架构可以被视为不同技术的组合,因为技术正在日益发展。因此,要让微服务应用企业能够与传统的软件开发模式进行比较是相当困难的。

基于 SOA 的微服务

下表列出了 SOA 和微服务的某些特性,凸显了使用微服务相对于 SOA 的重要性。

成分 面向服务架构 微服务
设计模式 SOA 是计算机软件的一种设计范例,其中软件组件以服务的形式暴露给外部世界以供使用。 微服务是SOA的一部分。它是SOA 的专门实现。
依赖性 业务部门相互依赖。 所有业务单元都是相互独立的。
尺寸 软件体积比传统软件大。 软件体积小。
技术 技术栈比微服务少。 微服务本质上是异构的,因为使用精确的技术来执行特定的任务。微服务可以被视为多种技术的集合。
自主和专注 SOA 应用程序旨在执行多种业务任务。 微服务应用程序旨在执行单个业务任务。
自然 本质上是整体的。 本质上是全栈。
部署 部署非常耗时。 部署非常简单。因此,耗时会更少。
成本效益 更具成本效益。 性价比较低。
可扩展性 与微服务相比更少。 完全缩放。
例子 让我们考虑一个在线 CAB 预订应用程序。如果我们想使用 SOA 构建该应用程序,那么它的软件单元将是 -
  • GetPayments 和 DriverInformation 和 MappingDataAPI
  • 验证用户和驱动程序API
如果使用微服务架构构建相同的应用程序,那么它的 API 将是 -
  • 提交付款服务
  • 获取驾驶员信息服务
  • 获取映射数据服务
  • 验证用户服务
  • 验证驱动程序服务