微服务优点及拆分原则

Posted javachen__

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务优点及拆分原则相关的知识,希望对你有一定的参考价值。

单机痛点

1.团队规模变大,功能重复建设
2.功能严重耦合,互相影响
3.代码频繁冲突,消耗研发精力
4.打包部署时间久而且经常打包失败
5.业务流量暴增,系统支撑不了

拆分微服务好处

1.复杂业务简单化
2.提升系统并发能力
3.突破单数据库性能瓶颈
4.提高研发人员研发效率,提高交付能力
5.减少发版时间,功能快速验证上线

微服务拆分原则

1.考虑团队人员结构
2.服务粒度适中(先粗粒度后细粒度,先少后多)
3.单一职责原则(高内聚和低耦合)
4.服务自治原则
5.服务之间轻量级通讯协议
6.服务拆分与日常有任务需求并行进行,考虑迁移方案与回滚方案
7.服务拆分避免循环依赖
8.分迭代逐步拆分、持续演进

服务拆分原则及难点

服务拆分原则

有很多个原则,这里拿两个常用的介绍

  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 分别实现自己服务内部的订单

以上是关于微服务优点及拆分原则的主要内容,如果未能解决你的问题,请参考以下文章

微服务当中的4大设计原则及19个解决方案,你知道吗?

一文教你微服务当中的4大设计原则及19个解决方案!

微服务_微服务的架构演进之路

任何架构都离不开服务的拆分,微服务的拆分和远程调用你会吗?

单一垂直分布式架构及微服务的优缺点

你必须了解的微服务架构设计的10个要点!