这是一个创建于 1160 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到有人发了微服务相关的主题有感而发。
我们的项目一开始有个用户微服务，后来来了个首席技术官，要求微服务再细分，然后用户微服务就拆分成了用户基本信息微服务和用户实名信息微服务，也就是说，把用户实名认证单独拉了个微服务。其他的微服务也差不多，然后导致现在大大小小的微服务接近五十个了（原来也就二十多个）。但其实用户量不多，也就是 2 万不到。
我心里是不赞成微服务分这么细的，但想想问问各位，技术官是对的还是我想法是对的呢？
我们的项目一开始有个用户微服务，后来来了个首席技术官，要求微服务再细分，然后用户微服务就拆分成了用户基本信息微服务和用户实名信息微服务，也就是说，把用户实名认证单独拉了个微服务。其他的微服务也差不多，然后导致现在大大小小的微服务接近五十个了（原来也就二十多个）。但其实用户量不多，也就是 2 万不到。
我心里是不赞成微服务分这么细的，但想想问问各位，技术官是对的还是我想法是对的呢？
 |
1
vanishxiaoma 2021-09-27 13:06:31 +08:00  1
应该一个接口一个微服务
|
 |
2
dilu 2021-09-27 13:12:44 +08:00
2w 的用户 估计 dau 就一千吧？
这也用微服务？ |
 |
3
leafre 2021-09-27 13:27:56 +08:00 1
粒度分的太细，徒增复杂度，如分布式事务，在没有性能瓶颈的情况下，细分就是耍流氓
|
 |
4
lilingj 2021-09-27 13:28:05 +08:00
推荐《凤凰架构》，最近看完，有谈到微服务粒度的上下界问题
|
 |
5
gam2046 2021-09-27 13:32:17 +08:00
个人感觉还是应该看业务场景以及业务规模，业务规模小的情况下，All in one 都没问题，开发起来也快，部署也方便。
没有产生业务瓶颈的情况下，过度细分会导致开发复杂度急剧上升，而且微服务之间的额外开销，可能导致性能还不如 All in one |
 |
6
potatowish 2021-09-27 13:33:48 +08:00 via iPhone 9
2 万用户不配用微服务
|
 |
7
coolcoffee 2021-09-27 13:37:04 +08:00
真微服务的话，应该是数据库也要拆分的。
现在很多微服务本质都是 SOA😂 |
 |
8
janus77 2021-09-27 13:41:04 +08:00 1
新官上任三把火罢了，给自己找点 KPI 。别太较真
|
 |
9
chendy 2021-09-27 13:41:53 +08:00
具体问题具体分析，对比拆分前和拆分后项目的开发和运行情况，应该自己就可以有个大概的答案了
|
 |
10
cmdOptionKana 2021-09-27 13:58:29 +08:00 4
站在投资人的角度，你对，为公司省钱。
站在打工人的角度，技术官对，拿公司的钱练手，以后简历也好看。 |
 |
11
qingwnag 2021-09-27 14:04:33 +08:00
不要小看单体，这个规模单体足矣；微服务费劲儿
|
 |
12
iyear 2021-09-27 14:07:51 +08:00
拿公司钱学学新东西不挺好的吗
|
 |
13
CantSee 2021-09-27 14:10:54 +08:00
单体服务,ng 负载均衡,一把梭哈,用户体量上来再拆分,一口吃个胖子维护起来麻烦的要死
|
 |
14
Reid 2021-09-27 14:13:43 +08:00
我觉得应该也是考虑了以后流量增大之后的可维护性和拓展性吧
|
 |
15
iyaozhen 2021-09-27 14:16:32 +08:00
没必要
最近我们在合微服务，基本 3 个合成 1 个 |
 |
16
jadec0der 2021-09-27 14:17:20 +08:00 1
不光要考虑用户数量，也要看团队规模，
如果用户服务只有一个开发负责，那拆成两个就很浪费时间。如果用户服务有 100 个人的开发团队，那拆成 10 个也可以理解。从 CTO 的角度来看，团队之间的责任明确、依赖减少，比服务的性能更重要。 |
 |
17
abc0123xyz 2021-09-27 14:17:39 +08:00
练练手不好吗，公司省不省钱，和你个打工的有什么关系.
|
 |
18
masterclock 2021-09-27 14:19:46 +08:00
用户量只是一个方面，不是规模的唯一度量
现在拆出来的这些 “微服务” 很可能不是微服务，现在的架构很可能变成了 分布式单体服务 我觉得每一个 微服务 都应该是 越 “大” 越好，完整、独立，不依赖于外部，内聚，难于拆分 |
 |
19
pengtdyd 2021-09-27 14:43:44 +08:00 1
垃圾的技术领导必然有垃圾的项目
|
 |
20
jtwor 2021-09-27 14:57:45 +08:00
2 万。。何必捏
|
 |
21
clf 2021-09-27 15:08:39 +08:00
服务器资源足够就划分呗（/doge ）
基础服务一定是独立的微服务，比如用户权限服务等被所有服务都依赖的。 业务服务间一定是低关联度的，同一个业务模块的作为一个微服务节点（内部可以二次划分子业务，放在不同的生产者里，但这些子业务间关联度还是很高的） |
 |
22
cxytz01 2021-09-27 15:18:32 +08:00 3
微服务的划分粒度是比较感性的话题，没有统一的标准。不能为了微服务而微服务，也不能为了单体而单体。它们之间没有明显的边界，不是泾渭分明的。
从单体到 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 天生合不来，那么需要微服务化，各自管各自的服务，谁也别管谁怎么实现的，给我接口就行。 以上讨论的是分。分了之后在合，我没遇到过，但是我可以想象也是为了降本增效： 分了的服务，给技术、技术维护、项目、业务、运维等任一项带来了层本上的上升，所以要合。 关于你的首席技术官，我不好评价他的对错，因为基于你的描述，只谈到了果，没有谈到因 -- 为什么而分。 |
 |
23
JamChiu 2021-09-27 15:53:26 +08:00 via iPhone
这 cto 是上来就问 5000w 并发的人么……
|
 |
24
Rwing 2021-09-27 15:54:40 +08:00
实话，2w 还没必要，不过也看你们有多少开发人员
|
 |
25
sonyxperia 2021-09-27 16:19:04 +08:00
给云厂商增加业绩
|
 |
26
stach 2021-09-27 16:53:30 +08:00 2
老板: 我们的技术是不是最牛逼的?
CTO: 我们用的都是业界最领先的技术! 包括但不限于微服务, 云原生, 大数据, 人工智能分析, 千人千面推荐算法. 你: 在大佬挖的坑里无法自拔, 遂准备跳槽. 面试官: 请问你做过什么牛逼的项目, 用过什么牛逼的技术 你: 微服务+云原生+大数据+人工智能分析+千人千面推荐算法 HR: 恭喜你通过我司的面试, 评定为 CTO 老板: 我们的技术是不是最牛逼的? CTO(你): 是的! |
 |
27
nicebird 2021-09-27 16:58:06 +08:00
2w，随便搞啊。。。瞎折腾都行。
|
 |
28
ericls 2021-09-27 23:53:56 +08:00 via iPhone
前面细分再多 到最后连同一个数据库
|
 |
29
msaionyc 2021-09-28 09:24:59 +08:00
怎么这么多喷 CTO 的，如果业务那边有大规模扩张（扩城，营销，增加推广）的打算，做这种打算，提前布局，不是非常合理的吗。
没了解清楚情况就开喷，素质去哪里了呢。 动不动就 2w 用户不配微服务，怎么得，你们是觉得那些大公司都是一瞬间做到千万用户的吗 |
 |
30
itechnology OP @cxytz01 感谢耐心解答
|
 |
31
caterpillar2 2021-09-28 10:25:01 +08:00
@cmdOptionKana 还是你通透啊
|
 |
32
mingl0280 2021-09-28 10:37:10 +08:00 via Android
你们 CTO 是在什么环境下做出这个决断的？两万 DAU 做细粒度的微服务只会把小企业拖垮的。
|
|
33
mingl0280 2021-09-28 10:38:07 +08:00 via Android
@msaionyc 大规模扩张也要到有钱扩张才能搞重构，别特么扩张没扩起来重构系统先把公司拖没了。
|
 |
34
abcbuzhiming 2021-09-28 10:54:37 +08:00 1
@msaionyc 问题是大公司的架构也不是第一天就按罗马设计建造的，别提什么提前布局，提前布局这个想法就是错的，超级系统都是由最简单的系统逐步迭代出来的，到哪个阶段用哪种架构，2w 用户还真就不配用微服务，一上来就想做超级系统这就是有病，十几年前早有有人批判过这种思维，结果十几年这种思维又死灰复燃了，到什么阶段，干什么事情，上来就想搞大新闻？谁出钱？有人陪你烧着玩那你就去吧，但是更多的例子是规模还没起来，公司先被你这超大规模的系统拖死了
|
 |
35
caixiaomao 2021-09-28 11:19:25 +08:00
用户规模不大的情况下只会根据业务划分，比如用户服务、订单服务这种的，分太细没必要
|
 |
36
LoNeFong 2021-09-28 11:34:29 +08:00
其实不止看用户量吧,也看维护成本
最好的感觉应该是`拆模块` 而不是`分服务`. |
 |
37
libook 2021-09-28 11:59:24 +08:00
不论合并还是拆分，都是可能会走极端的，最终拆成一个函数一个服务或者合并成只有一个大服务，所以如何把握这个度，需要权衡多个方面。
首先任何架构规划都是有寿命的，因为你只能根据经验来预估未来一定时间的情况，而且很可能会遇到外因变化而导致架构规划失去价值，正所谓没有银弹。 比如你可以预估未来一年的需求情况，然后就以一年为寿命来设计架构，然后再根据人事组织架构和业务划分情况来综合衡量应该如何划分微服务，一年后运气好的话可以继续使用，运气不好就重新评估重构计划。 拆分为微服务的目的主要是降低成本，比如人力成本、算力成本、故障损失或恢复成本等，如果达不到降低成本的目的，聪明的老板估计都不会批准方案。 |
 |
38
dwlovelife 2021-09-28 18:19:21 +08:00
微服务的出现，一开始之所以要拆，从来不是一开始就因为技术原因拆的，是业务的发展的带动，导致从技术场景上而言不拆不行了。我所见到的能称的上所谓微服务的（不是那种自己跟自己玩，把业务模块拆几个 module ）。拿电商来说，通常情况下一个服务就基本对应一个部门（这里想表达服务是一个很大的概念不是那么简单的一件事），拿结算提单来说把，最前面的是交易中心（下单的时候跳结算页发起下单流程就是它干的），结算的时候结算页这个页面支付操作一般会有一个支付部门干（提供的就是支付服务），完成支付后，会进行对账（入和出是否平） [财务系统] ，财务系统完成了之后还会有订单中心（订单系统）修改订单状态.........
|
|
39
dwlovelife 2021-09-28 18:21:37 +08:00
所以你看微服务的出现从来就不是为了拆而拆的，它是业务带动的，按我说就楼主所说的业务场景，说实话用单机就够了，为什么？因为成本。所以说我个人认为你们的架构师很不专业。
|
|
40
dwlovelife 2021-09-28 18:24:26 +08:00
再多说一句百分之 80 的软件公司不需要微服务，因为量根本不是那么容易你想上去就上去的，这玩意很多都是程序员要么脑补 要么为了练手。
|
 |
41
mmdsun 2021-09-28 19:06:15 +08:00 via Android
microservice-boundaries：
https://docs.microsoft.com/zh-cn/azure/architecture/microservices/model/microservice-boundaries |
 |
42
abigeater 2021-09-28 21:23:10 +08:00
目前公司也是采用微服务的方式 关于划分的细度我也是和领导吐槽了很多遍。
就用户鉴权这一流程就划分了：用户 /权限 /配置 /菜单 /API/OSS，六个服务。整个登陆流程是：登陆(OSS)/获取用户(User)/用户配置(Config)/鉴权(RBAC)/用户可操作菜单(Menu)/用户可调用接口(API) 这六个服务本地起了后电脑资源几乎满了（也可能的 Hyperf 的问题也得吐槽一下）。 但是用的爽的地方是不用和别人写同一个服务的代码，且出了追踪到问题后找写该服务的人，少了很多的黑锅。 |
 |
43
julyclyde 2021-10-05 15:20:00 +08:00
执行时间长的，比如后台和别的外部系统通信
前后步骤的比例不一样的，比如一次登录、多次查看、少量购买 |
 |
44
lotusp 2022-01-22 11:47:57 +08:00
同意微服务并不是拆的越细越好，微服务架构的实施从某种程度上来说要求是很高的，最好是有完善的自动化部署流程，可以自动发布到对应的环境。小团队维护多个服务本身也是非常痛苦的事情，不仅对于因为拆分带来的额外知识和复杂度需要更高的认知，也会降低开发和维护效率。
分享一篇很早前老马的文章： https://martinfowler.com/bliki/MonolithFirst.html 这篇文章现在看来也并不过时，不能为了拆分而拆分，就像动不动就造个轮子一样，要克制这种冲动。 讨论如何能够控制合理的粒度，或者什么情况下才考虑拆分，我之前写过一篇文章，欢迎交流指正： https://maguangguang.xyz/services-split-in-iterative-development |
Select Language