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

[echofather]

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

[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 接口放到一个统一的公共项目中，而不是各自复制各自的不然后期添加修改功能就乱了。所以这一点就很别扭