微服务设计模式 - 13 微服务架构重构策略
为什么 单体应用 -> 微服务
交付缓慢
充满故障的软件交付
可扩展性差
如何从 单体应用 -> 微服务
你应该逐步重构你的单体应用, 而不是推到重来. 有3种主要的策略:
1. 将新功能实现为服务
2. 隔离表现层和后端
3. 通过将功能提取到服务中来分解单体
API Gateway: 将对新功能的请求路由到新服务, 并将遗留请求路由到单体.
集成胶水代码: 将服务与单体结合. 它使服务能够访问单体所拥有的数据, 并能够调用单体实现功能.
隔离表现层和后端
表现层: 它由 HTTP 请求的模块组成, 并生成实现 Web UI 的 HTML 页面.
业务逻辑层: 由实现业务规则的模块组成, 这些模块在企业应用程序中可能很复杂.
数据访问逻辑层: 包含访问基础设施服务(如数据库和消息代理)的模块.
业务层具有粗粒度 API, 由一个或多个封装业务逻辑的门面组成.
提取业务能力到服务中
你想要提取到服务中的功能是对单体应用自上而下的一个"垂直切片". 该切片包含以下内容:
- 实现 API 端点的入站适配器
- 领域逻辑
- 出站适配器, 例如数据库访问逻辑
- 单体的数据库模式
模式: 反腐层
一个软件层, 用于在两个不同的领域模型之间进行转换, 防止一个模型的概念污染另一个模型.
