微服务分解策略

微服务架构的关键思想是功能分解。这意味着您无需开发单个大型应用程序，就可以将您的应用程序结构分解为一组逻辑服务。

应用程序的体系结构很重要，因为它决定了服务的质量

• 传统目标：可伸缩性，可靠性和安全性。
• 其他现代目标：快速，安全地提供服务。可维护性，可测试性和可部署性。

软件构架

应用程序的体系结构是将其分解为组件以及这些组件之间的关系。

分解很重要，因为它有助于团队之间的工作和知识分配，并提供应用程序整体工作的清晰度。

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

它定义了软件体系结构的四个视图

逻辑视图

• 由开发人员创建
• 组件：类和包
• 关系：他们之间的关系

开发视图 /实施意见

• 组件：模块（JAR）和可部署/可执行（WAR）
• 关系：依赖关系

进程视图

• 组成部分：进程
• 关系：IPC

物理视图

• 组件：机器和流程（节点）
• 关系：网络

4 + 1视图模型中的+1代表动画视图，并描述特定视图中的各个组件如何协同工作以处理请求。

架构风格

分层架构

分层体系结构将软件组件分层组织。层可以依赖于其下面的任何层。

流行的三层架构是分层架构

分层架构的缺点

• 依赖性没有很好地表示。
• 并不表示架构可以具有多个表示层。
• 并不代表该体系结构可以具有多个数据存储的事实。
• 应用程序层与数据层紧密耦合，因此在没有数据库的情况下很难测试应用程序逻辑。

六角形架构

基于建筑风格的整体

整体架构可以定义为一种架构样式，该架构样式将实现 视图表示为单个组件：单个可执行文件或可部署文件。

基于架构风格的微服务

架构风格的微服务架构表示一个具有一组多个组件的实现视图：可执行文件和Wars。

组件是服务，关系是通过通信协议进行的。尽管通常实现六边形体系结构，但是各个服务可以自由选择其体系结构。

微服务架构服务的关键约束应该松散耦合。

服务

服务是实现某些有用功能的独立，可独立部署的组件。

服务通常提供两类动作

• 命令：执行操作并更新数据。
• 查询：获取数据

服务还会发布事件。

松耦合

任何两个服务将仅通过API进行通信。API隐藏了服务的内部实现。两个服务不共享同一数据库以提供运行时隔离，因此一个服务无法持有将阻止另一服务的锁。

定义应用程序的微服务架构

步骤如下：

• 识别系统操作。
• 身份服务
• 为每个服务及其之间的交互定义API

识别系统操作

将系统视为黑匣子。现在确定所有系统操作。

系统操作是应用程序必须处理的请求的抽象。它可以是命令，也可以是查询。

它涉及以下操作：

• 收集系统的需求。
• 确定通常从需求中的名词派生的域模型。
• 确定通常从需求中的动词派生的系统操作。
• 从UI和UX的角度看，将在系统上执行哪些操作。

定义服务

有两种方法可以识别系统中的服务：

• 按业务能力分解
• 按域驱动器设计分解

分解原理

单一责任原则

一个类只有一个改变的理由。（罗伯特·马丁（Robert C.Martin））

开放关闭原则

包中的类应针对相同的更改一起封闭。影响软件包的更改会影响该软件包中的所有类。（罗伯·马丁（Rober C.Martin））

将应用程序分解为服务的障碍

• 网络延迟（高往返）
• 由于同步通信，降低了应用程序的可用性。
• 维护各服务之间的数据一致性
• 获取数据库的一致视图。
• 上帝类（在所有服务中都使用的班）

定义服务API

服务API有两类

• 暴露给外部客户端。
• 用于内部服务协作。