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

[tctc4869]

今天看到这个

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

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

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

[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 排查、拆分方案等，很多，每一个环节都有坑要踩，当然不排除是我们团队太菜了，踩的坑比别人要多。
尤其是想着第一次就作出完美的拆分方案，会越做越不合理。
总之微服务的架构对开发人员的水平要求确实要高很多，但是只要能解决这些问题，并做好相关文档，微服务还是有其可取之处的。