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

• 資深大佬 : fx

  维护痛苦

• 資深大佬 : leopod1995

  微服务的生长条件是，单机业务过于复杂 -> 拆成 n 套（ n<10 -> 每套业务耦合太严重，开发效率降低-> 微服务(n>10 -> 维护成本太高-> 合并同类项 -> 服务减少(n<10 -> 起名宏服务(macro

  本质上还是业务和架构、开发效率、运维成本的综合考虑

• 資深大佬 : janxin

  上百个微服务你试试…然后每个微服务再 N 个节点，直接爆炸

• 主 資深大佬 : tctc4869

  @janxin 这样的话，那 几十个微服务节点怎么样？如果项目大了不走微服务，那还能走什么偏门的方向么？

• 資深大佬 : xx6412223

  传统企业就不合适用微服务，

• 資深大佬 : liuzhaowei55

  单点故障，链式爆炸。

• 資深大佬 : wizzer

  90%以上客户的项目，单应用足够了

• 資深大佬 : maichael

  架构和设计本身就没有银弹，不存在能适配所有场景的设计，总是想着一招鲜吃遍天是不可取的。根据你业务实际的需求来设计你的架构，用不用微服务都要贴合你的实际需求来决定。

• 資深大佬 : janxin

  @tctc4869 几十个范围比较广，如果 20 个微服务一般人手团队问题不会很大的。

  这个不是说微服务方向上有问题，而是其实整合部分微服务为宏服务在维护性上会好很多。

• 資深大佬 : sampeng

  我早上才跟同事聊微服务弊端。设计架构的人要求太高。真按业务拆分。很容易写出 100 层调用代码。一次就算 1ms 。也要 100ms 。

• 資深大佬 : CODEWEA

  会玩概念啊

• 資深大佬 : 594duck

  当初我说为微服务不是银弹没必要，docker 更不是万能药。

  多少人喷我啊，多少人笑话我啊。v2 桑多少人和我吵啊。

  现在呢

• 資深大佬 : shineqaq

  就是不拆分，或者少量拆分

• 資深大佬 : 594duck

  对 99%的企业来说做好 SOA 就够了。

  上微服务要么面向简历要么面向升职

• 資深大佬 : 594duck

  @leopod1995 中间少了 SOA，很多公司其实上了 SOA 就解决了所有问题。

  只不过大部份技术人员为了恰饭，天天吹

• 資深大佬 : wangyzj

  @594duck #14 除了这个面向简历，面向升职，还有数字化转型

• 主 資深大佬 : tctc4869

  @janxin 服务拆分的话，不一定要完全按照为微服务的概念拆分把。不是还有 SOA 服务么？

• 資深大佬 : firefox12

  @janxin 1000 多个微服务飘过，也就那样。没有规则的前提下是没办法管理的。

• 資深大佬 : ppphp

  维护老项目总是很痛苦的，分拆也是要合理分拆人和业务

• 資深大佬 : Lighfer

  合理拆分就行
  我们的项目，数十个业务，每个业务都是一大功能，项目团队前中期 60 人左右（现 30 多人），单体应用的开发吃不消。
  踩的坑不少，但是团队成长起来后，开发效率和维护成本明显都比前一个大版本（单体应用）要好。
  前期是真的痛苦，踩的坑不计其数，效率低得吓人，调用链路的问题、监控、CI/CD 、事务、bug 排查、拆分方案等，很多，每一个环节都有坑要踩，当然不排除是我们团队太菜了，踩的坑比别人要多。
  尤其是想着第一次就作出完美的拆分方案，会越做越不合理。
  总之微服务的架构对开发人员的水平要求确实要高很多，但是只要能解决这些问题，并做好相关文档，微服务还是有其可取之处的。

• 資深大佬 : 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