目录
一、软件架构的定义和视图模型
软件架构的定义：
计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。
软件架构的4 + 1视图模型：
- 逻辑视图:开发人员创建的软件元素。在面向对象的语言中，这些元素是类和包。它们之间的关系是类和包之间的关系，包括继承、关联和依赖。
- 实现视图:构建编译系统的输出。此视图由表示打包代码的模块和组件组成，组件是由一个或多个模块组成的可执行或可部署单元。在Java中，模块是JAR文件，组件通常是WAR文件或可执行JAR文件。它们之间的关系包括模块之间的依赖关系以及组件和模块之间的组合关系。
- 进程视图:运行时的组件。每个元素都是一个进程，进程之间的关系代表进程间通信。
- 部署视图:进程如何映射到机器。此视图中的元素由(物理或虚拟)计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系。
二、架构风格
1、分层式架构风格
分层架构将软件元素按层的方式进行组织，每一层只能依赖于下方的层或其下面的任何层。
可以将分层架构应用于前面讨论的四个视图中的任何一个。流行的三层架构是应用于逻辑视图的分层架构。它将应用程序的类组织到以下层中:
- 表现层:包含实现用户界面或外部API的代码。（Controller）
- 业务逻辑层:包含业务逻辑。（Service）
- 数据持久化层:实现与数据库交互的逻辑。（Dao）
Springmvc从大的方面来说，一共有三层。m层：model数据模型层，V:view视图层 C：controller控制层。这是整体上谈的，把控制层往下分，就还可以再分Service层、Dao层、DB层。其中service含有Dao业务逻辑组件，可以通过Dao去操作数据库。
分层架构是架构风格的一个很好的例子，但它确实有些明显的弊端:
- 单个表现层:它无法展现应用程序可能不仅仅由单个系统调用的事实。
- 单一数据持久化层:它无法展现应用程序可能与多个数据库进行交互的事实。
- 将业务逻辑层定义为依赖于数据持久化层:理论上，这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。
2、六边形架构
六边形架构是分层架构风格的替代品。如图2-2所示，六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序具有一一个或多个人站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。同样，应用程序具有一个或多个出站适配器，而不是数据持久化层，这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的--个关键特性和优点是业务逻辑不依赖于适配器。相反，各种适配器都依赖业务逻辑。
3、微服务架构是一种架构风格
微服务架构也是一-种架构风格。它的实现视图由多个组件构成:一-组可执行文件或WAR
文件。它的组件是服务，连接器是使这些服务能够协作的通信协议。每个服务都有自己的逻
辑视图架构，通常也是六边形架构。
- 单体架构：将应用程序构建为单个可执行和可部署组件
- 微服务架构：将应用程序构建为松耦合、可独立部署的一组服务
三、为应用程序定义微服务架构
服务的分解有几个障碍需要克服。首先是网络延迟。你可能会发现，由于服务之间的网络往返太多，特定的分解将是不切实际的。分解的另一个障碍是服务之间的同步通信降低了可用性。你可能需要使用第3章中描述的自包含服务的概念。第三个障碍是需要维护跨服务的数据一致性。你需要使用第4章中讨论的Saga。分解的第四个也是最后--个障碍是所谓的上帝类( God Class),它广泛应用在整个应用程序中。幸运的是，你可以使用领域驱动设计中的概念来消除上帝类。
1、识别系统操作
第一步是创建由关键类组成的抽象领域模型，这些关键类提供用于描述系统操作的词汇表。第二步确定系统操作，并根据领域模型描述每个系统操作的行为。系统操作被定义后，下一步就是完成应用服务的识别。
2、根据业务能力进行服务拆分
特殊业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。在线商店的业务能力包括:订单管理、库存管理和发货，等等。一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。
3、根据子域进行服务拆分
领域模型以解决具体问题的方式包含了一个领域内的知识。DDD把领域模型的边界称为限界上下文( bounded context)。限界上下文包括实现这个模型的代码集合。当使用微服务架构时，每-一个限界上下文对应-一个或者一组服务。换一种说法，我们可以通过DDD的方式定义子域，并把子域对应为每一个服务，这样就完成了微服务架构的设计工作。图2-9展示了子域和服务之间的映射，每-一个子域都有属于它们自己的领域模型。领域驱动设计(DDD)
4、拆分单体应用为服务的难点
- 网络延迟
网络延迟是分布式系统中一直存在的问题。你可能会发现，对服务的特定分解会导致两个服务之间的大量往返调用。有时，你可以通过实施批处理API在一次往返中获取多个对象，从而将延迟减少到可接受的数量。但在其他情况下，解决方案是把多个相关的服务组合在一起，用编程语言的函数调用替换昂贵的进程间通信。
- 同步进程间通信导致可用性降低
另一个需要考虑的问题是如何处理进程间通信而不降低系统的可用性。例如，实现
createOrder ()操作最常见的方式是让Order Service 使用REST同步调用其他服务。这样做的弊端是REST这样的协议会降低Order Service 的可用性。如果任何一个被调用的服务处在不可用的状态，那么订单就无法创建了。有时候这可能是-一个不得已的折中，但是在第3章中学习异步消息之后，你就会发现其实有更好的办法来消除这类同步调用产生的紧耦合并提升可用性。
- 在服务之间维持数据一致性
另一个挑战是如何在某些系统操作需要更新多个服务中的数据时，仍旧维护服务之间的数据一致性。例如，当餐馆接受订单时，必须在Kitchen Service 和Delivery Service中同时进行更新。Kitchen Service 会更改Ticket的状态。Delivery Service 安排订单的交付。这些更新都必须以原子化的方式完成。传统的解决方案是使用基于两阶段提交( two phase commit)的分布式事务管理机制。但正如你将在第4章中看到的那样，对于现今的应用程序而言，这不是一一个好的选择，你必须使用一种非常不同的方法来处理事务管理，这就是Saga。Saga 是一系列使用消息协作的本地事务。Saga 比传统的ACID事务更复杂，但它们在许多情况下都能工作得很好。Saga 的一个限制是它们最终是一致的。如果你需要以原子方式更新某些数据，那么它必须位于单个服务中，这可能是分解的障碍。
- 获取一致的数据视图
分解的另一个障碍是无法跨多个数据库获得真正--致的数据视图。在单体应用程序中，ACID事务的属性保证查询将返回数据库的一致视图。相反，在微服务架构中，即使每个服务的数据库是一致的，你也无法获得全局一致的数据视图。如果你需要一些数据的一致视图，那么它必须驻留在单个服务中，这也是服务分解所面临的问题。幸运的是，在实践中这很少带来真正的问题。
- 上帝类阻碍了拆分
分解的另一个障碍是存在所谓的上帝类。上帝类是在整个应用程序中使用的全局类，上帝类通常为应用程序的许多不同方面实现业务逻辑。它有大量字段映射到具有许多列的数据库表。大多数应用程序至少有一个这样的上帝类，每个类代表一个对领域至关重要的概念:银行账户、电子商务订单、保险政策，等等。因为上帝类将应用程序的许多不同方面的状态和行为捆绑在一起，所以将使用它的任何业务逻辑拆分为服务往往都是一个不可逾越的障碍。
5、定义服务API
定义服务API的起点是将每个系统操作映射到服务。之后确定服务是否需要与其他服务协作以实现系统操作。如果需要协作，我们将确定其他服务必须提供哪些API才能支持协作。
确定支持服务协作所需要的API
有些系统操作跨越多个服务，例如，为了实现creatOrder（）操作，Order Service必须调用其他服务以验证前置条件并使后置条件成立。
四、小结
- 架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度。
- 微服务架构是- -种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性。
- 微服务中的服务是根据业务需求进行组织的，按照业务能力或者子域，而不是技术上的考量。
- 有两种分解模式:
- 按业务能力分解，其起源于业务架构。
- 基于领域驱动设计的概念，通过子域进行分解。
- 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。
3675
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
