暗物质

五种暗能量

  • Simple components
    • 单体应用内部按模块拆分，或者拆分成多个简单组件
    • Design modular components
    • Design smaller components
  • Team autonomy
    • N个团队，彼此交流，就是 $O(N^2)$ 复杂度，A团队需要等 B 团队会议沟通，效率很低
    • Design loosely coupled subdomains
    • Use a modular monolith to separate subdomains
    • Use a microservice architecture to physically separate subdomains
  • Fast deployment pipeline
    • 尽可能的快速、频繁的部署，这样能快速得到反馈
    • Use build acceleration technologies
    • Implement a merge queue
    • Careful physical design of the component
    • Design smaller components by separating subdomains
    • Design components so they can be tested locally
  • Multiple technology stacks
    • 可以用不同的技术栈，将其隔离开来，互不影响
    • Subdomains using different technology stacks should be packaged as separate components
    • Packaging subdomains as separate services make technology upgrades easier
    • Experimentation to discover new technology is useful
  • Segregate by characteristics，例提高可伸缩性的资源需求，提高可用性的可用性需求，提高安全性的安全需求，等等
    • Resource requirements
    • Domain-specific software development regulations
    • Business criticality
    • Security
    • DDD subdomain type

暗物质有五种力量

  • Simple interactions，一些简单重要的操作可以放在一起
  • Efficient interactions，涉及大量网络往返和大量数据传输的分布式操作可能效率太低
  • Prefer ACID over BASE，例如，将操作实现为ACID事务比最终一致的传奇更容易
  • Minimize runtime coupling
  • Minimize design time coupling

相关的模式

图示

Service collaboration patterns

  • Saga 模式
  • CQRS 模式
  • API composition

Communicate

  • Messaging，如 Apache Kafka、RabbitMQ
  • Remote Procedure Invocation，如 REST、gRPC、Apache Thrift

一些重要的设计

  • Database per Service pattern
  • API Gateway pattern
  • Circuit Breaker
  • Access token

可观测性模式

  • Log aggregation
  • Application metrics
  • Audit logging
  • Distributed tracing
  • Exception tracking
  • Health check API
  • Log deployments and changes

Testing patterns

  • Service Component Test
  • Service Integration Contract Test

UI 模式

  • Server-side page fragment composition
  • Client-side UI composition

API Gateway

BFF

客户端的服务发现

服务端的 服务发现

CQRS 模式

  • 命令与读取操作的是不同的数据库,
  • 命令端通过ORM框架将实体保存到 写库 (Write Db), 并将本地改动推送到 读库 (Read Db)
  • 查询端通过数据访问层访问 读库 (Read Db), 使用这种模式可以带来以下好处:
  • 查询更简单
    • 读操作不需要任何的完整性校验, 也不需要外键约束, 可以减少锁争用
    • 我们可以针对查询端单独优化,
    • 还可以使用刚好包含每个模板需要的数据的数据库视图，使得查询变得更快更简单
  • 提升查询端的使用体验
    • 由于这种架构将读写彻底分离,由于一般系统是读操作远远大于写操作,
    • 这给我们的系统带来了巨大的性能提升, 极大的提升了客户的使用体验
  • 关注点分离
    • 读写分离的模型可以使得关注点分离, 使得读模型会变得相对简单

SAGA 模式

  • 假设 T 是执行事务， C 是恢复事务
  • 向前进行， T1 -> T2 -> T3 -> T4 -> T5
  • 恢复模式， T1 -> T2 -> T3 -> C3 -> C2 -> C1
  • 编排（Choreography），事务之间通过 消息异步传递
  • 控制（Orchestration），提供一个中央控制器，方面控制，避免循环依赖

微服务的模式语言

应用模式、应用基础设施、基础设施模式

微服务治理基础设施

领域驱动设计

  • 首先应建立领域模型，确定领域限界上下文，然后才进行微服务拆分，
  • 如果是 数据驱动原则/界面驱动原则 ，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。
  • 领域模型和领域服务应具有高度通用性、稳定性，通过接口层和应用层屏蔽外部变化对业务逻辑的影响
  • 保证核心业务功能的稳定性。
  • 基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。

DDD 设计

1、用模型表达业务实体

  • 使用模型来表达业务概念和知识，并指导数据库、API 等软件的进一步设计。模型思维是软件工程中重要的思维之一，它可以简化复杂问题，并从某一个视角出发让人们更加容易理解问题。
  • 模型是对现实世界的简化，例如地图就是一种有效的模型，帮助人们理解道路和街道
  • 领域模型就是对业务领域简化的模型。

2、识别模型的边界

  • 领域模型集合之间由于业务的相关性可能形成松散的边界，这些边界就是我们分解复杂、大型问题为局部、消息问题的契机
  • 通过辨析模型的相关性，找到边界就能为软件模块的划分（单体架构）、服务的划分（微服务架构）提供指导
  • 在领域驱动中，识别出来的边界被称为界限上下文。

3、识别聚合

  • 在数据库的关系模型中，模型为一张网络结构。这样对于代码实现存在困扰，因为难以处理业务的一致性问题
  • 例如，订单、订单项目、商品之间，订单和订单项目的关系更加密切，具有相同的业务生命周期
  • 在领域驱动设计理念中，我们使用聚合代表一组模型的从属关系，其中起到关键带头作用的模型被叫做聚合根，除此之外被叫做实体和值对象
  • 如果一个聚合只有一个实体，那么聚合根就是这个实体

4、区分实体和值对象

  • 除了聚合根和实体之外，有一些模型看起来就像一次性的，他们没有自己的 ID 来标明身份，更多的是作为某个实体的一部分，表达几个字段的集合
  • 例如，在电商系统中，用户设定的常用地址，就是典型的实体，它有自己的 ID 作为身份。但当用户为订单选择地址时，这时的地址只是订单上的若干字段，我们就会把它处理为值对象

5、操作模型

  • 在领域驱动设计中，为了操作这些模型，又衍生了一些作为“操作者”的对象。
  • 工厂：处理领域模型创建过程的对象，但有时候不是必须的。
  • 服务：用来处理某些业务逻辑的对象。例如，为订单计算总价，或者校验一些业务规则。
  • 仓储：负责将领域模型持久化到数据库中或从数据库中重建的对象，它的目的是为了隔离领域模型和技术实现之间的差异

6、操作模型

  • 为了更好的组织项目中各种各样的对象，我们需要像计算机网络一样分层，来简化复杂项目的复杂性
  • 在领域驱动设计中，推荐使用四层架构
  • (1)用户接入层：处理用户接入的数据结构，例如 RESTful API，或者事件
  • (2)应用层：处理用户的业务操作逻辑，也就是用例，它和用户的使用场景相关
  • (3)领域层：处理通用的领域逻辑，也就是较为专业的业务逻辑，例如订单价格计算
  • (4)基础设施层：用来和基础设施适配，例如连接数据库，操作 Redis等

7、建立领域模型

  • 为了从业务知识中提取出领域模型，人们发明了很多种方法
  • 事件风暴是一种流行的软件建模方法。它的形式是通过工作坊引导业务人员和技术人员共同创作领域模型，以业务事件为线索，探索系统中可能的领域模型
  • 除了事件风暴之外，彩色建模也是一种常用的建模方法。它通过颜色区分不同领域模型的特点，来澄清领域模型的职责。彩色建模在过去的很多年里曾非常流行

Spring系列

SpringBoot

  • starter 方式自动整合了一堆外部依赖，还免去了版本不匹配问题
  • 内置 web容器，观察指标，Spring WebFlux 响应式编程
  • 各种注解，约定配置省去大量配置参数
  • 配置文件方式注入，Value，Config 等相关注解
  • 数据库层面，使用JdbcTemplate，以及JPA注解，一对多，一对一那种，各种持久化注解
  • RestTemplate，类似的回调机制，各种Mapping 注解，body，param，GET/POST 等
  • security模块，用户名/密码认证，访问ULR地址控制等
  • spring-boot admin，提供个多的观测指标，JVM和GC信息等
  • 基于消息和流的整合，整合各种单元测试，数据库Mock，RestMock等

包分层结构

  • config，通过配置参数注入到配置类中
  • entity，实体层，数据库层结构映射为对象结构
  • mapper，数据访问 Data Access Object (DAO)，一般只有mybatis生成的接口，自动创建实现类
  • controller，跟 REST 交互的 HTTP 请求/响应类
  • service，具体的业务逻辑类
  • mq，跟消息队列交互的类
  • client，跟外部服务交互的 REST 类
  • init，实现类 ApplicationRunner 类的初始化类

在线接口文档管理

  • APIDOC
  • Spring REST Docs
  • Swagger

服务注册中心的产品可供选择

  • Consul
  • Zookeeper
  • Etcd
  • Eureka
  • Nacos

Spring Cloud 体系下常用的调用方案

  • RestTemplate
  • Ribbon，Netflix出品，LB策略：随机、轮询、重试、响应时间权重和最空闲连接
  • Feign，内部也使用了 Ribbon 来做负载均衡功能

容错

  • Hystrix，1.5.18后进入维护模式
  • Hystrix Dashboard
  • fallback模式：@FeignClient(value = “card-service”, fallback = MemberCardServiceFallback.class)
  • resilience4j

配置中心

  • Spring Cloud Config，需要借助 Git
  • 携程的 Apollo（阿波罗）
  • 淘宝的 Diamond
  • 百度的 Disconf
  • 360 的 QConf
  • 阿里的 Nacos
  • 也可以基于 Zookeeper

缓存

  • Spring Data Redis，依赖于 Jedis 或 lettuce 客户端
  • 在项目启动时就加载缓存，待数据变更后再回刷缓存
  • @Order(value = 1)//order 是加载顺序，越小加载越早，若有依赖关于，建议按顺序排列即可

定时任务选型

  • XXL-JOB
  • Elastic-Job
  • Quartz
  • TBSchedule
  • Timer 和 TimerTask 是Java组件
  • ScheduledExecutorService、ExecutorService
  • @EnableScheduling
  • ShedLock 可以使我们的定时任务在同一时刻，最多执行一次

Backend For Frontend，意为服务于前端的后端

  • 可以采用 Java、Node.js、PHP 或者 Go 等其它语言来实现 BFF 层
  • 倾向于由前端代码构建，因为 BFF 层与前端贴合更紧密

消息中间件

  • Apache ActiveMQ
  • RabbitMQ
  • ZeroMQ
  • Kafka
  • Apache RocketMQ
  • @StreamListener(Sink.INPUT)
  • @EnableBinding({Source.class})

RPC

  • Dubbo，现跟 Spring cloud 整合已经很好了
  • 有一整套的生态系统

网关

  • Spring Cloud Gateway，替代了 Zuul，其已经进入维护期了
  • 在 Gateway 模块中引入 Hystrix 可以做熔断降级处理
  • Gateway 组件内部默认实现了 Redis + Lua 进行限流
  • 默认提供的 RedisRateLimter 的核心逻辑为判断是否取到令牌的实现
  • 跨域支持，前后端分离部署后，需要支持跨域请求
  • JWT，轻量级的网关鉴权方案
  • 通过 swagger，将所有微服务 API 做聚合展示

分布式事务，Seata

  • TC——事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚，独立于各应用之外。
  • TM——事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务，也就是事务的发起方。
  • RM——资源管理器：管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚，RM 自当是维护在各个微服务中
  • @Transactional(rollbackFor = Exception.class)
  • @GlobalTransactional

分布式锁

  • 基于 redis 集群的 Redission

系统应用监控

  • Actuator 插件
  • Spring Boot Admin

服务链路跟踪

  • Application Performance Management APM
  • Pinpoint
  • Zipkin
  • CAT
  • SkyWalking

参考