微服务是不是一种错误的方向？

[Joker123456789]

先说想法

这个标题并非一时兴起，也并非哗众取宠，而是我这段时间以来的思考。为什么会出现这样的想法？这还得从一个事实说起。

众所周知，微服务并不能提升整个项目的吞吐量，它的作用仅仅只是把项目按照一定的规则拆分成各种模块，然后每个模块都可以交给不同小组去开发。他解决的仅仅是大项目的团队协作问题。而真正能提升吞吐量的，除了程序本身的质量那就是负载均衡了，而且事实上微服务的架构中，每个服务都是以负载均衡的形式部署的，所以这里就有一个问题了：

如果仅仅是为了解决 [大项目的团队协作问题] 那么常规的模块化设计是不是也能做到？

现在由于 maven 的出现，再加上企业内部可以搭建私服，我们完全可以让每一个服务都以 jar 包的形式来开发。举个很简单的一个例子，比如有一个用户服务，订单服务，现在一般的做法是写一个聚合服务去调用这两个服务的接口，来实现业务逻辑的整合。

那如果把用户服务换成用户模块 jar 包、订单服务换成订单模块 jar 包，以 jar 包的形似传到私服，然后同样的写一个聚合服务，聚合服务把这两个 jar 包引入进来，是不是也能达到这样的效果？

如果需要负载均衡，那我们把这个聚合服务部署多个就好了，完全不影响。我完全想不到跟微服务比起来有什么坏处，如果有，欢迎大家指正。

微服务有什么缺点

1. 耦合性太高，虽然开发和部署不会影响别的服务，但是你如果动了接口的出入参，那么其他服务就得同步升级了，而且是调用了这个接口的服务都要升级，又或者你需要为此单拎一个接口出来，做版本区分。
2. 需要注册中心，项目会多出一个中间件，提升复杂度。
3. 会消耗内网带宽，甚至是公网带宽，因为服务之间的调用都是通过网络完成的。
4. 会出现分布式事务的问题，因为一个事务的操作可能会分布在不同的服务上执行。

如果用常规的模块化方案

1. 虽然耦合也高，但是如果你动了接口的出入参甚至是接口名，别的服务是不需要立刻升级的，除非你是在改 bug ，但这是被业务逼着升级，因为不升级是有 bug 的，但他不会被技术逼得升级，因为模块只是被打成了一个 jar 包引入了其他模块里，无论你怎么变，已经部署在线上的别的模块里依然是用的你的老代码。
2. 不需要注册中心
3. 不会消耗多余的带宽资源
4. 不需要分布式事务了

还是压力问题

一定会有人说，你把这么多模块都塞进一个服务里，那这个服务得部署多少台机器啊。

说到这里，就不得不从全局来看待问题了。我们可以看两张图（不好意思，有错别字，但是已经截图了就懒得改了，能看懂就行）

图 1

图 2

根据上面的两个图，我们是不是可以这么说，微服务在面对相同的流量时根本没有节约服务器的数量？反而还多了？

假如左边的聚合服务，他的业务量需要 10 台服务器才能支撑，右边的需要 5 台才能支撑，那么一共是 15 台。而微服务会导致 A 部署 15 台，B 也部署 15 台，再加上两个聚合服务，一共需要 32 台以上。

当然了，这只是极端的情况，现实中可能 A 服务不需要处理这么多业务，他可以少部署一点，又或者 B 服务可以少部署一点。但无论怎么算，服务器都是多了。

如果采用 jar 包的形式，那么只需要 15 台就够了，10 台用来部署左边的聚合服务，5 台用来部署右边的聚合服务。

说到底

这其实就是以三方库的思想在设计模块化，如果有一个工具类叫用户管理，有一个工具类叫支付管理。当你需要开发登录功能的时候，只需要引入一个 jar 包，然后调用里面的某个方法就好了，当你需要开发支付功能的时候也一样，你不需要去学习 dubbo ，不需要去学习 springcloud ，甚至不需要去关注注册中心是否挂没挂，注册中心的 url 是多少，服务到底有没有正常发布，有没有正常被发现。你会不会觉得这样有什么不妥呢？

以上只是个人的一点浅薄见解，欢迎大家理性探讨。

[hxndg]

槽点有点多。。。。有的观点挺有意思

但是一些其他观点，需要区分架构和技术实现

这些观点包括

- “如果仅仅是为了解决 [大项目的团队协作问题] ”。。。。它不是为了解决大项目的团队协作问题，它是适应了康威定律
- 耦合性太高，这个我理解是抨击提供的是服务。。。这个是微服务必然带来的
- 还有分布式事务。。。这个如果你说是数据去中心化，那确实是问题，但是分布式事务这个是技术

我个人觉得你可以思考自己的观点的时候先尝试证伪自己的观点

推荐
看下 https://martinfowler.com/articles/microservices.html 这个里面的定义

[RightHand]

增加了大量 kpi ，增加了大量人工，增加了大量服务资源。不是吗？？？

[sujin190]

看这说的，别的不说大型项目中更新时单体项目的话需要整体重启的要命性都没体会到，说明你还需要学习，不要质疑别人的智商，别的都不说，大型高负载快速迭代的项目单纯就是为了减少重启范围都值得搞微服务。还不说其他的问题

[sujin190]

而且都不需要多高的 qps ，估计超过 100qps ，三天两头动不动全体重启所产生的不可预测异常，所产生的损失就足够老板重视了，否则你需要多复杂的重启更新流程来弄，每次重启手都得抖吧

[Joker123456789]

@sujin190 重启一个单体项目 跟 重启一个服务，区别没那么大吧？单体项目跟一个服务从技术层面来说不都一个单体项目？只不过从架构上来说一个是服务，一个是单体项目。

假如淘宝的订单服务需要重启，重启期间如果不采取一些措施，那么这段时间所有用户一样下不了单，只不过是能登录能浏览。话又说回来，既然重启一个服务时可以采取措施，让流量暂时往其他节点跑，那么单体项目也可以这么干啊，不需要整体停服。

[june4]

@Joker123456789 如果一些遗留服务只要维护不需要再投入成本和升级依赖，另一个核心服务需要不断维护并跟上最新框架，你搞成单体的不太方便吧

[est]

你打工的话，微服务提供更多就业岗位

你外包接业务的话，微服务比单体可以让甲方掏更多钱

你解决问题的话，微服务本身带来更多问题

你指挥好几个组的话，微服务如果拆分恰当，可以提高协作效率。

主要看你屁股在哪里。

[Joker123456789]

@june4 确实是个问题

[povsister]

究其根本原因：你没有遇到足够大规模的业务而已，见了太多为了微服务而微服务的做法感觉有些“不过如此”的体验。

你可以猜测一下字节跳动的容器数量

[jayin]

主要矛盾是随着系统越来越大，有了业务解耦的需求，把大系统抽象成模块（服务），提升开发体验的，方便找到出系统瓶颈。

至于微服务的实现是 HTTP 、grpc,甚至是 jar 包 都没问题，取决于你怎么去划分业务，没有绝对正确，跟业务需求匹配就好了。

以前还有一个老东西——SOA ，也是面向服务架构，只是以过去系统规模，把单一的支付系统归为一个大的服务，现在有了微服务，再细化，把支付拆分成微信支付服务，支付宝服务，银联支付服务等。

至于分成支付系统服务，还是多个渠道支付服务拆分，都是没错的。业务的发展进度不同，都是合理的。

[hangszhang]

组织架构决定系统架构，并不完全是项目大不大来决定的

[fcten]

本来我维护一个没什么流量的小业务，重新部署 10 台机器就够了。现在你这么搞，我改一行代码就得重新部署一万台服务器。
本来这个服务 4c8g 的容器就够了，现在你这么搞，我直接上物理机也不够啊，天知道几千万行代码里哪些天杀的业务吃完了内存。
本来这个服务只有我们两三个人改，想什么时候发布就什么时候发布。现在你这么搞，每次发布前面排着几百个发布单，一个月才能发布成功一次。万一再出个故障要回滚代码，那真是画面太美我不敢看。。

啥，整个业务总用才用了不到 100 核？那你上什么微服务嘛……

[R4rvZ6agNVWr56V0]

脱离 Java ，在异构世界中会有更广大的视野。例如规模较大的团队把 Java 、Python 、Golang 不同的系统串起来…
而且，重点是为了解决康威定律带来的组织效率问题（大部分企业的沟通成本和协作效率的成本远大于设备的开支），如 1 楼所述。而为了微服务而实施微服务，这是一种本末倒置了。

[quan7u]

我工作一两年经验的时候也思考过类似问题，也是接触到更大的项目、流量才有了实际的改观
1 、微服务本身就是模块化方案：相比单体，协作（功能设计、代码开发）、运维（版本、发布、监控）都更敏捷
2 、服务健壮性：单体一旦引入了内存溢出、死循环等问题，直接影响整个服务
3 、压力：（图挂了看文字描述不太理解）单体项目一旦过于庞大，如何做压力评估？哪些模块需要支持多少 qps ？出现某个模块压力，单体只能扩充一台实例
4 、。。。

[dcoder]

简单说，idea 不是错误的方向. 因为最后是个大的分布式系统，每个服务独立出来开发调优挺好的.
但是用 k8s, docker, Java 这些 bloat 垃圾来做，就是实现上太差劲了而已

[xuanbg]

OP 你说的 4 个缺点，只有 2 是微服务的问题。但多个注册中心算什么问题？你还需要多个网关、多个链路追踪组件呢。多出这些就增加系统复杂度了？不，对于开发来说，一点复杂度都没增加。因为这些基础设施不需要你去维护，你只管用一行代码调用就行了。

至于其他 3 个问题，都是人的问题而非微服务的问题。算了，我还是老观点：不会封装和不会自动化运维的，老老实实玩单体就好。微服务肯定要比单体先进，自己没这个本事玩微服务就别玩，不要把锅甩给微服务。

[wupher]

看具体应用场景

DHH 16 年就发表过类似观点，好像是叫 Majestic Monolitch 吧。可以搜搜看。

适合你当前需要的，就是最好的。

[coderzhangsan]

说个题外话：社会环境和人情文化->企业文化->技术文化，理论要结合实际，现在 JAVA 八股文和技术栈基本都是微服务那套东西，这样的技术环境下 IT 从业者也会围绕这套东西来，但我相信大多数人了解实际，也知道如何做才能结合实际，但是在这样的企业文化下，这么做对己对团队没有太大好处，所以既然是为了自己和团队，以围绕 KPI 建设企业文化下，当然是盘子越大越好，至于装不装下那么多饭，那是另外一回事了。

[riluolvshe]

@Joker123456789 微服务架构下有负载均衡，可以按先后顺序重启。

[zoharSoul]

经验太少

[micean]

从一个极端到另一个极端……

[kneo]

绝大多数使用微服务的项目规模，都远远小于 Windows ，Chrome 。不存在一定要微服务。只能说，微服务有很多明显的优势，让它一度很流行。随便举几个：

1. 团队分工明确，接口测试明确。
2. 责任明确。如果一个服务挂了，可以迅速定位相关的团队。
3. 热更新方便。
4. 整体的运行性能（性价比）会降低，但是更容易 scale 。
5. 可以使用不同语言开发。团队有自主权。
6. 互相无编译依赖，无运行库依赖，配合容器部署，在很大程度上可以解决 dll/so/jar 冲突问题。

微服务的问题在于后来机械化，搞得太微了，一个团队负责好几个微服务，微服务互相直接也有依赖，也存在版本问题。部署和调试也成了地狱。你搞的不微别人还说你不正宗。

具体上不上微服务还是看自己团队和项目。自己爽不爽自己心里有数。不爽就别硬上。

[lesismal]

多数人都不懂的一切从实际出发，即使背会了八股、实际工程中还是不擅长运用。
微服务只是一种架构设计和工程实践方案，关键是适不适合用、怎么用、用的对不对。

2015 年左右微服务刚开始要兴起的时候，我在好多技术群里喷那些无脑微服务的人，注意，是喷那些无脑微服务的人而不是喷微服务本身。
早年没有微服务的时候就有分布式，是更广义的概念，微服务被 web 领域的人把分布式更加领域细分并且搞了一大坨以 web 领域为主的基础设施。但其实游戏行业大型游戏系统很早就用分布式，只是游戏技术没有 web http 这些相对统一的协议和技术栈、而多是一家公司一套框架，所以游戏行业的技术相对 web 领域而言像是一盘散沙，也难成固定流派，开源的游戏服务器架构没几个好用的。

整天在那纠结这个概念那个概念，从来没去思考下这个方案与实际工程结合是否合理，你们 95-99%的人都错了。

好的现象是，一些大厂团队和一些老鸟逐渐开始清醒，但也是局限于实践中的那些好坏的点才后知后觉，但如果懂得思考，这些很多坑都是可以提前预见的。
软件工程领域，绝大多数所谓的架构师最大缺点，就是没有像土木建筑数学等领域，去做更详细的建模、图纸设计之类的，只知道 tmd 跟风只知道画点漂亮的所谓架构图甚至 ppt 忽悠老板，但凡知道思考实际的事情、这些大多问题、不是指所有问题，而是排除掉高精尖难度大的那部分，因为现实工程中绝大部份问题都是普通问题，其实都是可以像幼儿园搭积木一样，提前摆弄摆弄就清晰了。

只背八股，不思考工程实践，写再多文章都是误人误己。

[cp19890714]

“微服务”这个名字只是表象，本质上是要根据实际的业务架构和业务需求，给出合适的技术架构。
你要是不想“微”，你可以不“微”啊，服务化就行了。
现在这个情况，明明是人的问题，你却说是技术的问题。

[jay0726]

我们一个部门 11 个后端开发，后端服务就有 100 多个，维护起来真的是灾难。

[sujin190]

@Joker123456789 你去问问淘宝，谁会给你什么额外措施，随时重启且不中断不出现异常不出现是所有互联网业务的基本要求好吧，而且更主要的一个问题是稍微大一点的业务流程都很长，可能数百步，可能需要执行很久，任何时刻都有未完全结束的流程在执行，重启不会产生不能完成或者未知状态的流程也是基本要求，服务器不是客户端，重启只会制造异常

[encro]

看看我的需求：

1 ，解决耦合度增加导致的复杂度增加的问题，采用微服务可以物理隔离各类模块的联系。
2 ，微服务后可以按模块部署，更容易按需迭代扩容。

从维护角度分析：
复杂度管理：微服务虽然看起来更多了，但是出问题的时候就更容易定位了。
水平扩展性：性能问题更容易定位，也更容易扩展。


从写代码角度管理：
写代码时由于粒度更小，更加容易写出稳定，可测试的代码。
开始项目前必须考虑通信，性能等因素，进一步要求先设计后编码，有利于提高代码质量。


为什么要微服务？回到第一性原理回答：

1 ，因为人的脑袋存储和 cpu 不够大，不能同时装下那么多模块的逻辑；
2 ，因为一台或者几台机器不够，不能同时运行这么多服务；
3 ，因为我们需要保证服务的不间断运行。


为了看看我的答案怎么样，我问了下 deepseek r1：为什么要微服务？用第一性原理回答

结果还好，无明显遗漏。。。

[249239432]

微服务这技术没错，最烦那些一天没几个人访问的也要硬上微服务

还有一个硬上微服务的场景就是，投标的时候，你没有微服务，你就比那些用了微服务的得分低

[julyclyde]

微服务（化）是手段而不是目标
问题是你需要找到目标

[xiaohusky]

我试过 20 几号人维护一个单体屎山，那确实是噩梦

[opengps]

微服务是为了大型服务端架构，进行进一步拆分，来分解服务端压力的，用不到那么大的架构根本没必要折腾微服务

[mark2025]

耦合性太高，虽然开发和部署不会影响别的服务，但是你如果动了接口的出入参，那么其他服务就得同步升级了
=======
单体服务不也一样么，改动接口参数，相关下游调用方都得同步修改（不管是项目内部还是外部）。

[encro]

@mark2025

还是有不通的，单体服务你不知道这个接口别人用了没有，界限是模糊的。
而微服务你已经明确定义了哪些是外部的，哪些是内部的。你动内部的，是没有问题的，你动外部的，你需要做兼容处理，或者增加一个新的接口，或者发布一个新的版本。

[aliveyang]

什么都引入工具放你本地，你本地放得下吗？

[lujiaxing]

不能说是错误方向。
微服务是解决团队大型化的必然方向。一个上百人的团队，去维护一个项目，别的不说光解决冲突都要解决好久。

但是好多公司做错了。一个只有几个人的团队硬去搞什么微服务。这才是需要修正的。

[zjsxwc]

那么问题来，
楼上说的 java 微服务架构的优点，serverless 全都具备，而且 serverless 还有运维方便、伸缩方便、部署成本价格低等优点，

为何不直接用 serverless 代替 java 的微服务架构？

[fcten]

@zjsxwc
serverless 资源隔离性差，核心场景为了稳定性往往不得不独立部署，这些优点就基本都没了
非核心场景倒是可以直接往上放，但是作为开发也不想整两套技术栈啊
另外 serverless 开发运维方便了，问题排查要麻烦的多

最后还是只有小团队会选择

[CasualYours]

微服务架构中核心对象是服务，因为服务间的解耦，可以轻松实现不同服务的区分对待。
比如在业务高峰期时，订单服务往往比用户服务承担更多流量，微服务架构可以指定仅对订单服务进行扩容。基于容器，可以根据业务场景，动态变换不同服务间的资源配置。

可以微服务架构是提高了系统负载能力的上限，但对应的维护成本，性能问题，部署成本都是需要权衡的因素。

[521jx123OvO]

不能为了微服务而去微服务，应该是项目的体量现行架构不足以承载了，再去考虑微服务。主要是前几年大家都在跟风做微服务，然后在现行的降本增效趋势下进行退微服务化。

微服务是为了解决一些问题，但是会产生新的问题。

最后，软件工程架构没有灵丹妙药。

[agagega]

软件工程是人的工程，软件项目的结构最后会变成开发人员的结构（康威定律）。

所以不同团队维护不同模块，就适合微服务。如果是一个团队，那用微服务就是自讨苦吃。

[dxddd]

“众所周知，微服务并不能提升整个项目的吞吐量”。你这第一段我就不赞同，微服务或者服务化刚开始就是为了提升吞吐量，虽然提升吞吐量，但是牺牲了一定效率并提升了成本。微服务比服务化更近一步的是更细粒度调节。一般程序的吞吐量瓶颈主要就在数据库，原本一个项目依赖一个数据库，现在依赖 100 个数据库（我说的极端些），吞吐量当然有提升。

你这里槽点有点多，不一一辩解了。还是那句话：“组织即架构”，适合自己组织的才是最好的架构。

[heiya]

我浅显的理解是项目流量高且必须满足项目大、复杂这两个条件才可以上微服务，其余不用。

[RandomJoke]

@Joker123456789 订单是核心服务了，你这个例子完全是在找极端，比如淘宝里打卡服务挂了重启，这个时候影响用户下单你觉得合适吗，核心业务核心服务可能成熟了，都不怎么动，只需要新业务部分不熟就可以了，再极端点，都在一个服务里，新上的功能导致 oom ，导致你核心业务全挂，那也不合适，所以本身微服务就是根据业务适度做就行了

[ioufev]

最近搜索到了 OSGi ，说是：一个服务一个 Jar 包，在一个 JVM 上运行多个彼此隔离的 Jar 里的服务。再搜索相关库，基本在前几年就不更新了，Java 的模块化也从 Java 9 开始用 Java Platform Module System ，插件扩展形式也是基本的 SPI 方式，修改了配置需要重启 JVM ，而不是 OSGi 的热插拔。OSGi 提供服务注册和发现，和现在的微服务思想都是一致的。OSGi 的配置和管理相对较复杂，需要处理大量的模块、版本和依赖关系，对于大多数现代应用来说，这种复杂度是过于笨重的。

[junwind]

我觉得微服务还是不错的，看你怎么用，一个大服务器，分成 n 个小服务，各自对外提供服务 api ，部署灵活，维护简单，团队人员也灵活，总之，看自己的业务量，业务量单一的，可以不拆分，但是业务繁杂的，建议分开，并不是非要用流行的微服务那一套架设，就按系统分为一个一个的单体服务就行。

[charleslin]

完全赞同这个观点，为了微服务而微服务

[pocketz]

你图裂了，掘金不让外站访问

[Joker123456789]

@dxddd 有没有一种可能，单体也可以分库分表？所以你用这个举例子显然是不合理的。

[dxddd]

@Joker123456789 你这么一说到还真是。一个工程，A 模块访问 A 库，B 模块访问 B 库，C 模块访问 C 库。技术上确实可以，不过我在现实里确实没见过了。

[CodeCaster]

看完这个问题以及上面所有的讨论，我想提出一种全新的思路，大家可以一起讨论下。

首先，在微服务出现以前，大多数服务是以单体应用的形式存在的，后续由于各种原因（项目变大，需求变多等等）演变为微服务。单体应用有单体应用的优点与缺点，微服务也有微服务的优点和缺点。这两种模式的争论其实一直存在，正如 @micean 说的，“从一个极端到另一个极端”，这句话一点不错。我觉得其实是有解决方案的，是不是可以在这两个“极端”中找一个平衡点呢？

记得 2023 年的时候，google 开源了一款软件，叫 service weaver ，他有一个口号，“以单体形式编码，以微服务形式部署”，他的这个思路非常新颖，主要想告诉大家的一点就是，编码的时候可以按照一个模块一个模块来开发，互相没有耦合，但是最终部署的时候可以选择是单体应用一起部署，或者是微服务分开部署。

其实，我们团队在这之前也一直在做这方面的探索，但是一直没有开源，直到 2025 年春节前，我们的项目也开源了，我们以 Java 为主，推出了一套插件化的开发框架，每一个模块都可以以插件进行开发，插件之间互相不感知，但是我们参考 OSGI 的思想（@ioufev ），做到了插件可以聚合成一个进程部署（单体应用形态），或者分开部署（微服务形态）。

如果做到了这一步，是不是可以解决楼主的问题呢？其实微服务并不是一个错误的方向，而是在技术的螺旋式上升演进过程中的一个关键点。

以下是我在知乎上回答的类似问题的回答： https://www.zhihu.com/question/11654944781/answer/96580243167
这个是我们这个插件化框架的社区地址： https://github.com/ModelEngine-Group/fit-framework

我们项目刚开源不久，欢迎来讨论单体应用和微服务之间的相关问题，如果有同学们喜欢，也可以给我们点个 Star ，鼓励一下我们，感谢~