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

应该一个接口一个微服务

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

这也用微服务？

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

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

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

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

2 万用户不配用微服务

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

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

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

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

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

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

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

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

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

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

没必要

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

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

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

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

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

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

2 万。。何必捏

服务器资源足够就划分呗（/doge ）

基础服务一定是独立的微服务，比如用户权限服务等被所有服务都依赖的。

业务服务间一定是低关联度的，同一个业务模块的作为一个微服务节点（内部可以二次划分子业务，放在不同的生产者里，但这些子业务间关联度还是很高的）

微服务的划分粒度是比较感性的话题，没有统一的标准。不能为了微服务而微服务，也不能为了单体而单体。它们之间没有明显的边界，不是泾渭分明的。

从单体到 SOA，到横向、垂直划分，到微服务，它们之所以出现都是为了提高生产力亦或者降低扩容成本，简称降本增效。以下讨论排除金融、游戏业务。(金融、游戏业务，为了更低的时延，核心模块不会使用微服务，关键模块甚至不计成本，性能至上)

先从成本角度考虑：如果你是一个 NewSQL DB，显然做成单体不适合。DB 作为整套业务系统的核心，压力最大，扩容最贵。单体 DB 扩容，意味着把整个 DB 程序整体复制 n 次，而不管热点模块是哪个，扩容成本比较大。因此，需要按模块拆分，扩容时，只需扩容热点模块。可以想象 mysql，redis 等 OLD SQL 的扩容，都是整个 DB 进行扩容，贵。

又从成本角度考虑：如果你是一个 DB，轻量级的。应用于嵌入式场景，开发者最求的是我只需要调用函数，就可以用你的 DB，不需要各种网络功能，而且占用资源少，还要快。那么此时微服务显然不适合，甚至带有网络 IO 的 server 都不适合，这就是 SQLite 的诞生原因： 我就是一个 library，不需要微服务，只需要模块化。

从技术维护角度考虑：一个单体服务，业务变更频繁，牵一发而动全身，每次上线整套系统都要有不定长的停机时间。因此需要微服务化：将不频繁变更的模块、频繁变更的模块剥离、分离出来，日后的改动只需要关注频繁变更的模块。
上线时只有频繁变更的模块会受到影响。

从技术的角度考虑：一个单体服务，需要稳定，不能重启，但又经常业务变更： 比如涉及到 TCP 长链接管理的服务。那么需要将长链接管理的模块和经常变更的业务剥离出来。

从机器资源的角度考虑：一个单体服务，既是 IO 密集型，又是 CPU 密集型的。那么需要将 IO 逻辑和 CPU 计算逻辑剥离出来，充分利用不同机器特性。

从业务、项目推进、扩容成本的角度考虑：一个电商程序，一个人可以负责全部，那么就不剥离。后续功能变多，一个人负责不过来，就模块化，依然不剥离。再再后续，某个模块上线时需要整个程序停机更新，则需要剥离。再再后续，某个模块成为热点时，需要整个程序扩容，则需要剥离。再再后续，单体服务限制了多人协作，你一个 pr，我一个 pr，他一个 pr，全都 hold 住，等着 merge 进入主干，则需要剥离。

从人员管理角度：A 和 B 天生合不来，那么需要微服务化，各自管各自的服务，谁也别管谁怎么实现的，给我接口就行。


以上讨论的是分。分了之后在合，我没遇到过，但是我可以想象也是为了降本增效： 分了的服务，给技术、技术维护、项目、业务、运维等任一项带来了层本上的上升，所以要合。

关于你的首席技术官，我不好评价他的对错，因为基于你的描述，只谈到了果，没有谈到因 -- 为什么而分。

这 cto 是上来就问 5000w 并发的人么……

实话，2w 还没必要，不过也看你们有多少开发人员

给云厂商增加业绩

老板: 我们的技术是不是最牛逼的?
CTO: 我们用的都是业界最领先的技术! 包括但不限于微服务, 云原生, 大数据, 人工智能分析, 千人千面推荐算法.
你: 在大佬挖的坑里无法自拔, 遂准备跳槽.

面试官: 请问你做过什么牛逼的项目, 用过什么牛逼的技术
你: 微服务+云原生+大数据+人工智能分析+千人千面推荐算法
HR: 恭喜你通过我司的面试, 评定为 CTO

老板: 我们的技术是不是最牛逼的?
CTO(你): 是的!

2w，随便搞啊。。。瞎折腾都行。