微服务架构设计模式-（16）重构

绞杀者应用程序

• 由微服务组成的应用程序，将新功能作为服务，并逐步从单体应用中提取服务来实现。
• 好处
  • 尽早并频繁的体现价值
    • 快速开发交付，使用
      • 与之相对的是“一步到位”重构，这时间长，且期间有新的功能加入，风险极高。
  • 尽可能减少对单体进行修改
    • 可用策略之一：将新服务的数据，同步到单体数据库。双写
• 策略
  • 将新功能实现为服务
    • 元素
      • API Gateway
        • 新功能请求路由到新服务
      • 集成胶水代码
        • 使服务能够访问单体所拥有的数据，并能够使用单体的功能
  • 隔离表现层和后端
    • 单体的解耦策略
      • 表现逻辑层
        • 处理http请求，生成html页面
      • 业务逻辑层
        • 业务规则
      • 数据访问逻辑层
        • 访问基础服务，如数据库
    • 将应用程序分离
      • 表现层一个服务
      • 业务逻辑层和数据访问层一个服务
  • 通过将功能提取到服务来分解单体
    • 提取服务之前，问问自己这样做有什么好处
    • 服务边界问题
      • 新服务的逻辑需要使用到单体中的类
      • 解决方法
        • DDD聚合，使用主键来代替
          • 比如之间能在一个服务中，直接拿到对象来用，现在变成两个服务，把ID传过去，另一个服务用ID来引用对象（从数据库读取，或请求接口，获取完整对象）
    • 重构数据库
      • 为了避免单体更改，进行双写。客户端迁移完成之后，停止双写
    • 提取哪些服务，何时提取
      • 专注在能够带来最大收益的服务
        • 参考点
          • 加速开发
            • 比如说这块的功能后面几个月会有大量的需求迭代，可以提取出来成一个服务
          • 解决性能、可扩展性或可靠性问题
          • 允许提取其他一些服务
            • 有时候提取一个服务，会简化另一个服务的提取

为什么要重构单体

• 交付缓慢
• 充满故障的软件交付
• 可扩展性差

服务与单体的协作方式

• 重要问题
  • 维护服务与单体的数据一致性
    • 有时候需要saga来维护
• 集成胶水
• 反腐层
  • 两个不同领域模型之间进行转换，防止一个模型的概念污染另一个模型
• 数据一致性
  • 视情况考虑saga
• 身份验证和访问授权
  • api gateway
    • API gateway来验证用户身份，然后将用户身份信息放入header之中，请求服务的时候带上，那么服务就不需要验证用户是否登录了，直接从header中获取用户信息