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

[itechnology]

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

[clf]

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

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

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

[cxytz01]

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

从单体到 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 天生合不来，那么需要微服务化，各自管各自的服务，谁也别管谁怎么实现的，给我接口就行。


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

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

[JamChiu]

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

[Rwing]

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

[sonyxperia]

给云厂商增加业绩

[stach]

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

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

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

[nicebird]

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

[ericls]

前面细分再多 到最后连同一个数据库

[msaionyc]

怎么这么多喷 CTO 的，如果业务那边有大规模扩张（扩城，营销，增加推广）的打算，做这种打算，提前布局，不是非常合理的吗。

没了解清楚情况就开喷，素质去哪里了呢。

动不动就 2w 用户不配微服务，怎么得，你们是觉得那些大公司都是一瞬间做到千万用户的吗

[itechnology]

@cxytz01 感谢耐心解答

[caterpillar2]

@cmdOptionKana 还是你通透啊

[mingl0280]

你们 CTO 是在什么环境下做出这个决断的？两万 DAU 做细粒度的微服务只会把小企业拖垮的。

[mingl0280]

@msaionyc 大规模扩张也要到有钱扩张才能搞重构，别特么扩张没扩起来重构系统先把公司拖没了。

[abcbuzhiming]

@msaionyc 问题是大公司的架构也不是第一天就按罗马设计建造的，别提什么提前布局，提前布局这个想法就是错的，超级系统都是由最简单的系统逐步迭代出来的，到哪个阶段用哪种架构，2w 用户还真就不配用微服务，一上来就想做超级系统这就是有病，十几年前早有有人批判过这种思维，结果十几年这种思维又死灰复燃了，到什么阶段，干什么事情，上来就想搞大新闻？谁出钱？有人陪你烧着玩那你就去吧，但是更多的例子是规模还没起来，公司先被你这超大规模的系统拖死了

[caixiaomao]

用户规模不大的情况下只会根据业务划分，比如用户服务、订单服务这种的，分太细没必要

[LoNeFong]

其实不止看用户量吧,也看维护成本
最好的感觉应该是`拆模块` 而不是`分服务`.

[libook]

不论合并还是拆分，都是可能会走极端的，最终拆成一个函数一个服务或者合并成只有一个大服务，所以如何把握这个度，需要权衡多个方面。

首先任何架构规划都是有寿命的，因为你只能根据经验来预估未来一定时间的情况，而且很可能会遇到外因变化而导致架构规划失去价值，正所谓没有银弹。

比如你可以预估未来一年的需求情况，然后就以一年为寿命来设计架构，然后再根据人事组织架构和业务划分情况来综合衡量应该如何划分微服务，一年后运气好的话可以继续使用，运气不好就重新评估重构计划。

拆分为微服务的目的主要是降低成本，比如人力成本、算力成本、故障损失或恢复成本等，如果达不到降低成本的目的，聪明的老板估计都不会批准方案。

[dwlovelife]

微服务的出现，一开始之所以要拆，从来不是一开始就因为技术原因拆的，是业务的发展的带动，导致从技术场景上而言不拆不行了。我所见到的能称的上所谓微服务的（不是那种自己跟自己玩，把业务模块拆几个 module ）。拿电商来说，通常情况下一个服务就基本对应一个部门（这里想表达服务是一个很大的概念不是那么简单的一件事），拿结算提单来说把，最前面的是交易中心（下单的时候跳结算页发起下单流程就是它干的），结算的时候结算页这个页面支付操作一般会有一个支付部门干（提供的就是支付服务），完成支付后，会进行对账（入和出是否平） [财务系统] ，财务系统完成了之后还会有订单中心（订单系统）修改订单状态.........

[dwlovelife]

所以你看微服务的出现从来就不是为了拆而拆的，它是业务带动的，按我说就楼主所说的业务场景，说实话用单机就够了，为什么？因为成本。所以说我个人认为你们的架构师很不专业。

[dwlovelife]

再多说一句百分之 80 的软件公司不需要微服务，因为量根本不是那么容易你想上去就上去的，这玩意很多都是程序员要么脑补 要么为了练手。