单体架构到微服务架构的演变

前言

随着互联网的飞速发展，现如今的应用复杂度可谓是“叹为观止”，这给开发和运维人员带来了不小的挑战。本文会介绍单体架构、分布式架构、微服务架构之间的区别和联系，主要的思想源于《分布式系统实战派》这本书籍。

（笔者水平有限，有不对的地方，还望指正）

单体架构

无论是以前，还是现在，都是一种非常常见且流行的系统架构设计。说得直白一点，就是一个项目就是一个文件夹，所有的代码都往这个文件夹里面塞。当然，为了开放方便和利于维护，我们往往会给项目进行分层，以Web项目举个例子：

平时的学习或者开发过程中，接触最多的就是三层架构了，也就是MVC嘛，【控制层，业务层，持久化层】。也许你会听过什么洋葱圈、四层架构、DDD等，不过这都不重要，本质上就是一种代码的耦合方式嘛。

一个文件夹，很方便，测试、编译、打包、部署、上线。一套操作，行云流水，岂不美哉。确实是这样的，笔者也深有体会。

但是，我们考虑一个问题，这个项目越来越大的时候，会发生怎样的情况？

对于开发人员来说，需求的不断增多，导致文件越来越多，很难不发生代码的冗余现象。你也可以想一下，是不是平时开发的时候，有些时候为了图方便，这里加一点东西，那里加一点东西，就可以把某个功能实现了。实际上，这种做法给后期的代码维护造成了很大的弊端（如果你有长时间迭代项目的经验的话，肯定明白我在说什么）。哪怕你运用了各种吊炸天的设计模式，很抱歉，随着需求的增多，也都是会沦为“屎山代码”。

一个人开发的项目还好，反正自己写的代码，自己能够读得懂（事实上，有些时候，你隔几天去看，你都会理解半天）。如果是团队开发，那可就真的是“乱交”了。不用说你也能想到，代码的提交的混乱，各种冲突，两眼一黑。

屎山就屎山喽，反正项目准时上线，功能做好不就行了嘛，“代码和我只要有一个能跑就行了”。一个项目实例一台机器，并发量高了，搞一个网关嘛，负载均衡到我的服务实例上。

你倒是清高哦，数据库那边屁股都快开花了！！！

哎哟，真的是，读写分离嘛，做个一主多从的。开发的代码不用改嘛？运维是不是得夸你呢？

好了，现在你就是不断给自己找事儿，后期要添加或者修改什么需求的，严重点都需要重新部署，又要走一遍流程喽，各部门真的是叫苦连天。

分布式架构

一般来说呢，系统的吞吐量都会在数据库上面，因为数据要进行持久化的话，肯定是要写入硬盘的，I/O相较于内存读写而言，效率差了几个数量级。

反正现在通过这种集群的方式，服务实例可以扛得住。数据库那边的话，读写分离后，读的压力可以通过多个从节点来解决，写得慢的话，那就多开几台机器，一起写，处理好数据同步就行了。

分布式架构的一大特征就是数据的分散处理与存储，这样的好处不言而喻，系统的吞吐量大大提高，而且还可以进行多地部署，提高容错率，一个地方的机房被破坏了，还有其他地方可以用。

确实好，但是数据的同步与一致性是一个巨大的挑战。

我们的服务实例也可以这样的嘛，在不同的地区部署，进行就近的服务提供，搭配分布式的数据库，爽歪歪！！！

爽个麻雀，爽。这TM是要花很多钱的，而且技术的难度和挑战性你是一点也不提啊，此方案提出，可能第二天你就走人了。

微服务架构

微服务架构其实是分布式架构的一个子集，即微服务天生就是分布式的（当然，这取决于你怎么部署的）。

微服务其实就是对原有单体项目的一个拆分，是一种“分而治之”的思想，通过拆分成不同的服务，服务之间明确各自的分工与职责，各自独立，不同的团队可以对某个服务进行个性化开发，服务之间利用网络进行通信。

每个服务原则上来说都有自己的数据库实例，所以微服务项目具有天然的高并发特性。

无论是对开发，还是对运维，这都是一种很好的选择，虽然本质上还是加机器：原来单体就是一台机器嘛，现在部署一个微服务项目，就单论服务应用来说，你都至少需要好几台机器，更别说你需要给这些服务做集群，保证其高可用性。

总结

微服务虽然好，但是要想完整的落地实现，需要足够的资金（很多的机器）以及技术经验（数据的同步、服务的容错等），对于大多数人而言，也只是学习了这个技术该怎么使用，并不会说自己去弄一个完整的微服务环境出来。单体架构也不是一无是处，如果没有成熟的微服务经验，或者明确了这个项目并不会短时间内进行快速的更新迭代，那么单体架构完全可以胜任，制定规范，写好代码，定期重构，后期一样可以改成微服务。

---

2024.12.28

writeby kaiven