好的架构,不一定是增加组件,而是敢于删除组件
📅 2026/7/22 6:49:52
👁️ 阅读次数
📝 编程学习
经验丰富其厉害的程序员,还有一项本事,就是知道哪些东西暂时可以不用,以便降低系统的复杂度。
很多项目发展一段时间后,总喜欢不断往里面加组件。比如:
觉得 MySQL 慢,就上 Redis。
觉得要异步,就搞 MQ。
觉得以后可能有很多规则,就先上规则引擎。
其还得意的认为,每加一个组件,是在提升架构。实际上,也是在增加系统复杂度。
比如有些业务,访问量并不高,MySQL 完全能扛住,你却还是加了一层 Redis。你有大把的优化手段去优化sql的。
虽然缓存确实减轻了数据库压力,但新的问题马上就来了:缓存什么时候更新?先删缓存还是先更新数据库?为了维护缓存和数据库的一致性,又写了一大堆代码。
再比如,一个系统本来就只有一个服务,部分程序员居然把异步任务全部丢到 MQ。
结果多了一套 Broker,多了一套运维,多了一套监控,还要处理消息重复、消息丢失、消息积压、消费失败重试等问题。
其实,如果只是为了异步执行,线程池就够了。而Spring 自带的事件发布订阅机制,也完全可以满足很多场景。
并不是所有异步,都值得引入 MQ。
我这边是不允许技术部的程序员随意引入新的组件的,那是一个架构的问题,怎么可以随意引入呢? 我是卡的非常严格的。
但凡用其他技术手段能解决的,就不引入新的组件。依赖越多,系统复杂性越高。
软件架构,本质上是在管理复杂度,请记住这句话。
增加一个组件是很容易的,删除一个组件却需要经验和判断。
好的架构的其中一个特点,就是依赖越来越少,系统越来越简单。
编程学习
技术分享
实战经验