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

[itechnology]

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

[mmdsun]

microservice-boundaries：

https://docs.microsoft.com/zh-cn/azure/architecture/microservices/model/microservice-boundaries

[abigeater]

目前公司也是采用微服务的方式 关于划分的细度我也是和领导吐槽了很多遍。
就用户鉴权这一流程就划分了：用户 /权限 /配置 /菜单 /API/OSS，六个服务。整个登陆流程是：登陆(OSS)/获取用户(User)/用户配置(Config)/鉴权(RBAC)/用户可操作菜单(Menu)/用户可调用接口(API) 这六个服务本地起了后电脑资源几乎满了（也可能的 Hyperf 的问题也得吐槽一下）。
但是用的爽的地方是不用和别人写同一个服务的代码，且出了追踪到问题后找写该服务的人，少了很多的黑锅。

[julyclyde]

执行时间长的，比如后台和别的外部系统通信
前后步骤的比例不一样的，比如一次登录、多次查看、少量购买

[lotusp]

同意微服务并不是拆的越细越好，微服务架构的实施从某种程度上来说要求是很高的，最好是有完善的自动化部署流程，可以自动发布到对应的环境。小团队维护多个服务本身也是非常痛苦的事情，不仅对于因为拆分带来的额外知识和复杂度需要更高的认知，也会降低开发和维护效率。

分享一篇很早前老马的文章： https://martinfowler.com/bliki/MonolithFirst.html
这篇文章现在看来也并不过时，不能为了拆分而拆分，就像动不动就造个轮子一样，要克制这种冲动。

讨论如何能够控制合理的粒度，或者什么情况下才考虑拆分，我之前写过一篇文章，欢迎交流指正：
https://maguangguang.xyz/services-split-in-iterative-development