单体 vs 微服务 怎么选?

选择架构的原则:

要从哪些方面考虑使用单体还是微服务?

● 成本

● 服务性能

● 发版上线

● 服务可靠性与稳定性

● 代码可维护性与拓展性

单体 vs 分布式(微服务)

1 单体 微服务
成本
性能 略差(多了一层网络的交互)
发版上线的效率(部署与迭代升级) 简单 略复杂
服务可靠性与稳定性
代码可维护性与拓展性

参考

https://www.51cto.com/article/718541.html

为什么会使用微服务,微服务解决了什么问题?

早期的单体架构更有优势,因为成本低,开发快,性能好,部署容易

但是随着版本的迭代升级,功能越来越多,各种代码逻辑依赖错综复杂,

● 代码将变得难以维护,

● 开发难度激增:增加一个功能可以需要改动多处的代码

● bug 频繁:代码的改动容易引发连锁效应,造成无穷无尽的报错

代码变得复杂之后维护成本急剧上升,这时候就需要进行功能的拆分,选用微服务.

  • 编译缓慢: 代码量大,编译时间就;每一个小功能的开发,测试,上线的周期更长(一个更改编译 10 几分钟)
微服务的作用与解决什么问题

● 降低代码的维护成本

● 提高开发效率

● 提高服务的稳定性(降低 bug 对服务的影响)

说简单一点,单体开发不下去了,改一个地方,要同时对很多地方进行调整,更加容易出 bug,一出 bug 整个服务全部受到影响;

项目中如何选择:

需要根据项目的具体情况:

  • 成本预算
  • 团队规模
  • 项目的初期复杂度

来决定使用单体还是微服务

一般的情况

项目开始先使用单体,

成本低,开发快,功能上线容易,能够快速上线并收获用户的反馈(先花小的代价摸清产品未来的发展方向)

随着产品方向的确定,功能也会越来越复杂,一般 10-50 万行代码的样子就要开始考虑服务的拆分了(具体情况还要看项目的具体业务但还是从团队规模,开发周期,错误量等方面综合考虑)

拆分信号:

  1. 部署特别慢: 一个服务部署超过 10 分钟(代码量大,编译时间长)
  2. 开发比较久: 这个说起来很模糊,什么才算开发久,复杂的功能就是开发比较久,简单的工能开发相对比较快,但是有一个核心指标就是相同复杂度的需求,开发周期比原来慢一倍(一个更改要影响到很多地方,同时更改)
  3. 错误比较多(维护困难): 这个就是你开发的功能好了,被人的功能用不了了,并且维护起来特别麻烦 (一个更改要影响到很多地方, 但是其他地方没有做更改导致错误)
  4. 提交冲突严重: 团队比较大的时候,所有人更改一个库,提交代码的时候经常遇到冲突,让人心烦意乱

如何拆分?

了解了为什么拆分微服务,什么时候拆分微服务,那么现在我们需要知道如何拆分微服务

  • 比如现在你是项目经理,你是架构师,你负责对项目进行拆分的时候应该怎么做
哪些原则

微服务拆分规范:

  1. 单一职责
  • 每个服务只实现某一个类型的业务需求,而不是将不同类型的业务需求杂揉在一起,
  • 每个服务可以独立部署,不需要依赖其他的服务(避免环形依赖与双向依赖)

好处:

1.项目可读性更好,可以快速找到某个功能的位置,便于开发维护,排错等

  1. 服务个隔离性,服务的耦合度低,一旦服务出错影响范围小

  2. 松耦合

    • 每个服务使用自己的一套组件,进一步降低服务间的耦合度,避免服务间的相互影响(数据库进行拆分等等,避免共享数据)

好处:

  1. 很清楚的知道这个服务在干什么,一旦功能出了问题可以快速定位

  2. 依赖项越少,出问题影响的范围小(依赖的东西可能出问题,尽量减少没必要的依赖数据库什么的)

  3. 演进式拆分

    • 逐步拆分而不是一次性拆的很细,比如短视频服务,拆分的时候可以先将视频服务拆分出去,没问题后再将聊天功能拆分出去
    • 避免一次性一次性拆的太细,工作量激增,开发测试变得困难
  4. 设计通用化接口而不是定制性接口,避免服务间强依赖

  • 不要为某个服务的需求定制接口,降低服务耦合度,开发维护起来越简单(如果定制接口越多,开发维护就会越复杂,要针对性改每一个接口)
具体场景
  • 根据业务分类进行拆分:
    例子: 短视频服务:视频服务,用户服务,社交服务
  • 根据接口压力进行拆分:
    例子短视频压力巨大,占全部请求的 80% 以上,就可以将接口单独拆出来成为一个服务,方便拓展与隔离
  • 根据团队情况进行拆分:
    比如团队的数量,团队人数进行拆分服务的数量.方便分配每个团队的任务.

参考

https://cloud.tencent.com/developer/article/1834786

https://chatgpt.com/c/6780f932-ccf4-8007-bcbd-2a4b3c0e6266

https://www.cnblogs.com/crazymakercircle/p/17847461.html#美团面试微服务如何拆分原则是什么

https://zhuanlan.zhihu.com/p/333393446

相关推荐
陌殇殇1 小时前
002 SpringCloudAlibaba整合 - Feign远程调用、Loadbalancer负载均衡
java·spring cloud·微服务
网络安全(king)7 小时前
网络安全知识:网络安全网格架构
安全·web安全·架构
东风微鸣9 小时前
TTRSS 迁移实战
docker·云原生·kubernetes·可观察性
落落落sss10 小时前
MongoDB
数据库·windows·redis·mongodb·微服务·wpf
Smile_Gently11 小时前
Docker
云原生·eureka
黄名富11 小时前
Spring Cloud — 深入了解Eureka、Ribbon及Feign
分布式·spring·spring cloud·微服务·eureka·ribbon
Diligent_lvan12 小时前
聊聊istio服务网格
云原生·istio
小丑西瓜66612 小时前
分布式简单理解
linux·redis·分布式·架构·架构演变
企鹅侠客12 小时前
kube-proxy怎么修改ipvs规则?
云原生·kubernetes·kubelet
仇辉攻防12 小时前
【云安全】云原生- K8S 污点横移
web安全·网络安全·云原生·容器·kubernetes·k8s·安全威胁分析