微服务怎么划分才算是正确的？是越细越好吗？

[itechnology]

看到有人发了微服务相关的主题有感而发。
我们的项目一开始有个用户微服务，后来来了个首席技术官，要求微服务再细分，然后用户微服务就拆分成了用户基本信息微服务和用户实名信息微服务，也就是说，把用户实名认证单独拉了个微服务。其他的微服务也差不多，然后导致现在大大小小的微服务接近五十个了（原来也就二十多个）。但其实用户量不多，也就是 2 万不到。
我心里是不赞成微服务分这么细的，但想想问问各位，技术官是对的还是我想法是对的呢？

[vanishxiaoma]

应该一个接口一个微服务

[dilu]

2w 的用户 估计 dau 就一千吧？

这也用微服务？

[leafre]

粒度分的太细，徒增复杂度，如分布式事务，在没有性能瓶颈的情况下，细分就是耍流氓

[lilingj]

推荐《凤凰架构》，最近看完，有谈到微服务粒度的上下界问题

[gam2046]

个人感觉还是应该看业务场景以及业务规模，业务规模小的情况下，All in one 都没问题，开发起来也快，部署也方便。

没有产生业务瓶颈的情况下，过度细分会导致开发复杂度急剧上升，而且微服务之间的额外开销，可能导致性能还不如 All in one

[potatowish]

2 万用户不配用微服务

[coolcoffee]

真微服务的话，应该是数据库也要拆分的。

现在很多微服务本质都是 SOA😂

[janus77]

新官上任三把火罢了，给自己找点 KPI 。别太较真

[chendy]

具体问题具体分析，对比拆分前和拆分后项目的开发和运行情况，应该自己就可以有个大概的答案了

[cmdOptionKana]

站在投资人的角度，你对，为公司省钱。

站在打工人的角度，技术官对，拿公司的钱练手，以后简历也好看。

[qingwnag]

不要小看单体，这个规模单体足矣；微服务费劲儿

[iyear]

拿公司钱学学新东西不挺好的吗

[CantSee]

单体服务,ng 负载均衡,一把梭哈,用户体量上来再拆分,一口吃个胖子维护起来麻烦的要死

[Reid]

我觉得应该也是考虑了以后流量增大之后的可维护性和拓展性吧

[iyaozhen]

没必要

最近我们在合微服务，基本 3 个合成 1 个

[jadec0der]

不光要考虑用户数量，也要看团队规模，

如果用户服务只有一个开发负责，那拆成两个就很浪费时间。如果用户服务有 100 个人的开发团队，那拆成 10 个也可以理解。从 CTO 的角度来看，团队之间的责任明确、依赖减少，比服务的性能更重要。

[abc0123xyz]

练练手不好吗，公司省不省钱，和你个打工的有什么关系.

[masterclock]

用户量只是一个方面，不是规模的唯一度量
现在拆出来的这些 “微服务” 很可能不是微服务，现在的架构很可能变成了 分布式单体服务
我觉得每一个 微服务 都应该是 越 “大” 越好，完整、独立，不依赖于外部，内聚，难于拆分

[pengtdyd]

垃圾的技术领导必然有垃圾的项目

[jtwor]

2 万。。何必捏