绞杀者应用程序
- 由微服务组成的应用程序,将新功能作为服务,并逐步从单体应用中提取服务来实现。
- 好处
- 尽早并频繁的体现价值
- 快速开发交付,使用
- 与之相对的是“一步到位”重构,这时间长,且期间有新的功能加入,风险极高。
- 快速开发交付,使用
- 尽可能减少对单体进行修改
- 可用策略之一:将新服务的数据,同步到单体数据库。双写
- 尽早并频繁的体现价值
- 策略
- 将新功能实现为服务
- 元素
- API Gateway
- 新功能请求路由到新服务
- 集成胶水代码
- 使服务能够访问单体所拥有的数据,并能够使用单体的功能
- API Gateway
- 元素
- 隔离表现层和后端
- 单体的解耦策略
- 表现逻辑层
- 处理http请求,生成html页面
- 业务逻辑层
- 业务规则
- 数据访问逻辑层
- 访问基础服务,如数据库
- 表现逻辑层
- 将应用程序分离
- 表现层一个服务
- 业务逻辑层和数据访问层一个服务
- 单体的解耦策略
- 通过将功能提取到服务来分解单体
- 提取服务之前,问问自己这样做有什么好处
- 服务边界问题
- 新服务的逻辑需要使用到单体中的类
- 解决方法
- DDD聚合,使用主键来代替
- 比如之间能在一个服务中,直接拿到对象来用,现在变成两个服务,把ID传过去,另一个服务用ID来引用对象(从数据库读取,或请求接口,获取完整对象)
- DDD聚合,使用主键来代替
- 重构数据库
- 为了避免单体更改,进行双写。客户端迁移完成之后,停止双写
- 提取哪些服务,何时提取
- 专注在能够带来最大收益的服务
- 参考点
- 加速开发
- 比如说这块的功能后面几个月会有大量的需求迭代,可以提取出来成一个服务
- 解决性能、可扩展性或可靠性问题
- 允许提取其他一些服务
- 有时候提取一个服务,会简化另一个服务的提取
- 加速开发
- 参考点
- 专注在能够带来最大收益的服务
- 将新功能实现为服务
为什么要重构单体
- 交付缓慢
- 充满故障的软件交付
- 可扩展性差
服务与单体的协作方式
- 重要问题
- 维护服务与单体的数据一致性
- 有时候需要saga来维护
- 维护服务与单体的数据一致性
- 集成胶水
- 反腐层
- 两个不同领域模型之间进行转换,防止一个模型的概念污染另一个模型
- 数据一致性
- 视情况考虑saga
- 身份验证和访问授权
- api gateway
- API gateway来验证用户身份,然后将用户身份信息放入header之中,请求服务的时候带上,那么服务就不需要验证用户是否登录了,直接从header中获取用户信息
- api gateway