微服务架构热度已过：从狂热到理性的架构选型之路

更多问题讨论和资料获取，请关注文章最后的微信公众号

引言

还记得几年前吗？微服务简直是技术圈的"当红炸子鸡"。不管什么项目，上来就先选微服务架构，好像不用就显得自己技术栈落后、不够专业。

但最近这两年，风向变了。越来越多的团队开始重新审视单体架构的价值。这不是技术倒退，而是大家终于想明白了------架构选型不能跟风，得看实际需求。

ThoughtWorks 在 2020 年的技术雷达里就明确提出：不要从微服务开始 $23$ 。这个建议，现在看来真是说到点子上了。

微服务热潮的兴起与现状

曾经的狂热

2015 年到 2019 年那会儿，微服务真的是火得一塌糊涂。Spring Cloud、Dubbo 这些框架大行其道，Netflix、阿里巴巴的成功案例被到处传播。一时间，微服务仿佛成了包治百病的神药：

业务解耦，每个服务独立开发部署
技术栈随便选，想用什么用什么
弹性扩展，哪里不够扩哪里
团队自治，各管各的

在这种氛围下，连很多小项目、个人项目都跃跃欲试，觉得不用微服务就 out 了。

Martin Fowler 在 2014 年发表的文章《Microservices》 $1$ 算是奠基之作。他当时就提醒过：微服务不是银弹，它带来了分布式系统的所有复杂性。可惜那时候大家都在追热度，这话没多少人听进去。

看看 Netflix，人家确实把微服务做成功了。但你得想想，人家有多少用户？全球数亿用户啊！而且 Netflix 的 DevOps 能力也是顶级的。Netflix 的技术博客 $2$ 详细记录了这一过程，成为业界学习的标杆。这种成功案例，对大多数团队来说，看看就好，真要学，得先问问自己有没有那个条件。

当前的冷静

等到真正落地实践了，很多团队才发现事情没那么简单：

分布式系统的复杂性，不是说着玩的
运维压力陡增，得搭一套完整的基础设施
服务之间调用，网络开销不小
调试起来特别费劲，调用链路追踪是个麻烦事
分布式事务？那更是个坑

这些问题暴露出来后，大家开始反思：我们真的需要微服务吗？

有篇论文专门研究了这个问题，《To Microservices or Not to Microservices?》 $3$ ，结论挺有意思：微服务带来的好处，在很多场景下被它引发的问题抵消了。建议团队在决定前，先好好做个成本收益分析。

有个概念叫"分布式单体"（Distributed Monolith），由前 Google 工程师 Steve Yegge 在 2017 年提出 $4$ ，说的是那种盲目拆分微服务的结果------既没有真正解耦，又摊上了分布式系统的所有麻烦。这可不是危言耸听，真有不少项目踩了这个坑。

回归单体架构的原因

1. 大多数项目规模有限

现实很骨感------绝大多数项目，根本不需要微服务：

日活几千到几万，这已经是大多数项目的水平了
团队规模？3-10 个人的团队最常见
业务复杂度？大部分场景用模块化单体就能搞定
发布频率？两周一次就够呛了

根据 Stack Overflow 2023 年开发者调查报告 $5$ ，超过 70% 的开发者在 50 人以下的团队，80% 的项目用户规模在 10 万以下。这些数据说明什么？大多数项目压根不需要微服务的分布式能力。

Martin Fowler 在《MonolithFirst》 $6$ 文章中早就说过：几乎任何从零开始构建系统的项目，都应该从单体架构开始。只有当系统真的够复杂、团队真的够大了，再考虑拆分。这话现在看来，真是太对了。

2. 微服务的隐藏成本被低估

当时大家只看到了好处，没看到背后的一堆成本。

基础设施成本

得搭这些东西：

服务注册与发现（比如 Nacos、Consul）
配置中心
API 网关
链路追踪系统
日志聚合平台
监控告警系统

开发维护成本

这些事也跑不了：

服务间通信协议怎么设计？
接口版本怎么管理？
分布式事务怎么处理？
服务降级、熔断怎么搞？
数据一致性怎么保障？

这些成本，在小型项目里往往得不偿失。

Google 工程师 Jeffrey Dean 和 Luiz André Barroso 在论文《The Tail at Scale》 $7$ 中专门分析了分布式系统的尾延迟问题。他们指出：在分布式系统里，一个慢请求会拖慢整个系统。这在微服务架构里尤其明显。

Uber 在其技术博客 $8$ 中也分享过他们的经验------管理数千个微服务需要投入大量工程资源。他们达到那个规模，投入才值得。规模不够的团队，这笔账算不过来。

还有篇论文《Microservices: Yesterday, Today, and Tomorrow》 $9$ 说得更直白：微服务架构想成功，得有三个前提------快速部署基础设施、完善的监控体系、成熟的团队组织。缺一个，微服务都可能变成负担。

3. 单体架构的演进

现在的单体架构可不是以前那种"大泥球"了，已经进化了不少：

模块化设计，边界清晰
分层架构，职责分明
用 DDD 思想做领域划分
插件化扩展
Docker 容器化部署

这种"模块化单体"，既简单又好维护。很多人可能不知道，DDD（领域驱动设计）最早就是用来解决单体架构的复杂度问题的。Eric Evans 在《领域驱动设计》 $10$ 一书中提出，通过限界上下文（Bounded Context）划分，单体应用内部也能保持清晰的业务边界，未来真要拆分服务也容易。

《Building Microservices》 $11$ 这本书的作者 Sam Newman 说过：微服务架构不应该成为默认选择。他建议用"绞杀者模式"（Strangler Pattern），渐进式地从单体演进到微服务。也就是说，别上来就拆，等项目真的需要了再拆。

微服务架构并未过时

得说明白一点：微服务热度下降不等于它过时了。正好相反，这说明大家对微服务的认识更成熟了。

微服务的适用场景

微服务依然有它的价值，但得用在合适的地方。

超大规模系统

用户量百万、千万级别
业务领域复杂，模块边界清晰
团队规模庞大（50+开发人员）
业务模块需要独立迭代

典型场景

电商平台（用户、商品、订单、支付等服务）
社交应用（用户、消息、动态、推荐等服务）
金融系统（账户、交易、风控、清算等服务）

像淘宝、支付宝、微信这些，用微服务是合适的。但问题是，你做的项目，真有这个规模吗？

技术演进的必然规律

任何技术都会经历"Gartner技术成熟度曲线"：

技术萌芽期：新技术出现，引发关注
期望膨胀期：过度宣传，期望过高
泡沫破裂低谷期：问题暴露，热度下降
稳步爬升恢复期：理性认识，逐步成熟
生产成熟期：广泛应用，成为主流

微服务正在从第2阶段走向第4阶段，这是技术走向成熟的标志，不是过时的征兆。

根据场景选择架构

架构选型的原则

1. 简单优先

能用简单方案解决的问题，绝不使用复杂方案。架构设计的首要目标是解决问题，不是炫技。

Robert C. Martin 在《架构整洁之道》 $12$ 这本书里说得好：软件架构的首要目标是降低构建和维护系统的成本。过度复杂的架构，恰恰相反。

还有个 KISS 原则（Keep It Simple, Stupid），简单的设计往往比复杂的设计更可靠、更好维护。这个原则虽然听着简单，但真做起来不容易，尤其是当你手头有一堆新技术想尝试的时候。

2. 演进式架构

架构应该随着业务发展而演进，别想着一步到位。不要试图预测未来的所有需求。今天的架构解决今天的问题，同时给明天留点空间就行。

Neal Ford 等人在《演进式架构》 $13$ 一书中提出：架构应该是可演进的，应该为未来的变化做好准备，而非试图预测未来。极限编程（XP）创始人 Kent Beck 也说过："先让它工作，再让它正确，最后让它快速。"这话用在架构选型上也合适：先用简单的架构让业务跑起来，再根据实际需求优化和演进。

3. 成本收益平衡

架构选型要权衡收益与成本，选性价比最高的方案。

多项研究表明，微服务架构的开发和维护成本平均比单体架构高出 30%-50%。只有在用户规模、团队规模、业务复杂度达到一定程度时，这些额外成本才能被收益抵消。

Google 在《Software Engineering at Google》 $14$ 这本书里强调：最简单的架构往往是最好的架构，因为它更容易理解和修改。

不同规模的架构选择

给你个简单的参考表：

项目规模	团队人数	用户规模	推荐架构
小型项目	1-5人	<10万	模块化单体
中型项目	5-20人	10-100万	模块化单体或服务化单体
大型项目	20-50人	100-1000万	部分核心业务拆分
超大型项目	50+人	>1000万	微服务架构

架构选型的决策流程

说到底，架构选型就是问自己几个问题：

当前业务规模和复杂度如何？
未来 1-2 年业务会怎么增长？
团队规模和技术能力够不够？
基础设施和运维能力跟得上吗？
成本和收益算过账吗？

这些问题想清楚了，架构选择其实不难。难的是克服"我想用新技术"的冲动。

架构演进之路

从单体到微服务的演进

架构不是一成不变的，应该随着业务发展而演进。一般会经历这几个阶段：

阶段一：单体架构

快速验证业务想法
团队规模小，沟通成本低
部署简单，调试方便
专注业务功能开发

阶段二：模块化单体

业务模块边界清晰
模块间通过接口通信
为未来拆分做准备
团队规模增长

阶段三：服务化单体

核心业务模块独立部署
部分服务拆分出去
引入基础的服务治理能力
团队分工明确

阶段四：微服务架构

业务模块全面拆分
完善的微服务基础设施
团队规模大，独立交付
业务复杂度高

演进的时机

什么时候该拆分了？看这几个信号：

部署冲突频繁，不同模块需要独立发布
扩展瓶颈明显，部分模块需要独立扩展
团队协作困难，团队规模大，协调成本高
业务边界清晰，领域边界已经明确

过早拆分的风险

增加系统复杂度
引入不必要的分布式问题
增加运维负担
降低开发效率

所以，别着急拆，等真有需要了再拆。

案例分析

成功的单体架构案例

Shopify

日处理数十亿请求，起初就是单体架构。后来通过 Ruby on Rails 模块化设计，逐步演进，核心服务还是单体。Shopify 工程团队在《Deconstructing the Monolith》 $15$ 一文中详细描述了这个过程。他们的哲学很简单："能不拆就不拆，必须要拆才拆"。最终也只有少数核心服务被拆分出去。

Stack Overflow

你可能想不到，Stack Overflow 也是单体架构。支撑了每秒数百次请求、每月数十亿 PV 的流量。Stack Overflow 在《Why Stack Overflow Doesn't Use Microservices》 $16$ 一文中明确表示，他们的架构师 Nick Craver 说过："微服务不是性能问题的解决方案，良好的数据库设计、缓存策略和代码优化才是。"

Basecamp

Basecamp 用单体 Rails 应用服务了数百万用户，证明了单体架构完全可行。创始人 DHH（David Heinemeier Hansson）在《重来》 $17$ 这本书里反复强调：简单的架构优于复杂的架构。

从微服务回归单体的案例

Ingenious

这个团队经历了从微服务回归单体的过程。Ingenious 的技术团队在《Goodbye Microservices: From 100s of problem children to 1 superstar》 $18$ 一文中详细记录了这个过程。原因很简单：复杂度过高，团队规模小，撑不住。回归单体后，开发效率提升了 3 倍，部署时间从几小时缩短到几分钟。

Segment

Segment 最初为了解决扩展问题转向微服务，结果发现分布式事务、服务间通信、调试等问题严重影响了开发效率。Segment 的工程团队在《Goodbye Microservices》 $19$ 一文中详细描述了这一历程。最后重构回单体架构，运维负担减少了 90%，工程师终于可以专心写业务逻辑了，不用整天折腾基础设施。

Eventuate

Chris Richardson 是微服务布道者，但他后来也反思：分布式数据管理是微服务架构最大的挑战之一，很多团队低估了这个问题 $20$ 。在业务边界不清晰、数据一致性要求高的场景下，单体架构反而更务实。

个人实践案例：医疗项目的架构选型反思

说个我自己的亲身经历，可能更能说明问题。

项目背景

技术栈：基于 pigx 微服务框架开发
业务领域：医疗管理系统
架构选择：微服务架构（用户服务、权限服务、医疗业务服务等）
团队规模：5-8 人

实际问题

上线后几年内，实际使用用户量很少，根本不需要分布式架构。但微服务架构需要部署注册中心、配置中心、网关、多个业务服务等组件，资源占用大。

为了节省云服务器成本，我们将所有微服务组件都部署到了同一台服务器上。

矛盾与代价

这种"伪微服务"架构带来的问题很严重：

违背了微服务的初衷------微服务强调独立部署、独立扩展，但所有服务挤在一台服务器上，完全丧失了这些优势
维护成本增加：
- 要维护 Nacos 注册中心、Sentinel 熔断器、Gateway 网关等基础设施
- 服务间调用要经过网络通信，排查问题更难了
- 日志分散在多个服务里，调试时得在多个服务间跳转
资源占用依然高------即使部署在一台服务器上，多个 JVM 实例、数据库连接池、基础设施组件依然占用大量内存
开发效率低------每次启动要等好几个服务依次启动，本地开发调试特别耗时

反思与改进

项目后期，我们深刻认识到：

架构选型失误：医疗项目的用户规模、业务复杂度完全不需要微服务架构
过度设计：为了"技术先进"而选择了微服务，但实际收益为零
成本倒挂：维护成本远超单体架构，却没获得任何收益

最终，我们计划将项目重构为单体架构，预计可以：

减少 60% 以上的服务器资源占用
降低 70% 的维护成本
提升 50% 以上的开发调试效率
部署流程从"部署 10+ 个服务"变为"部署 1 个应用"

这次经历让我深刻认识到：架构选型必须基于实际需求，不能跟风。一个日活几百用户的系统，用单体架构完全够用。为了"微服务"而微服务，只会给自己找麻烦。

最佳实践建议

对于新项目

从单体开始，别想太多
模块化设计，按领域边界组织
保持架构层次清晰
为未来拆分预留接口抽象
持续重构，保持代码质量

对于已有项目

理性评估当前架构的问题
找出真正的痛点
渐进式改进，别搞大规模重构
适时拆分，识别需要独立的服务
完善基础设施，为拆分做好准备

团队能力建设

基础能力

代码设计与重构
数据库设计与优化
测试与持续集成

进阶能力

领域驱动设计（DDD）
分布式系统设计
服务治理与监控

决策能力

架构评估
技术选型
演进规划

说到底，架构能力不是一天两天能练出来的，需要在实践中不断积累。

总结

微服务架构热度下降，反映的是行业认知的成熟。大家不再盲目追风，而是理性地认识到：

架构选型没有银弹------每种架构都有其适用场景
简单是最高级的复杂------能用简单方案解决的问题，就不需要复杂方案
架构应该服务于业务------而不是业务迁就架构
演进式架构才是正道------根据业务发展逐步演进

Martin Fowler 说过："You must be this tall to use microservices."（你必须达到这个高度才能使用微服务）

这句话的意思很明确：使用微服务需要相应的团队规模、技术能力和基础设施支持。条件不成熟时，单体架构往往是更明智的选择。

Martin Abbott 和 Michael Fisher 在《扩展的艺术》 $21$ 这本书里提出了"扩展立方体"（Scaling Cube）模型，说系统扩展有多种维度，微服务只是其中一种方式。选择架构时，应该根据业务需求和团队能力，选择最合适的方式，而非盲目追求最先进的技术。

论文《Microservices: A Systematic Mapping Study》 $22$ 对 2014-2017 年间发表的 103 篇微服务相关论文做了系统性综述。研究发现，微服务架构的主要挑战包括：数据一致性（占 36%）、服务发现与通信（占 28%）、测试与部署（占 22%）。论文建议团队在采用微服务前，必须确保具备应对这些挑战的能力。

微服务没有过时，它依然是一种重要的架构模式。只是我们现在更清楚：架构的本质是权衡，是在特定约束条件下做出最优选择，而非盲目追求所谓的"先进技术"。

让我们回归理性，根据实际场景选择最适合的架构。这才是成熟技术团队应有的态度。

参考文献

$1$ Martin Fowler & James Lewis. "Microservices: a definition of this new architectural term". martinfowler.com, 2014.

$2$ Netflix Technology Blog. Netflix 微服务架构实践系列文章. medium.com/netflix-techblog

$3$ Amirhossein Vakilzadeh et al. "To Microservices or Not to Microservices?". IEEE International Conference on Software Architecture, 2018.

$4$ Steve Yegge. "Platforms". steve-yegge.blogspot.com, 2017.

$5$ Stack Overflow. "Developer Survey Results 2023". survey.stackoverflow.co, 2023.

$6$ Martin Fowler. "MonolithFirst". martinfowler.com, 2015.

$7$ Jeffrey Dean, Luiz André Barroso. "The Tail at Scale". Communications of the ACM, 2013.

$8$ Uber Engineering. "Why We Switched from Mesos to Kubernetes". eng.uber.com

$9$ Nicola Dragoni et al. "Microservices: Yesterday, Today, and Tomorrow". Springer, 2019.

$10$ Eric Evans. 《领域驱动设计：软件核心复杂性应对之道》. Addison-Wesley, 2003.

$11$ Sam Newman. 《Building Microservices: Designing Fine-Grained Systems》. O'Reilly Media, 2014.

$12$ Robert C. Martin. 《架构整洁之道》. Prentice Hall, 2017.

$13$ Neal Ford, Rebecca Parsons, Patrick Kua. 《Building Evolutionary Architectures》. O'Reilly Media, 2017.

$14$ Titus Winters, Tom Manshreck, Hyrum Wright. 《Software Engineering at Google》. O'Reilly Media, 2020.

$15$ Shopify Engineering. "Deconstructing the Monolith: How We Broke Down Our Massive Rails App". shopify.engineering, 2019.

$16$ Stack Overflow Blog. "Why Stack Overflow Doesn't Use Microservices". stackoverflow.blog, 2015.

$17$ David Heinemeier Hansson. 《重来：更为简单有效的商业思维》. 中信出版社, 2010.

$18$ Ingenious. "Goodbye Microservices: From 100s of problem children to 1 superstar". ingenious.net, 2018.

$19$ Segment Blog. "Goodbye Microservices". segment.com, 2020.

$20$ Chris Richardson. Eventuate 关于微服务数据一致性的系列文章. eventuate.io

$21$ Martin Abbott, Michael Fisher. 《The Art of Scalability》. Addison-Wesley, 2009.

$22$ Paulo Pereira et al. "Microservices: A Systematic Mapping Study". Journal of Systems and Software, 2017.

$23$ ThoughtWorks. "Technology Radar Vol. 21". thoughtworks.com, 2020.