微服务设计模式

为什么 单体应用 -> 微服务

交付缓慢

充满故障的软件交付

可扩展性差

如何从 单体应用 -> 微服务

你应该逐步重构你的单体应用, 而不是推到重来. 有3种主要的策略:

1. 将新功能实现为服务

2. 隔离表现层和后端

3. 通过将功能提取到服务中来分解单体

API Gateway: 将对新功能的请求路由到新服务, 并将遗留请求路由到单体.

集成胶水代码: 将服务与单体结合. 它使服务能够访问单体所拥有的数据, 并能够调用单体实现功能.

隔离表现层和后端

表现层: 它由 HTTP 请求的模块组成, 并生成实现 Web UI 的 HTML 页面.

业务逻辑层: 由实现业务规则的模块组成, 这些模块在企业应用程序中可能很复杂.

数据访问逻辑层: 包含访问基础设施服务(如数据库和消息代理)的模块.

业务层具有粗粒度 API, 由一个或多个封装业务逻辑的门面组成. 

提取业务能力到服务中

你想要提取到服务中的功能是对单体应用自上而下的一个"垂直切片". 该切片包含以下内容:

  • 实现 API 端点的入站适配器
  • 领域逻辑
  • 出站适配器, 例如数据库访问逻辑
  • 单体的数据库模式

模式: 反腐层

一个软件层, 用于在两个不同的领域模型之间进行转换, 防止一个模型的概念污染另一个模型.

原文地址:https://www.cnblogs.com/moveofgod/p/14928070.html