不是所有系统都得上微服务——一套"复古"架构的务实选择

这两年技术圈有个风气，新项目不管三七二十一先上微服务，好像不用Spring Cloud、不上K8s就不配做架构似的。

我今天说一个真实案例，一套完全没有微服务的架构，跑了几年，稳如老狗——它不先进、不潮流，却精准匹配业务，用最低的成本实现了最高的稳定性，这正是工程思维的核心体现。

一、业务场景：没有极端需求，只有典型特征

这是一套普通的政务系统，没有复杂的业务逻辑，也没有极端的流量压力，却极具代表性——它的业务特征，几乎覆盖了80%的常规业务系统（包括多数电商后台、OA系统、审批系统）。

核心特征十分明确：

• 读写比典型：8:1读写比，浏览操作占绝对主导，写入操作频次低、压力小；

• 用户与并发适中：用户量不大不小，并发不高不低，既不是12306那种高并发场景，也不是仅供几人使用的内部小工具，属于“中等体量”的常规需求。

二、架构全貌：没有花里胡哨，只有够用就好

这套架构的组成极其简单，甚至可以用“朴素”来形容，没有任何当下流行的技术组件，却构成了稳定运行的闭环：

• 入口层：F5负载均衡，承担请求分发，保障入口稳定性；

• 应用层：4台应用服务器，满足并发需求，预留冗余空间；

• 数据层：关系数据库，依托自身缓存机制，提升查询效率；

• 存储层：RAID 5阵列 + 10000转机械硬盘，兼顾读取速度与空间利用率；

• 运维层：基础报警 + 定期巡检，人工查看监控，无复杂自动化工具。

没有网关、没有服务注册发现、没有容器编排、没有配置中心——放在今天的技术选型评审会上，这套架构大概率会被批得体无完肤，“太老了”“没有弹性伸缩”“没有服务治理”的质疑会接踵而至。

但事实是：它跑得非常好，稳定运行数年，几乎没有出现过宕机事故，完全满足政务系统的核心需求。

三、为什么稳？吃透业务，精准匹配

这套架构的稳定性，从来不是“运气好”，而是精准吃透了业务特征，每一个选型都贴合实际需求，没有多余的设计，也没有短板漏洞，这正是务实架构的核心价值所在。

• RAID 5的选型：8:1读写比意味着磁盘读取是绝对主力，而RAID 5的核心优势就是并行读取速度快，同时磁盘空间利用率远高于RAID 1，完美匹配“读多写少”的业务规律，不浪费资源也不出现瓶颈；

• 数据库缓存的价值：数据库配置了共享内存，对于高频重复的SQL查询，缓存命中率极高，大幅提升执行效率，减少磁盘I/O压力；

• 机械硬盘的合理性：10000转机械硬盘确实不如全闪存，但结合8:1的读写比，再加上数据库缓存、应用缓存的双重加持，磁盘I/O根本不会成为系统瓶颈，用机械硬盘的成本，实现了满足需求的性能；

• 4台应用服务器的冗余：对当前并发量而言，4台服务器确实属于“杀鸡用牛刀”，但政务系统的核心诉求是“稳”——硬件成本远低于人力成本，多一台服务器的冗余，远比出现一次宕机事故更划算，这是对“稳”的务实妥协。

四、运维哲学：务实容错，不搞过度复杂

这套系统的运维逻辑，和它的架构一样“朴素”，却异常有效，核心态度只有一句话：黄灯不处理，等死。

没有复杂的自动化运维平台，没有AIOps智能监控，核心运维动作只有两个：有报警就及时查看，有预警就立即排查，小问题不拖延、不积累，避免拖成大事故——比如磁盘出现黄灯预警，人工直接去机房更换，简单、高效、直接。

但必须明确：这种运维策略有一个核心前提——这套系统不是民生系统。

如果是社保、医保、水电煤这类24小时不能停的民生系统，必须24小时专人值守，宕机就是重大事故；但多数政务系统没有这么高的可用性要求，容错空间较大，无需投入高昂的自动化运维成本，简单的人工巡检就足以保障稳定。

五、澄清误区：不是微服务不好，是场景不对

我始终不否定微服务的价值，它确实解决了很多实际问题，但它不是“万能药”，更不是“面子工程”——微服务的价值，只有在特定场景下才能体现，脱离场景的微服务，只会徒增复杂度。

以下4种场景，上微服务才是合理的选择，也是微服务真正能发挥价值的地方：

• 团队规模大：几十号人同时维护一个代码库，频繁出现代码冲突、协作困难，需要拆分模块、独立维护；

• 模块需独立演进：不同模块迭代节奏差异大，比如支付模块一天发3次版，用户模块一个月发1次版，需要独立部署、互不影响；

• 流量差异极大：部分接口需要扛10万QPS的高压力，而其他接口仅需承载100 QPS，需要针对性扩容、按需分配资源；

• 技术栈多样：不同模块需要适配不同技术栈，比如推荐引擎用Python，核心交易用Java，需要跨技术栈整合。

但很多项目根本不满足这些条件：团队只有三五个人，流量稳定且不大，模块之间耦合度低，一个war包部署上去，就能稳稳当当跑几年。

这种情况下强行上微服务，得到的只有无尽的复杂度：部署难度翻10倍、运维成本翻10倍，问题排查从“单台机器”变成“整条调用链”，新人入职半个月都搞不清系统结构——得到的全是复杂度，失去的全是简单性，完全得不偿失。

六、核心结论：技术选型的本质，是匹配场景

技术选型从来没有“先进”与“落后”之分，只有“合适”与“不合适”之别，核心原则只有一个：匹配场景。

不同场景，对应不同的最优解，无需被技术潮流裹挟：

• 高并发、大流量、大团队 → 微服务、容器化、自动化运维，用复杂架构解决复杂问题；

• 中等流量、小团队、业务稳定 → 单体架构或简单集群，够用就好，兼顾效率与成本；

• 政务内网、用户量小、核心求稳 → “复古”架构反而是最优解，简单、可靠、低成本。

新技术的价值，是解决“新问题”；如果你的问题的是常规问题、老问题，用成熟的老技术就足够了。

能用简单方案解决的问题，就不要用复杂方案去解决——这不是保守，而是最务实的工程思维。

那套F5 + RAID 5 + 数据库缓存的“复古”架构，没有前沿技术的加持，却精准匹配业务需求，既好用又省钱，完美诠释了“务实”二字。

有时候，最好的架构决策就是——不做多余的架构决策。