详解单体架构和微服务（概念，优缺点和区别）

最新推荐文章于 2024-08-03 16:27:32 发布

天选的爪哇

最新推荐文章于 2024-08-03 16:27:32 发布

阅读量2.8k

点赞数 4

文章标签：架构微服务运维

本文链接：https://blog.csdn.net/xjx666666/article/details/132413595

版权

单体架构和微服务

单体架构和微服务架构区别？为什么要用微服务架构？

单体架构的整个系统是一个War包，即war包走天下。微服务架构的项目是很多个war包（一个子系统一个）。

单体架构的优点:

架构简单
开发测试部署简单

缺点:

随着业务扩展，代码越来越复杂，代码质量参差不齐，开发人员的水平不一，修改每一个小bug都是心惊胆战的。并且在进行开发维护时，所有人都需要向这个服务中提交代码，那么一定是会有大量代码冲突的，所以对于大型企业（一个开发部总共好几百人），微服务架构是必须的，它可以拆分项目进而拆分团队。
由于单体架构，功能复杂，部署慢
扩展成本高，根据单体架构图：假设模块A是一个CPU密集型的模块，而模块B是一个IO密集模块。单体架构上，无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU + 更牛逼的内存 + 更牛逼的磁盘，这成本…
- 举个例子：比如双11，淘宝肯定加服务器，因为并发量太大了。但是如果是单体架构，那么无法只针对相关的服务加机器，比如我们想要个交易服务加机器让它处理订单的并发量更大，那么微服务架构就可以实现，但是单体架构就不可以，它一加机器就是整个项目加，而在这个项目中交易服务可能只占百分之十的资源，即资源利用率太小了。
阻碍了新技术的发展，升级成本高~

微服务架构

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事，类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库，这样变相的也相当于拓展数据库了，原来的单体整个项目对应一个数据库，要想拓展需要某个项目的数据需要整个数据库拓展，分割服务之后一个服务一个数据库了。这样的一个一个的小服务就是微服务.

单体应用，非核心业务出现了重大bug导致系统内存溢出，那么就可能导致整个服务宕机。拆分之后，只是出问题的模块不可用，系统核心功能并不受影响。