本篇为我阅读《微服务架构设计模式》的读书笔记。如觉得有帮助，请购买正版图书学习。

• 微服务概览
  • 服务的拓展方式（拓展立方）
  • 好处：
  • 弊端：
  • 模式
  • 微服务的模式语言
• 服务拆分策略
  • 软件架构
    • 4+1 视图描述架构
    • 架构的作用
  • 架构风格
  • 拆分方法
    • 第一步：定义系统操作
    • 第二步：定义服务
    • 第三步：定义服务 API 和写协作方式

微服务概览

服务的拓展方式（拓展立方）

1. X 轴拓展：在多个实例直接实现请求的负载均衡
2. Z 轴拓展：根据请求的属性路由请求。不同于 X 轴拓展，每个实例仅负责数据的一个子集
3. Y 轴拓展：根据功能把应用拆分为服务，也就是功能性分解。微服务方式：把应用程序功能性的拆分为一组服务的架构风格。

好处：

1. 高內聚，每个服务都比较小且容易维护
2. 使大型的复杂应用程序可以持续交付和持续部署
3. 每个服务独立，可单独部署和扩展
4. 更容易实验和采纳新技术
5. 更好的容错性，某个服务发生故障，不会影响全局

弊端：

1. 服务拆分和定义是一项挑战
2. 分布式系统本身带来的复杂性，使开发、部署、测试更困难
3. 当部署跨越多个服务的功能时，需要更谨慎地协调更多的开发团队
4. 什么阶段开始使用微服务

模式

模式是针对特定的上下文中发生的问题的可重用的解决方案。常用的模式结构包括三个方面：

1. 需求：描述解决的问题和围绕这个问题的上下文
2. 结果上下文：采用这个模式的结果，包括三个部分：好处，弊端，问题（引入的新问题）
3. 相关模式：五种不同的关系：前导，后续，替代，泛化（针对一个问题的一般解决方案），特化（针对特定模式的具体解决方案）

微服务的模式语言

微服务架构模式语言的概括性视图

微服务模式组：

1. 服务拆分
2. 通信
3. 实现事务管理的数据一致性
4. 查询数据（多数据源数据聚合）
5. 服务部署
6. 可观测性（健康检查，日志聚合，分布式追踪，异常追踪，应用指标，审计日志）
7. 自动化测试
8. 解决基础设施和边界问题的相关模式
9. 安全相关

带来的新问题模式组：

1. 基础设施
2. 应用基础设施
3. 应用

服务拆分策略

软件架构

计算机系统的软件架构是构成这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。—— 《Documenting Software architectures: Views and Beyond》

4+1 视图描述架构

4+1 视图是描述架构的绝佳方式，每个试图都描述了架构的一个侧重面，场景把视图中的元素串联在一起。

1. 逻辑视图：开发人员创建的软件元素（包，类，它们之间的依赖、继承、关联关系）
2. 实现视图：构建编译系统的输出（JAR，WAR，它们之间依赖、组合的关系）
3. 进程视图：运行时的组件（每个元素都是一个进程，进程之间的通信）
4. 部署试图：进程如何映射到机器（机器和进程的映射，机器之间的网络）
5. 用例：把视图串联起来，每个场景负责描述视图中的多个元素如何协作，以完成一个请求。

架构的作用

应用程序一般有两个层面的需求：功能性需求，非功能性需求。架构帮助应用程序满足非功能性需求。

架构风格

1. 分层架构：MVC（数据持久化层，表现曾，业务逻辑层）
2. 六边型架构
3. 单体架构
4. 微服务架构

拆分方法

第一步：定义系统操作

起点是需求，包括故事和其相关的用户场景。定义过程：

1. 创建由关键类组成的抽象领域模型（名词）；
2. 确定系统操作（动词），一般有查询型和命令型系统操作。定义命令型操作可以先列出所有操作，然后列出这些操作的前置条件和后置条件。定义查询型操作可以列出用户在各个阶段需要的查询

第二步：定义服务

根据业务能力进行拆分：业务能力定义了这个组织的业务是做什么的，能做什么通常是比较固定的（比如银行存取款），怎么做会随着时间改变（ATM、柜台）。一旦业务能力确认，就可以将一个能力或者一组相关的能力定义服务。

根据子域进行拆分：领域模型以解决具体问题的方式包含了一个领域的知识，是当前领域相关团队的词汇表，DDD也被称为通用语言。DDD有两个核心概念：子域、界限上下文

第三步：定义服务 API 和写协作方式