Microservice Architecture 简明教程

在面向服务架构中，整个软件包将被细分为小的、相互关联的业务单元。每个这些小的业务单元将使用不同的协议互相通信，以向客户交付成功的业务。现在的问题是，微服务架构（MSA）与 SOA 有什么不同？一句话来说，SOA 是一种设计模式，微服务是实现 SOA 的实现方法，或者我们可以说微服务是 SOA 的一种类型。

以下是开发以微服务为导向的应用程序时需要记住的一些规则。

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

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

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

在上面的图像中，您可以看到用于存储不同用户和业务数据的不同模块，例如数据库。在前端，我们有不同的设备，我们通常在那里呈现用户或业务数据以供使用。在中间，我们有一个包可以是可部署的 EAR 或 WAR 文件，它接受用户末端的请求，借助于资源对其进行处理，然后将其呈现在用户面前。在业务需要对上述范例进行任何更改之前，一切都很好。

考虑以下情况，您必须根据业务需求更改应用程序。

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

现在，您的业务部门需要对“签出”模块进行一些更改以包括“钱包”选项。您现在必须更改“签出”模块并将它重新部署到服务器中。请注意，您正在重新部署软件包的不同模块，而我们并没有对其进行任何更改。这就是面向服务的架构，更具体地说是微服务架构的概念的由来。我们可以以这种方式开发单体应用程序，使得软件的每个模块都充当独立的单元，能够独立地处理单个业务任务。

考虑以下示例。

在上述架构中，我们不会创建包含端到端紧凑服务的任何 ear 文件。相反，我们通过将它们作为服务公开来划分软件的不同部分。软件的任何部分都可以通过使用各自的服务来轻松地彼此进行通信。这就是微服务在现代 Web 应用程序中扮演重要角色的方式。

让我们在微服务的意义上比较我们的购物车示例。我们可以将购物车分解为不同的模块，例如“搜索”、“筛选”、“签出”、“购物车”、“推荐”等。如果我们想构建一个购物车门户，那么我们必须构建上述模块，使其能够彼此连接，以提供 24x7 良好的购物体验。

以下是一些使用微服务而非使用单体应用程序的优势：

下表列出了 SOA 和微服务的某些特性，展示了与 SOA 相比使用微服务的重要性。