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

@caotian #32 是的，我认同

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

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

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

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

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

@lihongjie0209 屙屎不出赖地硬。

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

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

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

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

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

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

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

@JerryCha 哈？为啥这么说

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

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

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

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

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

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

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

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