part1. Domain Driven Design(Strategic Design,Tactical Design)

Top Down

focus on business or activityy domain

Ubiquitous Language:统一语言

Tactical Design Tools：战术性设计工具

Implementing Domain Driven Design(Event storming,DDD in code)

DDD总结：

Monoliths（大单体应用）

单体应用的优缺点：

part2.microservice architect patterns(微服务架构模式)

1.独享数据库(Database per microservice)

优点：

• 数据由服务完全所有

• 服务的开发团队之间耦合度降低

缺点：

• 服务间的数据共享变得更有挑战性

• 在应用范围内的保证ACID事务变的困难许多

• 细心设计如何拆分单体数据库是一项极具挑战的任务

使用独享数据库的场景：

• 在大型企业应用程序中

• 在团队需要完全把控微服务以实现开发规模扩展和速度提升

不适合使用独享数据库的场景：

• 在小规模应用中

• 如果是单个团队开发所有微服务

可用技术demo: 所有SQL,NOSQL数据库都提供的逻辑分离(eg：单独的表、集合、结构、数据库)

2.事件源（Event Sourcing）(消息)

优点:

• 为高可伸缩系统提供原子性操作

• 自动记录实体变更历史，包括时序回溯功能

• 松耦合和事件驱动的微服务

缺点：

• 从事件存储中读取实体成为新挑战，通常需要额外的数据存储（CQRS模式）

• 系统整体复杂度增加了，通常需要领域驱动设计

• 系统需要处理事件重复（幂等）或丢失

• 变更事件的结构成为新的挑战

使用事件源场景：

• 使用关系数据库的、高可伸缩的事务型系统

• 使用NOSQL数据库的事务型系统

• 弹性高可伸缩微服务架构

• 典型的消息驱动或事件驱动系统（电子商务、预定和预约系统）

不适合使用事件溯源的场景：

• 使用SQL数据库的低可伸缩性事务型系统

• 在服务可以同步交换数据（eg:通过API）的简单微服务架构中

可用技术demo: 事件存储：EventStoreDB, Apache kafka, Confluent Cloud, AWS kinesis, Azure Event Hub, GCP Pub/Sub, Azure Cosmos DB, Mongodb, Cassandra, Amazon DynamoDB

框架：Lagom,Akka,spring,akkatecture,Axon,Eventuate

3.命令和查询职责分离(CQRS)

• 简单模式：强化单一职责和分离关注点，从而实现简洁设计
  

• CQRS高级模式：读写分离

优点：

• 在事件驱动的微服务中数据读取速度更快

• 数据的高可用性

• 读写系统可独立扩展

缺点：

• 读数据存储是弱一致性（最终一致性）

• 整个系统的复杂性增加了，混乱的CQRS会显得危害整个项目

使用CQRS场景：

• 在高可扩展的微服务架构中使用事件源

• 在复杂领域模型中，读操作需要同时查询多个数据存储

• 在读写操作负载差异明显的系统中

不适合使用CQRS的场景：

• 在没必要存储大量事件的微服务架构中，用事件快照来计算实体状态是一个更好的选择

• 在读写操作负载相近的系统中

可用技术demo:

写存储：EventStoreDB,Apache kafka, Confluent Cloud,AWS kinesis,Azure Event Hub, GCP Pub/Sub,Azure cosmos DB,mongodb,Cassandra,Amazon DynamoDB

读存储：es, Solr,Cloud Spanner,Amazon Aurora,Azure Cosmos DB,Neo4j

框架：Lagom,Akka,Spring,akkatecture,Axon,Eventuate

4.saga:实现分布式事务

saga使用于服务流程特别复杂长，如果本地事务失败，saga会执行一系列补偿事务来回滚前面本地事务的更改。

Saga事务协调管理主要有两种形式：

1. 事件编排Choreography:分散协调，每个微服务生产并监听其他微服务的事件或消息然后决定是否执行XX动作

2. 命令编排Orchestration:集中协调，由一个协调器告诉参与的微服务哪个本地事务需要执行

优点：

• 为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务

• 为使用了不支持2pc的非关系数据库的微服务框架提供一致性事务

缺点：

• 需要处理瞬时故障，并且提供幂等性

• 难以调试，而且复杂性随着微服务数量增加而增加

使用saga场景：

• 在使用事件源的高可伸缩、松耦合的微服务中

• 在使用了分布式非关系数据库的系统中

不适合使用saga场景：

• 使用关系数据库的低可伸缩性事务型系统

• 在服务间存在循环依赖的系统中

可用技术demo:

Axon,Eventuate,Narayana

5.面向前端的后端（BFF）：为前端定制了一个后端

优点：

• 分离BFF之间的关注点，使得可以为具体的UI优化

• 提供更高的安全性

• 减少ui和下游微服务之间频繁的通信

缺点：

• BFF之间代码重复

• 大量的BFF用于其他用户界面（eg：智能电视、web、移动端、pc桌面版）

• 需要仔细的设计和实现，BFF不应该包括任何业务逻辑，而应只包含特定客户端逻辑和行为

使用BFF的场景：

• 如果应用程序有多个含不同api需求的ui

• 出于安全需要，UI和下游微服务之间需要额外的层

• 如果在UI开发中使用微前段

不适合BFF的场景：

• 如果应用程序虽有多个UI，但使用的API相同

• 如果核心微服务不是部署在DMZ网络中

可用技术demo:

任何后端框架(Node.js,spring,Django,Laravel,Flask,Play)

6.API网关

优点：

• 在前端和后端服务之间提供松耦合

• 减少客户端和微服务之间的调用次数

• 通过SSL终端、身份验证和授权实现高安全性

• 集中管理的横切关注点，eg: 日志记录和监视、节流、负载均衡

缺点：

• 可能导致微服务架构中的单点故障

• 额外的网络调用带来的延迟增加

• 如果不进行扩展，容易成为整个企业应用的瓶颈

• 额外哦维护和开发费用

使用API网关的场景：

• 在复杂的微服务架构中，几乎是必备的

• 在大型企业中，API网关是中心化安全性和横切关注点的必要工具

不适合使用API网关的场景：

• 在安全和集中管理不是最优先要素的私人项目或小公司中

• 如果微服务的数据相当少

可用技术demo:

Amazon API网关，Azure API网管，kong, Apigee,WSO2 API管理器

7.Strangler（扼杀者）:单体向微服务过度的架构中使用 （Facade）

优点：

• 安全的迁移单体应用程序到微服务

• 可以并行的迁移已有功能和开发新功能

• 迁移过程可以更好的把控节奏

缺点：

• 在现有的单体应用服务和新的微服务之间共享数据存储变得具有挑战性

• 添加Facade(API网关)将增加系统延迟

• 端到端测试变得困难

使用Strangler的场景：

• 将大型后端单体应用程序的增量迁移到微服务

不适合用Strangler的场景：

• 如果后端单体应用很小，全量替换更好

• 如果无法拦截客户端对遗留的单体应用程序的请求

可用技术demo:

API网关后端应用框架

8.断路器

优点：

• 提高微服务架构的容错性

• 阻止引发其他微服务的级联故障

缺点：

• 需要复杂的异常处理

• 日志和监控

• 应该支持人工复位

使用断路器的场景：

• 在微服务间使用同步通信的紧耦合的微服务架构中

• 如果微服务依赖多个其他微服务

不适合使用断路器的场景：

• 松耦合、事件驱动的微服务架构

• 如果微服务不依赖其他微服务

可用技术demo:

API网关、服务网格、各种锻炼器库（Hystrix,Reselence4j,Polly）

9.外部化配置：代码与配置分离，不耦合

优点：

• 生产配置不属于代码库，因而最小化了安全漏洞

• 修改配置参数不需要重新构建应用程序

缺点：

• 需要依赖一个支持外部化配置的框架

• 何时需要使用外部化配置

• 在验证概念的开发中

• 任何重要的生产应用程序都能必须使用外部化配置

可用技术demo:

几乎所有企业级的现代框架都支持外部化配置，eg:nacos /阿波罗

10.消费端驱动的契约测试 :自动化测试

BDD

需求驱动的契约测试使用场景：

在大型企业业务应用程序中，通常由不同的团队开发不同服务；

不适合使用消费端驱动的契约测试场景：

• 所有微服务由同一团队负责开发的小型简单的应用程序

• 如果服务端微服务是相对稳定的，并且不处于活跃的开发状态

可用技术demo:

pack,postman,springcloud contract,swagger3