关于微服务:服务拆分

35次阅读

共计 939 个字符,预计需要花费 3 分钟才能阅读完成。

服务拆分准则

有很多个准则,这里拿两个罕用的介绍

  1. 繁多职责 (SRP)

    • 扭转一个类应该只有一个理由。
      如果一个类承载了多个职责,那么,这个类就会非常不稳固。
      微服务架构下,应设计小、内聚、繁多职责的服务,那么会大大提高服务的稳定性。
  2. 闭包准则 (CCP)

    • 包中所有类,应该是同类变动的一个汇合。
    • 也就是说,如果须要对包做调整,须要调整的类、变量等,都应在这个包之内。
      需要变更,改变须要两个耦合的包做调整,这是很大的危险。
      如果业务变更,只需调整同一个包下的类,那么就能够极大的改善,我的项目可维护性。
      微服务架构下,雷同起因须要扭转的服务,放在一个组件内。
      需要变动的变更、部署,代价升高;能够管制服务的数量。
      现实的状况下,一个变更只会影响一个团队。

失常开发中,在评估阶段,有很多因素导致,不能齐全的遵循原则。
为了保障日后的可维护性,尽量的依照准则,若不能齐全遵循,则提前准备分段,给日后保护应用。

  • 代码是首先是给人读,而不是机器。
  • 性能要求不高时,尽可能进步可读性。

拆分服务难点

  1. 网络延时
    大量的接口调用。
    例如,http 接口的调用
    解决办法:
    apigateway,内网中先对某项性能 http、rpc 接口进行聚合
    合并相干性能的服务,应用函数调用,取代接口调用
  2. 同步过程通信,可用性问题
    解决过程通信可用性问题。
    例如,创立订单,调用户服务验证,用户服务不可拜访
    解决办法:
    应用异步事件机制
    针对例子,应用异步事件,批改流程,创立订单分为:提交订单,验证用户等校验阶段,创立胜利,分阶段进步服务可用性
  3. 服务间数据一致性
    某些操作,可能更改多个服务的数据。
    例子:
    餐馆承受订单,需更改 kitchen service 状态、delivery service 状态
    解决办法:
    TCC(Try Confirm Cancle)、
    SAGA、

    https://zhuanlan.zhihu.com/p/…
  4. 获取统一的数据视图
  5. 上帝类
    上帝类是整个应用程序中,应用的全局类。
    例子:
    订单,蕴含,restaurant、delivery 等信息
    而 order 数据表蕴含了所有信息,拆分为 kitchen service、delivery service 就存在问题
    解决办法:
    应用 DDD
    对于例子,对 kitchen service、delivery service 别离实现本人服务外部的订单
正文完
 0