CEO 觉得微服务部署极其繁琐，什么 nacos 、mq 、redis 都好复杂，远不如零几年的开发一条龙从后台到前端那么简单。
要求把十来个微服务(用户、订单、后台、网关等）合并成一个。
简化部署，只一台机器搞定。
试问，这种单体程序最后以怎样的方式崩溃。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 526 days ago, the information mentioned may be changed or developed.
 |
101
javalaw2010 Jan 20, 2025  2
我觉得一家公司如果在技术架构上使用单体还是使用微服务有争议，那大概率就不必使用微服务。
|
 |
102
guotie Jan 20, 2025
毫无问题
单体为啥不能扩展？？？？ |
 |
103
zen1 Jan 20, 2025
先搞懂什么是单体，什么是微服务吧。微服务不是银弹，单体也不是什么 low 货！
|
 |
104
xuelu520 Jan 20, 2025
看着我 source tree 里面的 20 多个微服务项目，开发一个需求涉及 N 个服务，太鸡儿麻烦了
我司部门什么东西搞个微服务，有点为了微而微的感觉了。 |
 |
105
Pdk5a8759cbeD6CH Jan 20, 2025
@mbeoliero123 单体是指把所有服务揉进一个项目吧，又不是单机不能搞负载均衡。你微服务不搞多台机子 流量大的时候也扛不住啊。
|
 |
106
Gll910802 Jan 20, 2025
@lqw3030 的确，我们目前就这么处理的。想 all in one ，就单独启动一个 jvm 引入所有包的那个工程。想微服务，就各自模块单独工程单独 jvm 启动
|
 |
109
tongqe Jan 20, 2025 1
要看自己的系统是否是复杂系统，复杂系统中的每个元素的行为和关系是不一致的，比如几个关键指标，高可用，高吞吐，高扩展花成一个三维坐标轴，比如银行的交易服务，对高可用，高吞吐要求极高，而一些统计模块的实时性要求没那么高。这种元素之间的差异性是天然存在，无法避免的，自然要拆分。如果再带入组织架构和人类协作的方式上，拆分微服务是当下比较合适的方案。至于楼上一些帖子说，spring 和 Java 作为基础设施占用内存的问题，其实是优先级非常低的问题
|
 |
110
runlongyao2 Jan 20, 2025
docker 把服务部署到一台机器，这样要改的少点
|
|
111
runlongyao2 Jan 20, 2025
@yinmin 哪儿那么多百万级的业务...如果有，迁出来这一个单独部署和维护就好
|
|
112
Pdk5a8759cbeD6CH Jan 20, 2025
@hdfg159 # 90 这种情况微服务和单体没任何区别，我们的微服务的数据库、proto 文件，项目地址都拆分开的，负责用户服务的就拉用户服务的代码。
|
|
113
runlongyao2 Jan 20, 2025
|
|
114
Pdk5a8759cbeD6CH Jan 20, 2025
@yinmin 单体和用不用消息队列有啥关系？难道单体的都没有处理过购买未付款，然后等 20 分钟自动取消订单然后归还库存的业务吗？
|
 |
115
fcten Jan 20, 2025
如果这些功能只要 3 ～ 5 人一个团队就能维护，单体服务并没有什么问题
|
|
116
runlongyao2 Jan 20, 2025
@keller 老兄明白人
|
 |
117
uRQDd07Pt2UWOtOF Jan 20, 2025
单体系统为了解决自身的各种内部问题，分化为多个微服务系统，当各个问题解决解决后，又合并为一个新的单体系统，螺旋型进化，往复这个循环
|
 |
118
lvlongxiang199 Jan 20, 2025
shopify 也用单体. 贵司的业务比 shopify 更复杂 ? 为啥他们的单体没崩 ?
https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity https://shopify.engineering/shopify-monolith |
 |
119
harry90 Jan 20, 2025
业务量如何 增长如何 多大规模 未来预期如何 什么样的团队 任何架构选择都可以考虑实际情况
|
|
120
runlongyao2 Jan 20, 2025
@ryalu 微服务最大问题就是，容易导致成本失控，这种失控不像项目失败一样，它是隐形的。
|
|
121
runlongyao2 Jan 20, 2025
@cj323 应用每增量了，微服务的成本问题就显现出来了
|
 |
122
dxddd Jan 20, 2025
组织即架构。
如果公司技术团队几个人，那么单体服务是比较合适的；如果达到 10 人，那么建议拆成两三个服务。 基本上每三个人维护一个服务是比较合适的。 |
 |
123
pangzipp Jan 20, 2025
不要迷信微服务。
康威定律： 软件系统的设计往往会反映出其所处组织的沟通结构。 |
 |
124
CareiOS Jan 20, 2025
用 golang 吧
|
 |
125
bk201 Jan 20, 2025
看你业务，组织架构是怎么样的吧。一般小公司确实不需要微服务，微服务和崩溃没必然联系，单体也是可以多机部署的
|
 |
126
yiyiniu Jan 20, 2025
@xhwdy26 楼主，CEO 觉得微服务部署繁琐，是因为没找到好的管理服务的工具。看下这个，完全免费，管理微服务非常方便简单： https://www.toutiao.com/article/7314207015789593122/ 开发部署环境时，再也不用安装 JDK 、Nginx 、Redis 、MySQL 等服务了
https://www.toutiao.com/article/7314842204491645440/ |
|
127
GBdG6clg2Jy17ua5 Jan 20, 2025
用单体还是用微服务是看团队人数的多少决定的。
1.你们几千个人了，肯定是按职能，各个团队开发自己的服务。微服务还是挺好用的。 2.如果你们只有几个人，那还是单体吧。微服务没必要。 |
 |
128
yooomu Jan 20, 2025
微服务是一种拆分的思想。当业务和项目规模扩大之后，为了在某些高压力的模块上能够做到水平扩展，自然会将这个模块拆成无状态的子服务，随之就会引入 mq 等中间件用来同步状态和通信。为了能够降低服务间调用和配置管理的负担，就会引入了配置中心和注册中心。微服务化是一种循序渐进的过程，上来就全盘微服务，成本太高了。楼上说的单体项目集群部署，不也是微服务的思想吗。所以项目刚开发的时候应该做好模块分割，模块间通信尽量做成事件机制，为以后可能的微服务改造打好基础
|
|
129
GBdG6clg2Jy17ua5 Jan 20, 2025
单体程序不代表会崩溃。
单体和单机是两个概念。单体也可以通过 nginx 之类的负载均衡，部署几百台机器。某一些机器挂掉，服务是不会挂的。 |
 |
131
Yukineko Jan 20, 2025
规模大了才需要微服务，不要为了微服务而微服务
|
 |
132
JoeDH Jan 20, 2025
单体，然后堆机器
|
 |
133
gg2018 Jan 20, 2025
@kk2syc #33 兄台，4 核 8G 的机器，php 再怎么优化，也达不到 并发上万啊，况且还是业务性质带 db 的服务器，估计是日浏览量上万 pv 吧？
|
 |
134
8355 Jan 20, 2025
如果业务总量上限一直保持在可控不增长的阶段，其实单机更好更省钱，单机是部署，单并不是单体应用，这样构建一次太慢了。
单体应用到最后就是 64 扩 128 128 扩 256 会有点肉疼，而且只能全部停机扩，哪怕其他非关联业务也得停机。 他不懂这个所以感觉单体好，你等到他花钱的时候他就知道了。 |
 |
135
CoderLife Jan 20, 2025
之前接到一个维护项目:
公司内部使用的, 10 来个人用的 erp, 用 java 开发的, nacos, springcloud......上上下下一共 7,8 个服务, 结果所有服务都部属到了一台服务器上, ------- 看到头都炸了, ------- 已用 nodejs, 重构成单服务了 |
 |
136
iv8d Jan 20, 2025 via Android
没有需求我们就制造需求，中小服务单机完全够用，那你想过大项目需要横向扩展吗
|
 |
137
ala2008 Jan 20, 2025
我们公司另一个部门因为服务器资源不够，改为单体了，也不用 docker 了，的确省资源😂
|
 |
138
fffq Jan 20, 2025
单体最大的问题是单点故障，能接受就用
|
 |
139
ichou Jan 20, 2025
Q: 如何合并成单体，几个人同时在一个项目上开发的冲突怎么解决？
A: 各干各的就 git flow ，频繁冲突就 Trunk-Based Development Q: 如果合并成单体，启动时间会增加，开发调试不方便，怎么面对这个问题？ A: 单体也可以模块化，除了 core 之外其它模块都是可插拔的，启动你需要的模块就好了 Q: 如果合并成单体，某个模块要拉分支，应该怎么处理这个问题？ A: 不应该任何开发都拉分支么？直接在 dev or main 上开发？ 如果你指的是定制化的非通用需求，那就拉分支让它永远待在分支上好了，不是的话可以考虑 feature toggle |
 |
140
huijiewei Jan 20, 2025
一个单体如果编译时间超过 15 分钟就可以考虑拆成微服务了。不然还是单体方便
|
 |
141
v1 Jan 20, 2025
@gg2018 一看就知道兄弟你没经历过 PHP 黄金时期，实际 rps*3.5=并发，不然说出去自己都觉得很丢人，还怎么给老板画饼？（当年真要 10k rps ，我早财务自由了，唉）
|
 |
143
jeesk Jan 20, 2025 via Android
有些服务适合做微服务， 前台 to b ，c 流量 n 倍大于管理后台， 难道崩了全部一起蹦？
|
 |
144
yvyvyv Jan 20, 2025
单体就是所有业务集合在一个项目里吧，微服务主要是拆分业务将不同模块分配给不同项目组来完成。最后对接在一起，其实要是一个人搞微服务作用不大，什么 mq redis 网关 单体也可以搞啊。用户量大 资源占用多 甚至到瓶颈，单体也可以横向扩展搞负载均衡啊 同时也可以做到容灾。 其实我感觉是怎么舒服怎么来没必要硬上微服务。
|
 |
145
AlexBob Jan 20, 2025
|
 |
146
iyiluo Jan 20, 2025
很多内网用的系统，撑死也就几百人在用，这点数据就没必要用微服务了
|
 |
148
AlexHsu Jan 20, 2025
其实本来就应该单体化 随着系统复杂度增加上 istio k8s 把压力给到运维 让运维有点活干
把微服务的压力都给带代码太蠢了 |
 |
149
Dlin Jan 20, 2025
问题 1:
冲突问题，首先解决规范问题，统一好项目使用的 ide ，代码样式 style.xml 。ide 设置，避免误格式化等。 |
|
150
Dlin Jan 20, 2025
问题 1:
冲突问题，首先解决规范问题，统一好项目使用的 ide ，代码样式 style.xml 。ide 设置，避免误格式化等。 然后是规范提交问题，细化提交内容，勤提交勤拉取。 问题 2: 启动时间增加应该不会太多，推荐结合热部署（比如 jrebel 做开发） |
 |
151
gowk Jan 20, 2025
大部分系统都没必要微服务化，Postgres 就可以搞定很多事情
Just use Postgres for everything: https://news.ycombinator.com/item?id=33934139 https://github.com/Olshansk/postgres_for_everything https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb |
 |
152
mooyo Jan 20, 2025
@sagaxu #63 你要说能不能那肯定都能，但现状不是这样的。
现状就是，大多数互联网大厂的业务，连 interface 抽象都没有，直接往里面硬塞的业务代码。这就是现状，在这个现状下，微服务直接写一坨新的屎上去替换就是比单体更方便更安全更可控。 |
|
153
mooyo Jan 20, 2025
@mooyo #152 而且就国内这波微服务浪潮，实际上我理解和 golang 的流行也是相辅相成的，在这个环境下用 golang 拉屎就是比之前那套单体写法更方便。
|
 |
154
JosephYin01 Jan 20, 2025
听起来不是微服务的问题, 是你们部署方式的问题
|
 |
155
cstj0505 Jan 20, 2025
上面一些人还停留在什么年代?
单体用不用 k8s?单体就不能 k8s,就不能无状态水平扩展?就不能用 mq?就不能按需再拆分出来. |
 |
156
csfreshman Jan 20, 2025
单体和所有服务微服务是两个极端，应该是按照模块梳理合并，减少服务量，你们这个如果太复杂的化，搞成单体化似乎也没有太大毛病，因为之前过渡吹捧微服务话，很多人都是硬着头皮上的。
|
 |
157
outyua Jan 20, 2025
@ruxuan1306 康威定律
|
 |
158
xiapipi Jan 20, 2025
开发团队人数不多。使用的用户不是非常庞大。单体项目绝对足够。99.99%的项目单体绝对搞定。
|
 |
159
yuxian Jan 21, 2025
不得不说，你们老板很明智，干脆去掉 java ，采用 nextjs 体系，前后端一把梭哈。成本极限压缩。哈哈
|
 |
160
srwxyz Jan 21, 2025 via iPhone
还是业务规模往下走了，如果还在上升，肯定不会有这感觉😂
|
 |
161
Hudiebbk Jan 21, 2025
我这边新项目如果需求那边没有明确说,我一般都是单体服务,但是提前会划分好模块,等后面真需要拆,写个 main 函数就拆出去了,前期快速上线验证业务
|
 |
162
forbreak Jan 21, 2025
我记得微服务刚出来是为了解决，旧的系统的技术债务，异构系统的问题。然后后面业务再慢慢迁移到一起。 但是不知道怎么就变成微服务一把梭了 。 能有人力物力把系统迁移到单体服务，肯定不需要微服务了。 单体也有负载均衡。
|
 |
163
LDa Jan 21, 2025
干过 ， 合成一个单体打包发布 ， 共享 tomcat session 进行集群部署
稳定的一批 |
 |
164
7beloved Jan 21, 2025
我们小公司没玩微服务，但是都是分布式的，简单说，开发语言比开发人员还要多。后端语言就是 py,go,java,proto,node 了，一共三套环境，玩的阿里云的 k8s ，每个月成本十分高，服务器总资源大概是 400 多 G ，3 台 64 ，6 台 32 的服务器资源，还不算其他的一些小型服务器。架构层面的定义，跟领导的能力有很大的关系，很多领导都是为了用二用，到了开发实现这里就很头痛，每个单独的服务都要对应一个 bff ，问题是 TM 的公司前端不愿意写 BFF ，我真 C 了
|
 |
165
Eliefly Jan 21, 2025
很多公司业务单体架构已经足够满足需求，没必要为了微服务而微服务，收益没看到成本一大堆。
|
Select Language