3 次尝试使用 springcloud 技术重构项目失败，暂时得出结论：微服务不行

[echofather]

结论如下： 1 没有充分的解耦，项目与项目之间还是高度耦合 2 学习配置 springcloud 超级麻烦 3 调试根本没法调试，都不知道走到哪去了 4interface 要作为公共的项目单独维护 5 整体运维超级麻烦，需要配置各种维护的中间件 6 嵌入式的微服务语言不兼容 7 最关键的是:分布式事务根本就是浪费资源，性能根本没有单机来的快

[adamzhuang]

@echofather 微服务之间交互是走 Dubbo 之类的 RPC 吗？我们这边系统交互用的 spring cloud feign，然后全上 Restful 接口，要用的时候就查文档

[reus]

为什么网飞行，你不行？
为什么谷歌行，你不行？
很显然就是你不行啊，不是微服务不行

[wolfie]

1 2 3 6 自己问题
5. 运维难度增高，开发难度降低
7. 大写的问号

[wangxiaoaer]

@echofather 服务之间用 restful 进行交互的话，为什么还要用接口，你们是直接 RPC 调用其它服务的类和方法？

何必呢，如果是 HTTP 这种交互方式，每个服务想怎么实现都好啊，语言不同都没关系。

[echofather]

@reus 你行吗，你行你上

[hlwjia]

9012 年了不要说什么行不行，说什么合适不合适。

[echofather]

@wolfie 关于第 7 条你自己测试下就知道了，使用那种全局事务的业务压测一下就行，其时间都消耗在网络 io 上了

[bk201]

没一条理由站得住脚，仔细琢磨下你自己的问题点，搜索下。

[ErrorMan]

如果微服务不行的话，为什么面试都要问呢，还是基础问题

[echofather]

@bk201 我不相信网上那些胡几把扯淡，他们居然告诉我事务可以用最终一致（手动检查修改错误数据）解决😭

[WispZhan]

很多小团队连设计和建模都没，上来就撸服务，走都没学好就想着跑。

做微服务要是真不会分服务，建议先从单体（巨石）应用开始，核心业务域确定了之后再根据情况进行微服务拆分。

上手就来微服务设计的一般只有两类人，1. 运维开发 /中间件开发，指脱离业务域运作的； 2. 啥都不知道盲从的，完全不顾及项目成本和风险的

[caotian]

已经在坑里了, 一个 springboot 项目做了一大半, 拆成了十几个微服务, 都走 restful 接口做 rpc, 最坑的是用了 spring cloud stream, 刚上它的时候觉得挺爽, 不用自己管理消息, 然后后续有些服务用了别的语言来写, 比如用 go 写了一些原生 sql 查询的统计报表啥的, 发现 consul 和 spring data gateway 都可以兼容别的语言, 就是这个 spring cloud stream 没说怎么兼容, 也查不到资料, spring cloud 就提供了一个 sidecar 项目来给其它语言兼容做了范例, 奈何这货用不上, 算是一个坑了。
另外拆成这么多服务, 每个服务用 docker 部署, 这个内存消耗真的是巨大哪, 每个 docker 容器, 如果不限制, 启动起来都是六七百 M, 运行一段时间都是上 G 的内存占用, 而 go 实现的报表启动起来的时候也就几 M 内存占用。而且如果上 k8s, rpc 也不好处理, 于是有了个 spring cloud for k8s 的项目, 感觉又弄更复杂了。
整体上看来, 如果项目要运行在 k8s 上, 还是不要用 spring cloud 为好, 个人浅见

[reus]

@echofather 我当然行啊，我早就上了，呵呵。

[xuminzhong]

一个项目中，决定使用什么、不使用什么，也是一个难点，这也是体现架构师价值的地方。
害怕技术落后、大厂把微服务作为基础面试，这点的确有跟风的原因。

入行 10 来年，最近半年开始接触 springcloud 微服务，以我不多的经验来看，
微服务在事务这块的处理能力真的非常吃力，特别是加上 kafka 这类消息系统后，几乎无解。

我也赞成楼主的观点，springcloud 微服务不适合大多的情况，而且真就没遇到适合的情况，
楼上说的谷歌、网飞行，就比较扯了，他们面对的业务，国内有几个公司、几个项目会遇到。

[arraysnow]

我们前台每天千万交易量，不用微服务会搞死的。
运营端顶多 10wpv，拆分微服务纯属找别扭。

[arraysnow]

所以你的结论还是片面些了，大公司一个随随便便的前台应用，后面就需要不同部门的几百人程序员支撑。不考虑服务治理，确实没办法撑起业务量，这在大厂算是你说的“基础”了

[mawenjian]

如果不是访问量巨大，或者业务庞杂，硬上微服务意义不算太大。如果考虑以后的可扩展性，只做服务化也足够了，后续再拆也不算困难，步子太大的话容易扯着 D。

[index90]

赞同 #31，听到过有人说，“然后就说明明一个请求搞定的事情，偏偏要转发几次请求”，最后得出结论是微服务没用。
不熟悉业务，不从领域设计出发，就是为了微服务而微服务了。

[wc951]

上微服务之前先了解领域驱动设计

[raphael008]

我看老外架构都是在 IT 基础架构方面想办法。。。