课程时长
2天(6小时/天)课程大纲
第一天 | ||
第1部分 | 单体架构的好处 | |
什么是单体地狱 | ||
拯救之道:微服务架构 | ||
扩展立方体和服务 | ||
微服务架构作为模块化的一种形式 | ||
每个服务都拥有自己的数据库 | ||
微服务架构与SOA的异同 | ||
微服务架构的好处和弊端 | ||
微服务架构并不是“银弹” | ||
微服务之上:流程和组织 | ||
进行软件开发和交付的组织 | ||
进行软件开发和交付的流程 | ||
第2部分 | 服务的拆分策略 | |
微服务架构到底是什么 | ||
微服务架构是一种架构风格 | ||
为应用程序定义微服务架构 | ||
识别系统操作 | ||
根据业务能力进行服务拆分 | ||
根据子域进行服务拆分 | ||
拆分的指导原则 | ||
拆分单体应用为服务的难点 | ||
定义服务API | ||
第3部分 | 微服务架构中的进程间通信 | |
在微服务架构中定义API | ||
API的演化 | ||
消息的格式 | ||
基于同步远程过程调用模式的通信 | ||
使用REST | ||
使用gRPC | ||
使用断路器模式处理局部故障 | ||
使用服务发现 | ||
基于异步消息模式的通信 | ||
什么是消息传递 | ||
使用消息机制实现交互方式 | ||
为基于消息机制的服务API创建API规范 | ||
使用消息代理 | ||
处理并发和消息顺序 | ||
处理重复消息 | ||
事务性消息 | ||
消息相关的类库和框架 | ||
使用异步消息提高可用性 | ||
同步消息会降低可用性 | ||
消除同步交互 | ||
第4部分 | 微服务架构中的业务逻辑设计 | |
业务逻辑组织模式 | ||
使用事务脚本模式设计业务逻辑 | ||
使用领域模型模式设计业务逻辑 | ||
关于领域驱动设计 | ||
使用聚合模式设计领域模型 | ||
模糊边界所带来的问题 | ||
聚合拥有明确的边界 | ||
聚合的规则 | ||
聚合的颗粒度 | ||
使用聚合设计业务逻辑 | ||
发布领域事件 | ||
为什么需要发布变更事件 | ||
什么是领域事件 | ||
事件增强 | ||
识别领域事件 | ||
生成和发布领域事件 | ||
消费领域事件 | ||
第5部分 | 使用事件溯源开发业务逻辑 | |
使用事件溯源开发业务逻辑概述 | ||
传统持久化技术的问题 | ||
什么是事件溯源 | ||
使用乐观锁处理并发更新 | ||
事件溯源和发布事件 | ||
使用快照提升性能 | ||
幂等方式的消息处理 | ||
领域事件的演化 | ||
事件溯源的好处 | ||
事件溯源的弊端 | ||
实现事件存储库 | ||
第二天 | ||
第6部分 | 在微服务架构中实现查询 | |
使用API组合模式进行查询 | ||
findOrder()查询操作 | ||
什么是API组合模式 | ||
使用API组合模式实现findOrder()查询操作 | ||
API组合模式的设计缺陷 | ||
API组合模式的好处和弊端 | ||
使用CQRS模式 | ||
为什么要使用CQRS | ||
什么是CQRS | ||
CQRS的好处 | ||
CQRS的弊端 | ||
设计CQRS视图 | ||
选择视图存储库 | ||
设计数据访问模块 | ||
添加和更新CQRS视图 | ||
第7部分 | 外部API模式 | |
外部API的设计难题 | ||
其他类型客户端API的设计难题 | ||
AP IGateway模式的好处和弊端 | ||
实现一个API Gateway | ||
使用现成的API Gateway | ||
开发自己的API Gateway | ||
第8部分 | 开发面向生产环境的微服务应用 | |
开发安全的服务 | ||
传统单体应用程序的安全性 | ||
在微服务架构中实现安全性 | ||
设计可配置的服务 | ||
使用基于推送的外部化配置 | ||
使用基于拉取的外部化配置 | ||
设计可观测的服务 | ||
使用健康检查API模式 | ||
使用日志聚合模式 | ||
使用分布式追踪模式 | ||
使用应用程序指标模式 | ||
使用异常追踪模式 | ||
使用审计日志模式 | ||
使用微服务基底模式开发服务 | ||
使用微服务基底 | ||
从微服务基底到服务网格 | ||
第9部分 | 部署微服务应用 | |
部署模式:编程语言特定的发布包格式 | ||
使用编程语言特定的发布包格式进行部署的好处 | ||
使用编程语言特定的发布包格式进行部署的弊端 | ||
部署模式:将服务部署为虚拟机 | ||
将服务部署为虚拟机的好处 | ||
将服务部署为虚拟机的弊端 | ||
部署模式:将服务部署为容器 | ||
使用Docker部署服务 | ||
将服务部署为容器的好处 | ||
将服务部署为容器的弊端 | ||
使用Kubernetes部署应用程序 | ||
什么是Kubernetes | ||
在Kubernetes上部署Service | ||
部署API Gateway | ||
零停机部署 | ||
使用服务网格分隔部署与发布流程 | ||
部署模式:Serverless部署 | ||
第10部分 | 微服务架构的重构策略 | |
重构到微服务需要考虑的问题 | ||
为什么要重构单体应用 | ||
绞杀单体应用 | ||
将单体应用重构为微服务架构的若干策略 | ||
将新功能实现为服务 | ||
隔离表现层与后端 | ||
提取业务能力到服务中 | ||
设计服务与单体的协作方式 | ||
设计集成胶水 | ||
在服务和单体之间维持数据一致性 | ||
处理身份验证和访问授权 | ||
将新功能实现为服务:处理错误配送订单 | ||