单体 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

相关推荐
guihong0042 小时前
深入解析 ZooKeeper:分布式协调服务的原理与应用
分布式·zookeeper·云原生
guihong0042 小时前
深入探秘 ZooKeeper:架构、设计、角色与 ZNode 全解析 前言
分布式·zookeeper·架构
wangbing11252 小时前
开发指南090-使用python做微服务
微服务·云原生·架构
binqian3 小时前
【harbor】离线安装2.9.0-arm64架构服务制作和升级部署
运维·架构
Kika写代码3 小时前
【基于轻量型架构的WEB开发】课程 实验一 mybatis操作 Java EE企业级应用开发教程 Spring+SpringMVC+MyBatis
前端·架构·mybatis
数据的世界013 小时前
.NET体系架构
架构·c#·.net
极客先躯8 小时前
高级java每日一道面试题-2025年01月08日-微服务篇-负载平衡的意义什么 ?
java·微服务·成本效益·提高可靠性·优化性能·扩展能力·地理位置分布
花花进修8 小时前
什么叫慢查询 ?什么情况下出现?怎么解决,怎么优化 在微服务中
微服务·云原生·架构
金州饿霸11 小时前
HDFS架构原理
hadoop·hdfs·架构