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

[echofather]

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

弄这个玩意，主要是因为害怕技术落后，况且各个大厂都把微服务作为基础面试问题。你们不害怕吗

v 社里的大神还是比较多的，感谢各位给我指引方向

[lazyfighter]

我都傻了

[aLazarus]

看到标题我以为严肃文学发展到了 v2

[ZSeptember]

哈哈哈，这几条基本都是你们自己的问题。。关微服务什么事情

[codzzb]

@aLazarus 严肃文学已经深入程序员生活的方方面面（一个想法不一定对

[tuboshuv1]

哈哈哈哈哈哈哈哈哈，还是用 Spring boot 吧。你们需求没到这步。

[exploreXin]

数次尝试使用 Mac 写代码不出 bug 失败，暂时得出结论：苹果不行。

[chendy]

不该拆，或者不会拆，就不要拆

[askfilm]

@echofather 肯定有会一大批人讽刺你技术没到家， 不过我觉得你总结的挺好，比较实际

[Guozi1989]

在没有真正理解微服务的时候不要轻易的去尝试硬上。

[stevenkang]

微服务分而治之，治理的是人员架构，跟技术关系不大。

微服务维护成本比单体架构高太多，舍不得投入人力资源去搞的话，还是老老实实单体架构。

[skotori]

的确，项目没有臃肿到必须分模块部署的时候，不需要微服务

[misaka19000]

@codzzb #4 你是立党吗？

[aLazarus]

@codzzb #4 你是特师 2300 个精神碎片中的一个么？

[Yuicon]

最近我也在重构 确实太麻烦 本来是 service 之间的调用 改成微服务 就要一次性全改好 工作量太大 所以我选择先把整个单体作为一个微服务提供服务 然后从依赖最小的改起 比如我第一个准备改 id 生成器

[GoLand]

图来了

[oatw]

不知道楼主是自己玩儿还是和团队小伙伴一起玩儿，如果自己玩儿，还是不要微服务了吧～蛋疼夹着走路过。。。

[securityCoding]

每天就几万的量 , 上个毛微服务

[adamzhuang]

4. interface 要作为公共的项目单独维护

这点没理解

[Amit]

没有一定的量不要用微服务。直接改造成微服务太激进了，可以先在原服务基础上改，分模块解耦，然后把能拆的拆出来，不一定要拆的很细，实在不好分开的放到一个服务也没关系，分布式事务能不用就不用。

[echofather]

@adamzhuang 因为各个微服务调用的其实是各个 service 的接口，所以最优的实践是将所有的 service 接口放到一个统一的公共项目中，而不是各自复制各自的不然后期添加修改功能就乱了。所以这一点就很别扭

[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 基础架构方面想办法。。。

[HangoX]

楼主一个人玩啥，人家都是好几百人的团队的，然后每个小组负责不同业务，以前那种开发方式压根没法开发，这样才分开来，性能肯定有下降，但是开发效率上来了

[CODEWEA]

微服务 服务的是团队，不是性能，微服务是有额外的资源消耗的，非大公司大流量，别瞎搞花里胡哨的，没用。

[yidinghe]

微服务的人力成本非常高的，解耦的代价就是代码量增加好几倍，业务模型复杂好几倍。

[lihongjie0209]

@reus #22 因为 99%的公司不如谷歌

[nekoyaki]

3 次尝试使用导弹打蚊子失败，暂时得出结论：制导兵器不行。

[hantsy]

1. 在你不懂领域建模，搞不清自己项目需求的 Bounded Context 的时候，还是老实做好基本的东西，把业务逻辑先清理，这比什么都重要。

2. 微服务不仅是应用程序逻辑上细分，团队组织结构也要随之变化。

3. 微服务实施中 DevOps 是一等公民，如果在 Infrastructure 上不能做到自动化，不写测试，不做 CI、CD，还是算了吧。这个我了解过国内所谓在实施微服务的，基本很少去做，靠人肉运维还是算了吧，你永远不是微服务。

4. 微服务为容器而生，Spring Cloud 最大问题就是把微服务一些运维相关的东西耦合到应用之一，会导致写测试非常不方便。在 Spring Cloud 刚出来的时候，那时只有 Netflix 那一套，一个项目 Dropwizard 迁移过来，做了大量的 POC，最终我们只采用了 Spring Cloud 的日志跟踪，其他全部用容器（ Service Discovery, Load Balance 等）实现。

如果对微服务的一些模式有一定认知，你会发现用什么语言框架去实现都不是问题。当你可以驾驭微服务，完全可以混合使用多种语言，架框去实现。理想情况下，使用微服务可以发挥团队所有人员的天分，开发人员（一个小团队）完全可以用自己的擅长的技术去实现（ micro ） service，把产品做到极致。

你以为用了 Spring Cloud 就是微服务。

[hantsy]

@yidinghe 这个没错，天下没有免费的午餐。马大叔文章也明确建议从单体应用开始，积累领域建模经验，为将来可能的微服务转形准备。

[Cbdy]

做系统设计要实事求是，理论联系实际。切忌本本主义，教条主义。

[luozic]

结合自己实际情况做技术，再好的东西，暂时用不了就是用不了。 并且微服务也不是适合所有公司的“银弹”。

[zhazi]

多读书，先学 oop，熟练后然后就自己能整理出来领域上下文了。
用自然语言描述清楚你的业务，然后区分出业务名词。
思考业务名词是不是应该建模。
不要去考虑什么微服务。
每个业务名词都清晰了，对象也就丰满了。
用贫血模型永远都是 service 里的大泥球。

[reus]

@lihongjie0209 为什么不做那 1%呢？不想上进又何必工作。

[vjnjc]

不知道你们团队多少人，之前我们 5 个人的情况也调研过，发现提升不大。

[shanlan]

看大家这么一说，我觉得我们公司的微服务可能玩不起来了。

[xuanbg]

不客气地说，大部分程序员连方法 /类都分不好，只会写长长的、纠缠在一起的面条代码。不管什么业务，都是三层一把梭，哪有什么模块划分。连划分模块的能力都没有，你能指望他搞好微服务？

[v2orz]

小公司小业务量就别用呗，当你业务大了之后你自然就知道需要用了

[wd1196554643]

小公司没必要，没有复杂的业务没必要上微服务，单体的应用可以解决没必要搞复杂

[lihongjie0209]

@reus #51
首先， 客户和业务没这需求，作为开发你怎么办
其次，在最理想的情况下， 你决定成为那 1%的开发者， 你跳槽到谷歌之类的大公司，然后呢，所有人都有着理想情况吗？


只要这个世界还在运行，那么就会注定有 99%的一般需求的项目和 1%的极端需求的项目，开发者也是这样。不能说你是 1%的那波人就认为 99%的人不努力。

[jwenjian]

nginx 后面挂几个单体 springboot 应用 实在撑不住了再一点一点拆。

[reus]

@lihongjie0209 那就是人的问题，不是“微服务”的问题。

[cyheng]

楼主深知钓鱼的是技巧，我估计它如果老老实实问他的问题估计没有几个人回答

[YzSama]

@caotian #32 是的，我认同

如果微服务 没有好的基础设施，还是不要碰的好。 我们公司是上了 k8s，但是也不会想去上 SpringCloud。

SpringBoot 足够了。虽然，拆分了。但是 开发的效率是提升了几倍。

我们没上容器化之前，运维人肉搬运 代码上线的。 运维天天被各个项目上线，烦的抽离不出来。 基本一天都安排不过来。自动化之后，基本没人找了。专心搞 服务器。😂

[lihongjie0209]

@reus #59 技术问题不能落地比人的问题更大

[uyhyygyug1234]

你们喷楼主干哈，楼主自己不是总结的挺好，认识到了业务模型不适合。这个社区提供经验教训不挺好。

[reus]

@lihongjie0209 屙屎不出赖地硬。

[newtype0092]

@uyhyygyug1234 一个东西尝试了 3 次认识到了业务模型不适合，那不是瞎尝试么。。。
楼主说主要是怕技术落后，这算个什么鬼理由？
我理解的重构用该是提前调研分析优缺点，想好要解决的现有问题，和可能引入的新问题，评估利大于弊才动手。
看见别家用什么二话不说上手就是照着干，那纯粹就是闲的想加班了。。。

[echofather]

@newtype0092 不会新技术，没有项目经验，等你 35 了，你觉得他们大厂公司不会淘汰你吗

[yiyi11]

有一张图，就是单机服务是一坨大 shi，然后拆成微服务是一堆小 shi。微服务只有配合容器技术，深度实践 devops 才值得，否则只是徒增成本。而且微服务不是全部，只是解决特定领域的问题的子集。

[kiddult]

@xuminzhong 涉及 2c 的话，轻易不要用事务，2b 看个人，不过还是觉得事后补偿比事务好，为那点安全性增加的复杂度和性能消耗不成比例

[JerryCha]

扔掉 SpringBoot，你的 DEBUG 会更轻松。

[xkzhangsan]

建议看一下重新定义 Spring Cloud 实战，里面讲解比较详细，包括分布式事务处理。

[xkzhangsan]

老项目业务比较复杂的话，重构要慎重，慢慢迭代进行。

[oneisall8955]

@JerryCha 哈？为啥这么说

[sujin190]

能得出这个结论的大部分估计都是不是技术方案不行，是你不行，抽象架构化能力不足的话，微服务这种东西做出来只会比单体服务更为糟糕

[W1angMh]

我们团队最近也在做架构升级，银行类项目，单体应用拆成分布式微服务，这个过程的确会让人非常头痛，一周要开无数次会来讨论究竟怎么拆。我们原来的应用体量非常大，业务逻辑非常复杂，现在拆成微服务之后，感觉清晰明朗许多，优点还是挺明显的。我的结论就是技术没有什么行与不行这一说法，只能说合适不合适你当前的业务需求

[lihongjie0209]

@yiyi11 #67 https://imgur.com/Rmur93a 这个吧， 我看 youtube 的一个演讲的时候截图的， 就是说这种情况

[lihongjie0209]

@reus #64 对于楼主的结论来说确实是这样的， 对于我来说， 只是微服务在这种场景下不合适

[lidfather]

微服务已经过时，现在是中台架构，了解一下

[dongeast52123]

实施微服务有一个必要条件：有钱。有钱了才能有一套强力的运维开发体系支撑，硬件，软件，开发人员。
但是真正搞得起这些的，公司不多，许多中小型互联网公司开始折腾“微服务”，纯属自己给自己挖坑。先去把业务模型划分清楚吧。

[lynskylate]

@xuminzhong ....大厂根本不会用 spring cloud，默认的组件根本满足不了性能需求，都是自建基础设施的。
spring cloud 的目标本身就是没有能力和金钱组建基础设施的小公司

[Arnie97]

如果各服务都部署在同一台机器上，增加了通信开销，那自然是浪费资源，没有单体应用效率高。分布式的意义在于方便水平扩容…

[JerryCha]

@oneisall8955 看 15 楼

[mreasonyang]

我觉得要不要拆微服务有个简单但通常都很有效的判断标准，那就是你们的老服务为了保证服务容量是不是占用了大量机器导致每次发布都要花费一个小时以上，如果是的话那就应该拆分了

[mreasonyang]

另外微服务其实服务间调用真的不适合搞成 HTTP RESTful，如果发现网络 IO 是瓶颈，还是尽早改二进制 RPC 吧

[jwangkun]

只能说你们公司现在业务达不到需要微服务的条件，不要做井底之蛙，随便作出结论

[SkyLine7]

我们这用 springboot 足够了,本来每天访问量就不多

[lazyfighter]

@stevenkang 微服务涉设计中有专门一章来说明这个东西，推荐 @echofather 读一读