微服务架构 - 简介



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

微型化的概念

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

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

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

  • 耦合性 - 所有微服务都应该松散耦合,这样在一个微服务中的更改不会影响其他微服务。

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

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

Electronic Commerce Solutions

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

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

Database

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

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

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

Business Unit

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

考虑以下示例。

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

让我们按照微服务的思路比较我们的购物车示例。我们可以将我们的购物车分解成不同的模块,例如“搜索”、“筛选”、“结账”、“购物车”、“推荐”等。如果我们想要构建一个购物车门户网站,那么我们必须以这样一种方式构建上述模块,使它们能够相互连接,从而为您提供 24x7 的良好购物体验。

优点和缺点

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

优点

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

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

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

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

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

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

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

缺点

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

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

  • 企业就绪性 - 微服务架构可以被认为是不同技术的集合,因为技术日新月异。因此,与传统的软件开发模型相比,很难使微服务应用程序达到企业就绪状态。

微服务优于 SOA

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

组件 SOA 微服务
设计模式 SOA 是一种计算机软件设计范例,其中软件组件以服务的形式向外部世界公开以供使用。 微服务是 SOA 的一部分。它是 SOA 的一种专门实现。
依赖性 业务单元相互依赖。 所有业务单元都是相互独立的。
大小 软件大小大于传统软件。 软件大小较小。
技术 技术栈少于微服务。 微服务本质上是异构的,因为使用精确的技术来执行特定任务。微服务可以被认为是许多技术的集合。
自主性和焦点 SOA 应用程序构建用于执行多个业务任务。 微服务应用程序构建用于执行单个业务任务。
性质 单体性质。 全栈性质。
部署 部署耗时。 部署非常容易。因此,它将不那么费时。
成本效益 更具成本效益。 成本效益较低。
可扩展性 与微服务相比较低。 完全可扩展。
示例 让我们考虑一个在线出租车预订应用程序。如果我们想使用 SOA 构建该应用程序,则其软件单元将是:
  • GetPayments 和 DriverInformation 和 MappingDataAPI
  • AuthenticateUsersAnd DriversAPI
如果使用微服务架构构建相同的应用程序,则其 API 将是:
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService
广告