微服务的节点多了真的很不好么？宏服务是什么东西？

[tctc4869]

今天看到这个

https://my.oschina.net/DeveloperFront/blog/4651920

新的专有名词被发明出来“宏服务”，这是什么东西？取代微服务的东西？微服务节点多了真的很不好么？

各位的主管 web 项目，大了之后有没有考虑微服务，还是考虑过走“偏门”的方法？还是到时候看情况着来？

[ArJun]

微服务的利器是 K8s

[janxin]

@tctc4869 我的理解是微服务是 SOA 的一种落地实现方式

[Kirsk]

微服务不能提供效率用来装逼增加工作量？ 项目适合什么就是什么 ddd soa 微服务 三缺一

[maigebaoer]

类似于一个 App 拆分成 n 个模块，每个模块可以交给不同的人搞，并行开发。然而……以大多数厂子的沟通调试成本……

[shyangs]

單點故障，鏈式爆炸.

[Mohanson]

等一个名词: 量子服务 /智能服务...

[index90]

对微服务一知半解，道听途说就出来踩微服务架构。存在即合理，围绕着微服务架构的生态逐渐丰富和完善，真如你所说那么不堪，还能存在那么多年吗？

所会拆出 100 层调用的那些人，根本没去了解微服务要解决的问题，为了微服务而微服务。

ABC 三个模块，在巨石里面他们是三个互不相干的业务组件，其中一个升级会导致另外两个业务也会产生变更，其中一个代码有 bug，会影响另外两个业务程序正常运行。为了解决这个问题，才把他们拆开三个微服务。而不是因为 A 通过函数调用 B，B 通过函数调用 C，就把他们拆成微服务。

[xuanbg]

@594duck 现在也一样啊。微服务要做好是需要一些基石的，譬如 DevOps 、DDD 、Spring cloud，还有用户中心、账务中心、消息中心等业务无关的支撑服务。这些都是搞定了，就只剩下写写业务代码了。这样的微服务是很爽的，每个服务都很简单，开发快、上线快，并且易于扩展和维护。

微服务的核心优势就是把系统复杂度从开发转移给了运维，而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度，所以大家都很快乐。但如果你没有能力搞定运维，就会被干趴下，于是微服务对你就不是什么好事了。在服务拆分上面也一样，拆得不好，维护起来比单体更麻烦。

所以，是不是要上微服务，不是看规模大小，也不是看行业，而是看团队有没有这个能力。有能力就上，没能力就不要赶时髦硬上了。

[felixcode]

宏服务的诞生是因为微服务助力互联网+后产生的生态化反。

[Tink]

大企业系统多的，还是 ESB 后期维护成本低一些

[tctc4869]

@Kirsk ddd 是什么？

[Kirsk]

@tctc4869 领域驱动设计

[firefox12]

https://cloud.tencent.com/developer/article/1701195