《微服务架构设计模式》之二：服务的拆分策略_如何切分微服务

92 浏览量更新于2023-03-03 评论收藏 1016KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

《微服务架构设计模式》之二：服务的拆分策略《微服务架构设计模式》之二：服务的拆分策略

2.1　微服务架构到底是什么

第1章描述了微服务架构的关键思想是如何进行功能分解。你可以将应用程序构建为一组服务，而不是开发一个大型的单体应

用程序。一方面，将微服务架构描述为一种功能分解是有用的。但另一方面，它留下了几个未解决的问题，包括：微服务架构

如何与更广泛的软件架构概念相结合？什么是服务？服务的规模有多重要？

为了回答这些问题，我们需要退后一步，看看软件架构的含义。软件的架构是一种抽象的结构，它由软件的各个组成部分和这

些部分之间的依赖关系构成。正如你将在本节中看到的，软件的架构是多维的，因此有多种方法可以对其进行描述。架构很重

要的原因是它决定了应用程序的质量属性或能力。传统上，架构的目标是可扩展性、可靠性和安全性。但是今天，该架构能够

快速安全地交付软件，这一点非常重要。你将了解微服务架构是一种架构风格，可为应用程序提供更高的可维护性、可测试性

和可部署性。

我将通过描述软件架构的概念及其重要性来开始本节。接下来，我将讨论架构风格的概念。然后我将微服务架构定义为特定的

架构风格。让我们从理解软件架构的概念开始。

2.1.1　软件架构是什么，为什么它如此重要

架构显然很重要。至少有两个专门讨论该主题的会议：Oreilly的软件架构会议和SATURN会议。许多开发人员的目标是成为一

名架构师。但什么是架构，为什么它如此重要？

为了回答这个问题，我首先定义术语软件架构的含义。之后，我将讨论应用程序的架构是多维的，并使用一组视图或蓝图进行

描述。然后我将强调软件架构的重要性，因为它对应用程序的质量属性有显著的影响。

软件架构的定义

软件架构有很多定义。例如，维基百科上列举了大量的定义。

我最喜欢的定义来自卡耐基梅隆大学软件工程研究所（www.sei.cmu.edu）的Len Bass及其同事，他们在使软件架构成为一门

学科方面发挥了关键作用。他们定义的软件架构如下：

计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。

—Bass等著《Documenting Software Architectures: Views and Beyond》

这显然是一个非常抽象的定义。但其实质是应用程序的架构是将软件分解为元素（element）和这些元素之间的关系

（relation）。由于以下两个原因，分解很重要：

它促进了劳动和知识的分工。它使具有特定专业知识的人们（或多个团队）能够就应用程序高效地协同工作。

它定义了软件元素的交互方式。

将软件分解成元素以及定义这些元素之间的关系，决定了软件的能力。

软件架构的4+1视图模型

从更具体的角度而言，应用程序的架构可以从多个视角来看，就像建筑架构，一般有结构、管线、电气等多个架构视角。

Phillip Krutchen在他经典的论文《Architectural Blueprints —

The 4+1 View Model of Software Architecture》中提出了软件架构的4+1视图。

图2-1展示的这套视图定义了四个不同的软件架构视图，每一个视图都只描述架构的一个特定方面。每个视图包括一些特定的

软件元素和它们相互之间的关系。

每个视图的目的如下：

逻辑视图：开发人员创建的软件元素。在面向对象的语言中，这些元素是类和包。它们之间的关系是类和包之间的关系，包括

继承、关联和依赖。

实现视图：构建编译系统的输出。此视图由表示打包代码的模块和组件组成，组件是由一个或多个模块组成的可执行或可部署

单元。在Java中，模块是JAR文件，组件通常是WAR文件或可执行JAR文件。它们之间的关系包括模块之间的依赖关系以及

组件和模块之间的组合关系。

进程视图：运行时的组件。每个元素都是一个进程，进程之间的关系代表进程间通信。

部署视图：进程如何映射到机器。此视图中的元素由（物理或虚拟）计算机和进程组成。机器之间的关系代表网络。该视图还

描述了进程和机器之间的关系。

除了这四个视图以外，4+1中的+1是指场景，它负责把视图串联在一起。每个场景负责描述在一个视图中的多个架构元素如何

协作，以完成一个请求。例如，在逻辑视图中的场景，展现了类是如何协作的。同样，在进程视图中的场景，展现了进程是如

何协作的。

4+1视图是描述应用程序架构的绝佳方式。每一个视图都描述了架构的一个重要侧面。场景把视图中的元素如何协作串联在一

起。现在我们来看看为什么架构是如此重要。

为什么架构如此重要

应用程序有两个层面的需求。第一类是功能性需求，这些需求决定一个应用程序做什么。这些通常都包含在用例（use case）

或者用户故事（user story）中。应用的架构其实跟这些功能性需求没什么关系。功能性需求可以通过任意的架构来实现，甚

至是非常糟糕的大泥球架构。

架构的重要性在于，它帮助应用程序满足了第二类需求：非功能性需求。我们把这类需求也称之为质量属性需求，或者简称

为“能力”。这些非功能性需求决定一个应用程序在运行时的质量，比如可扩展性和可靠性。它们也决定了开发阶段的质量，包

括可维护性、可测试性、可扩展性和可部署性。为应用程序所选择的架构将决定这些质量属性。

2.1.2　什么是架构的风格

在物理世界中，建筑物的建筑通常遵循特定的风格，例如维多利亚式、美国工匠式或装饰艺术式。每种风格都是一系列设计决

策，限制了建筑的特征和建筑材料。建筑风格的概念也适用于软件。David Garlan和Mary Shaw（An Introduction to Software

Architecture，January 1994）这两位软件架构学科的先驱定义了如下架构风格：

因此，架构风格根据结构组织模式定义了一系列此类系统。更具体地说，架构风格确定可以在该风格的实例中使用的组件和连

接器的词汇表，以及关于如何组合它们的一组约束。

特定的架构风格提供了有限的元素（组件）和关系（连接器），你可以从中定义应用程序架构的视图。应用程序通常使用多种

架构风格的组合。例如，在本节的后面，我将描述单体架构是如何将实现视图构造为单个（可执行与可部署）组件的架构样

式。微服务架构将应用程序构造为一组松散耦合的服务。

分层式架构风格

架构的典型例子是分层架构。分层架构将软件元素按“层”的方式组织。每个层都有明确定义的职责。分层架构还限制了层之间

的依赖关系。每一层只能依赖于紧邻其下方的层（如果严格分层）或其下面的任何层。

可以将分层架构应用于前面讨论的四个视图中的任何一个。流行的三层架构是应用于逻辑视图的分层架构。它将应用程序的类

组织到以下层中：

表现层：包含实现用户界面或外部API的代码。

- 业务逻辑层：包含业务逻辑。

数据持久化层：实现与数据库交互的逻辑。

分层架构是架构风格的一个很好的例子，但它确实有一些明显的弊端：

- 单个表现层：它无法展现应用程序可能不仅仅由单个系统调用的事实。

单一数据持久化层：它无法展现应用程序可能与多个数据库进行交互的事实。

将业务逻辑层定义为依赖于数据持久化层：理论上，这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。

此外，分层架构错误地表示了精心设计的应用程序中的依赖关系。业务逻辑通常定义数据访问方法的接口或接口库。数据持久

化层则定义了实现存储库接口的DAO类。换句话说，依赖关系与分层架构所描述的相反。

让我们看一下克服这些弊端的替代架构：六边形架构。

关于架构风格的六边形

六边形架构是分层架构风格的替代品。如图2-2所示，六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序

具有一个或多个入站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。同样，应用程序具有一个或多个出

站适配器，而不是数据持久化层，这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的一个关键特性和优点是业务

逻辑不依赖于适配器。相反，各种适配器都依赖业务逻辑。

业务逻辑具有一个或多个端口（port）。端口定义了一组操作，关于业务逻辑如何与外部交互。例如，在Java中，端口通常是

Java接口。有两种端口：入站和出站端口。入站端口是业务逻辑公开的API，它使外部应用程序可以调用它。入站端口的一个

实例是服务接口，它定义服务的公共方法。出站端口是业务逻辑调用外部系统的方式。出站端口的一个实例是存储库接口，它

定义数据访问操作的集合。

业务逻辑的周围是适配器。与端口一样，有两种类型的适配器：入站和出站。入站适配器通过调用入站端口来处理来自外部世

界的请求。入站适配器的一个实例是Spring MVC Controller，它实现一组REST接口（endpoint）或一组Web页面。另一个实

例是订阅消息的消息代理客户端。多个入站适配器可以调用相同的入站端口。

出站适配器实现出站端口，并通过调用外部应用程序或服务处理来自业务逻辑的请求。出站适配器的一个实例是实现访问数据

库的操作的数据访问对象（DAO）类。另一个实例是调用远程服务的代理类。出站适配器也可以发布事件。

六边形架构风格的一个重要好处是它将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开来。业务逻辑不依赖于表

示层逻辑或数据访问层逻辑。

由于这种分离，单独测试业务逻辑要容易得多。另一个好处是它更准确地反映了现代应用程序的架构。可以通过多个适配器调

用业务逻辑，每个适配器实现特定的API或用户界面。业务逻辑还可以调用多个适配器，每个适配器调用不同的外部系统。六

边形架构是描述微服务架构中每个服务的架构的好方法。

分层架构和六边形架构都是架构风格的实例。每个都定义了架构的构建块（元素），并对它们之间的关系施加了约束。六边形

架构和分层架构（三层架构）构成了软件的逻辑视图。现在让我们将微服务架构定义为构成软件的实现视图的架构风格。

2.1.3　微服务架构是一种架构风格

前面已经讨论过4+1视图模型和架构风格，所以现在可以开始定义单体架构和微服务架构。它们都是架构风格。单体架构是一

种架构风格，它的实现视图是单个组件：单个可执行文件或WAR文件。这个定义并没有说明其他的视图。例如，单体应用程

序可以具有六边形架构风格的逻辑视图。

微服务架构也是一种架构风格。它的实现视图由多个组件构成：一组可执行文件或WAR文件。它的组件是服务，连接器是使

这些服务能够协作的通信协议。每个服务都有自己的逻辑视图架构，通常也是六边形架构。图2-3显示了FTGO应用程序可能

的微服务架构。此架构中的服务对应于业务功能，例如订单管理和餐馆管理。

在本章后面，我将描述业务能力（business capability）的含义。服务之间的连接器使用进程间通信机制（如REST API和异步

消息）实现。第3章将更详细地讨论进程间通信。

微服务架构强加的一个关键约束是服务松耦合。因此，服务之间的协作方式存在一定限制。为了解释这些限制，我将尝试定义

什么是服务，解释松耦合意味着什么，并告诉你为什么这很重要。

什么是服务

服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。图2-4显示了服务的外部视图，在此示例中是Order

Service。服务具有API，为其客户端提供对功能的访问。有两种类型的操作：命令和查询。API由命令、查询和事件组成。命

令如createOrder()执行操作并更新数据。查询，如findOrderById()检索数据。服务还发布由其客户端使用的事件，例如

OrderCreated。

服务的API封装了其内部实现。与单体架构不同，开发人员无法绕过服务的API直接访问服务内部的方法或数据。因此，微服

务架构强制实现了应用程序的模块化。

微服务架构中的每项服务都有自己的架构，可能还有独特的技术栈。但是典型的服务往往都具有六边形架构。其API由与服务

的业务逻辑交互的适配器实现。操作适配器调用业务逻辑，事件适配器对外发布业务逻辑产生的事件。

剩余15页未读，继续阅读

weixin_38534344

粉丝: 0
资源: 917

会员权益专享

《微服务架构设计模式》之二：服务的拆分策略

评论0

会员权益专享

最新资源

《微服务架构设计模式》之二：服务的拆分策略

评论0

微服务架构服务拆分粒度

基于DDD和微服务的中台建设.pdf

《微服务架构设计模式》之三：微服务架构中的进程间通信

微服务架构基础概念与实践：使用Go语言构建微服务

微服务架构中的通信机制：RPC vs RESTful

微服务架构 vs. 单体架构：优缺点对比分析

微服务架构中的安全保护：认证与授权

微服务架构实践：设计和实施策略

微服务架构设计模式pdf

java 微服务架构设计文档

微服务架构及设计模式

解释一下微服务架构模式

什么系统不适合微服务架构

分布式架构和微服务架构的区别

写一篇基于微服务架构的B2C模式的商城的开题报告

提供一个不少于500字的基于微服务架构的流程建模引擎的软件技术特点说明

springboot微服务架构

微服务系统架构怎么搭建

微服务设计中文完整版.pdf

netcore 微服务

会员权益专享

最新资源