这是一个创建于 449 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先本人是一个 Java 程序员，Java 生态还是比较周全的，像注册中心，配置中心，日志收集，调用链追踪，分库分表等等。
但是我心中突然有一个疑问，为什么一定要用上这些东西，真的有必要吗？比如说注册中心，没有一定的用户量，或者不是容器化，搞什么注册中心？ nginx 转发不是根据高效？还有配置中心？又不是几百上千个应用，才几个应用上什么配置中心。
我发现很多小的创业公司，上来就是搞什么微服务，真的有必要？难度不是徒增资源的成本和维护成本？
我觉得任何中间件都是对应困境中而产物，如果没有遇到这些困境，为了用而用，是不是纯粹的在炫技？
 |
1
jjjjjokerrrr 2023-07-28 17:00:18 +08:00
感觉还是得分情况看：
1. 你认为这个业务之后用的人会很多 2. 你认为这个业务之后会噶了 |
|
2
jjjjjokerrrr 2023-07-28 17:01:22 +08:00
第一种情况，考虑后续服务扩展是有必要的，第二种情况是不是不做了比较好 xD
|
 |
3
csw3983931 OP @jjjjjokerrrr 你说的情况 1 ，我觉得用的人会很多，这个跟单机服务，然后模块的拆分并不影响吧。
我觉得大多数初创公司都是人手不住，要大量需求迭代，微服务只会让发版本和处理业务常见更加复杂和麻烦，当然现在 Java 程序员可以说基本都会一些中间件。但是个人觉得越少越好。 |
 |
4
lisxour 2023-07-28 17:16:10 +08:00
你说的是对的，不管什么量级，总有无脑去搞微服务的
|
 |
5
redial39 2023-07-28 17:17:13 +08:00
只要你确定当业务越来越发展以后,你的项目越来越多以后,运维天天来找你麻烦给你小鞋穿以后不会有 "当时应该上配置中心,现在不至于这么狼狈" 的决心的话..你就可以一个 jar 走天下
|
 |
6
coderxy 2023-07-28 17:26:25 +08:00  2
你说的有一定道理，其实如果只是要求够用的话，一台单机跑个 jar 就可以对外提供服务了。
但是很多程序员是按照自己的习惯来的，很多原来一直用微服务体系用惯了，你突然让它搞单机应用，他不一定能快速适应。 所以，只要开发者认为自己是在以较低的成本快速展开业务就是最正确的方案。 有没有微服务都可以是最正确的方案。 |
 |
7
wangxiaoaer 2023-07-28 17:27:07 +08:00 1
是的，有一点过度设计的感觉了。 之前看过一个帖子说到自己 04 年左右开发的一个 Java Web 应用，打包成 jar 格式，这么多年过去了，jre 环境满足的话可以分分钟部署上去就欢快的跑起来了。
现在随随便便搞个什么应用不搞几个微服务都跟瘫痪了一样，更有甚者 p 大点应用还他么上 k8s 的。 |
 |
8
wu67 2023-07-28 17:29:05 +08:00 8
每次说到业务发展到什么量级我就想笑.
大部分人写的项目, 可能巅峰时期也就千把人同时访问, 甚至很多是个位数访问, 讲什么微服务呢... 极端一点, 可能很多公司倒闭了, 这个项目的同时访问量也上不了几百人. 更极端一点, 可能没几年, 因为技术栈老旧难以维护, 又招了一批人来开一个新的项目推倒重来了 题外话, v 站这摸鱼大站, 网站底下的在线人数, 此刻是 4833 |
 |
9
kamalei 2023-07-28 17:32:37 +08:00 1
不用，你下一份工作怎么吹。
|
|
10
csw3983931 OP @redial39 我觉得项目越来越多，这是一个因素，到达一定量后必然会增加人手，然后服务拆分，然后再考虑是否引进微服务的中间件。
|
|
11
csw3983931 OP @coderxy 我觉得一直没有使用过微服务的程序员去写微服务的项目会有压力，有微服务经验的程序员，写单体应该是有一种如释重负，很轻松的感觉，因为考虑的场景少了，比如分布式事务，任务调度中心，一致性等等
|
|
12
csw3983931 OP @wangxiaoaer 是的，依赖的太多中间件，导致重新部署一套，无论是成本还是资源都是要 copy 一份，而且一旦漏了一个环节，就可能无法正常运行。属实感觉微服务要慎重
|
|
13
csw3983931 OP @wu67 是的，我感觉中国大多数初创企业都是这样的现状。而且单体服务优化的好，机器和资源跟上，几十万的用户量还是轻轻松松的。
|
|
14
coderxy 2023-07-28 18:06:59 +08:00
@csw3983931 很多业务开发，只是习惯与在某个框架下开发。 比如习惯了使用（甚至只使用过） spring cloud 的框架，然后各种组件都是用现成的。 你让他去写单机，他不一定能很快适应。
微服务不是啥高阶功法，只是一种技术方案而已，过度仰视或鄙视一种技术方案，都是不合理的心态。 只有当一个技术人员，可以游刃有余的使用任何一种技术方案完成业务时，他才能真正的根据业务需求，选择最合适的技术方案。 不然假如你不会微服务，然后跟公司其它同事说我们不需要微服务巴拉巴拉。 其它人嘴上不说，心里肯定吐槽。 |
 |
15
lambdaq 2023-07-28 18:11:18 +08:00
。。。。。php python ruby 就是这样从当年 J2EE 抢的市场份额啊。。。你以为呢。。。。。
|
 |
16
pengtdyd 2023-07-28 18:17:19 +08:00
因为面试的要求，面试的时候向面试官展示自己华丽的造火箭能力能更容易的从应聘者中脱颖而出。如果不这么做，其实是会在就业市场中被淘汰。
|
 |
17
wu00 2023-07-28 18:19:32 +08:00
都说缺点，我来说优点
- 拿公司项目练手 - 降低解释成本，避免给老板、同事解释为什么咱们没有用这些专业的、高大上的、牛逼的新技术 |
 |
18
zsdroid 2023-07-28 18:57:04 +08:00
如果项目中不用，面试问到了一问三不知怎么办？
|
 |
19
tomatocici2333 2023-07-28 20:12:47 +08:00
没办法 现在你的项目不是分布式，你都要改成分布式的...不然简历这关都过不了 hr
|
 |
20
paradoxs 2023-07-28 20:17:50 +08:00
这些东西很水，没一个稳定的发展方向。 所以现在程序员的就业环境才显得这么的难。 因为没有东西可以量化你的能力。
|
 |
21
LeegoYih 2023-07-28 20:22:10 +08:00
让你写单机应用，你又会嫌弃没技术含量。
|
 |
22
kingjpa 2023-07-28 21:09:14 +08:00
其实绝大部分应用 实时用户量都不会上万。
|
 |
23
agagega 2023-07-28 21:11:39 +08:00 via iPhone 1
分享一下这篇文章，如果你是做自己的项目，真没必要上分布式那一套徒增复杂度： https://ruby-china.org/topics/39735
> 随着越来越多的人们意识到对于微服务的追逐会走上一条死胡同，“钟摆将会再摆动回来“。“雄伟巨石”在这儿等待着微服务的“难民”。如果他们确实做到了大型应用程序的规模，那么“城堡”这种可以扩展的模式足以让你安心。 |
 |
24
xuanbg 2023-07-28 21:18:51 +08:00
几行命令的事，有什么维护成本？
|
 |
25
hooych 2023-07-28 21:28:17 +08:00
各大云厂商都有现成的产品可以接入，用户只需要关注业务服务即可。
|
 |
26
James0 2023-07-28 21:54:00 +08:00
因为你可能还不熟悉使用,或者公司基建太辣鸡
|
 |
27
winglight2016 2023-07-28 23:13:23 +08:00
如果 lz 试过开发一个长期运行使用，并且需要经常修改维护的系统就明白为什么要上配置中心、容器化、微服务了，一切都是为了可维护性、稳定性。
|
 |
28
Ericcccccccc 2023-07-29 01:10:56 +08:00
好, 假设你不用配置中心, 那你实现相关功能要怎么做呢?
(最后变成自己实现了一个配置中心? |
 |
29
wushenlun 2023-07-29 01:22:02 +08:00
用现成方案才是最节省成本的 ，自己手搓代码可劲折腾去吧
|
 |
30
IvanLi127 2023-07-29 01:54:47 +08:00 via Android
我说个比较极端的话，有一部分公司，尤其是小公司选 java 做技术栈本身，就是为了招人省事，开发省事，所以如果用上了很多对程序本身没多大益处，反倒是很累赘的组件，也可能是出于省事。
反正现在硬件成本低了，堆一堆东西，性能差点加配置就是了。。。我感觉追求程序简约高效的开发者，应该不怎么会选中 java 了吧。。。 |
 |
31
Bingchunmoli 2023-07-29 02:59:56 +08:00 via Android
有可能是你做了可以买 20 万不做不能宣传集群微服务什么话术只能买 8000
|
 |
32
qinxi 2023-07-29 08:41:24 +08:00 via iPad
我们的主服务现在就是单 jar 跑，今年收入应该有几千万了
我们的 global 团队是微服务。不过国内版本目前不打算用，没必要 |
 |
33
ikas 2023-07-29 08:58:52 +08:00
原因=>垃圾公司垃圾老板垃圾人
|
 |
34
cquan 2023-07-29 09:42:54 +08:00
被迫卷的
|
 |
35
laozhoubuluo 2023-07-29 10:02:43 +08:00
1. 有的需求提供方对自己预期比较高，例如觉得自己能冲用户量或者以后要学习微信搞大而全。需求侧定了调子之后架构必然要按照需求来实现。比如定了个用户数或者交易量一年冲千万、三年破亿的指标，不搞服务拆分可能才是架构失职。
2. 如果您是面试官，在现在这个大环境下没有微服务、注册中心应用经验的中高年资员工您会考虑录用么？如果大多数面试官都不考虑的话，那也别奇怪大家为啥要往微服务、注册中心上靠拢了。 |
 |
36
learningman 2023-07-29 10:45:42 +08:00 via Android
threads 还是 python 写的呢，优化啥啊
|
 |
37
silentsky 2023-07-29 12:06:18 +08:00 via Android
单体应用确实没必要 如果两个服务以上那肯定需要这些 又不是什么很难的东西
|
|
38
silentsky 2023-07-29 12:10:09 +08:00 via Android
配置中心没你说的不堪 比如你想动态改一些配置不用重启服务生效 就很有用。有些敏感数据放在配置中心肯定更安全些
|
 |
39
evalcony 2023-07-29 12:20:46 +08:00
1. 提高招人门槛。
2. 招聘的双向选择。水平好一点的人看你们还是个单体应用，可能就不乐意过来了。 |
 |
40
agdhole 2023-07-29 12:30:44 +08:00
某个游戏平台公司流水过亿，所有东西都是单机撑住，没有任何高级的架构，甚至连专业运维都没有。所以单机其实是很强大的。
|
 |
41
leegradyllljjjj 2023-07-29 13:40:09 +08:00
我微服务容器化 k8s 都上了，怎么没人来访问啊，老板你说句话呀
没有淘宝的命得了淘宝的病 |
 |
42
salmon5 2023-07-29 16:17:53 +08:00
你说的对的，不搞这些怎么搞 KPI 呢？怎么拿公司联手呢？反正代价也是公司付出。
大多数人在一个公司也就 1-2 年，练完手，拍拍屁股就走了 |
 |
43
bigbrother 2023-07-29 16:31:45 +08:00
为了写简历啊
|
 |
44
daimubai 2023-07-29 16:37:09 +08:00
嗯，其实单体项目完全足够了的，再加两台服务器部署个集群也完全可以的。
|
 |
45
nkidgm 2023-07-29 17:07:53 +08:00
其实很多玩微服务的人连单体应用都还没玩明白。。。
|
 |
46
ClericPy 2023-07-29 17:26:51 +08:00
没有三年以上运维给你支撑, 用任何第三方中间件都是在给接手的人添乱
尤其是连服务治理都不做的情况下滥用微服务, 年份越大灾难越重 |
 |
47
angryfish 2023-07-29 17:36:47 +08:00
如果后端开发就 3,5 个人的话写微服务拆分得太细会很痛苦。对于小公司，从公司角度还是建议一个单体 jar 走天下。
但对于个人发展，当练手吧。 |
 |
48
brookegas 2023-07-29 20:53:19 +08:00
这已经是公开的秘密了
其实道理都懂，以用户量来看根本用不上注册中心、分库分表这些花活 但是大家都这么玩，把简单的应用工作量放大了好几倍 好处是经济上行时多了几倍的码农岗位，高薪摸鱼乐无边 坏处是拉低了效率，经济下行时企业死得快，码农跟着一起堕入深渊 |
 |
49
ashuai 2023-07-29 21:10:14 +08:00
公司去投项目，项目一般不大，2C4G 的物理机足以支撑，但那帮不懂的麻瓜好像感觉中间件用得越多越牛 x 。搞安全的都不知道缩哪去了
|
 |
50
jiangzm 2023-07-29 21:22:06 +08:00
小公司上微服务倒不一定有问题，就怕瞎拆分几个人能拆 10 几个服务，除了浪费资源也没太大实际好处。
|
|
51
xuanbg 2023-07-29 21:45:01 +08:00 1
微服务从来没有说要多少用户量才值得上，微服务主要解决的是系统复杂度的问题。解决量的问题，是分布式系统的事，只不过微服务天然就支持分布式而已。
所以，只要系统比较复杂，哪怕只是为了能够方便维护和扩展功能，只要会用一些 devOps 工具，譬如会简单使用 k8s 来解决运维领域的问题的话，微服务就是最好的解决方案，没有之一。 我上个月接了个活，才 6w 。如果我从无到有给他搞单体服务，估计 2 个月才能搞得定。而采用微服务方案，上线时间就变成 20 天了。 |
 |
52
tin3w5 2023-07-29 22:37:32 +08:00 via iPhone
格局小了，你只是从你的角度来看，他是个小微企业，从老板的角度来看，万一以后要扩容呢？客户量大了，需要拆的时候再重写？
与其未来 capacity 不足的时候手忙脚乱的拆服务，不如初期设计的时候就做好，免得以后麻烦。 咱们都是搞技术的，没必要过多干涉上面的决策。他们搞多大项目，咱们要多少钱，只要钱到位，什么花活咱都会。 |
 |
53
diagnostics 2023-07-29 22:48:12 +08:00
因为留有扩展的余地吧，拿基金头部的软件恒生来说，他们的 o32 也是单体，和你们的思路一样，单体做到极致，后果就是：
1. 很多功能没法加，代码已经非常庞大了 2. 扩展性非常差，只能一直堆最好的硬件 1 、2 都导致了很多功能做在其他系统，导致恒生和其他第三方厂商做的系统没啥区别。 恒生自己也在做 o45 ，然后就落后别人了，很多券商也在做去恒生化了。当然未来可能不一定 所以，为什么要搞这些？当然小公司，没发展空间就可以没必要了，另外其实新技术挺方便的，尤其是 有一套 k8s 对于开发来说，测试非常方便，压测也很方便。 |
 |
54
olaloong 2023-07-29 23:18:54 +08:00 via Android
都是成熟的东西，使用成本没你想得那么高，顺手就用上了
真等后期需要了再改，那成本可高多了 |
 |
55
akira 2023-07-30 00:20:35 +08:00
你要是说小的创业公司的话，那可以 php 一把梭 验证商业模型
去到一定量级以后再用 java 整体重构 |
 |
56
snBDX1b0jJM4ogKd 2023-07-30 01:38:34 +08:00 via Android
有没有可能，对他来说，一个 jar 就默认搞定了这些东西，部署也是驾轻就熟。
如果因为项目太小，非要让他重新搞一个精简的出来，他的工作量可能更多。那不是另一个角度的过度设计？ |
 |
57
jdOY 2023-07-30 03:16:35 +08:00
老板说要什么你就搞什么
|
 |
58
gejun123456 2023-07-30 09:37:04 +08:00
没必要，小公司弄单体应用就行，做大做强再优化
|
 |
59
murmur 2023-07-30 10:07:15 +08:00
中间件就是 tomcat ，你不会连这个都不知道吧
|
|
60
murmur 2023-07-30 10:07:27 +08:00
更正：tomcat 就是中间件的一种
|
 |
63
lanlanye 2023-07-31 02:06:52 +08:00
优点当然也是有的：
1. 可以练手，不然你下一份工作的简历怎么办？ 2. 容器化管理起来确实容易，哪怕我就俩服务，用 k8s 也方便些，至于你说消耗的资源……那是老板的钱，又不是我的。 3. 战未来，万一火了呢？ 4. 微服务不仅能拆分大型软件，还能方便拆分团队，如果一个项目有很多个组参与，使用微服务会比写成单体然后让大家工作在同一个仓库下容易些……同理，如果前提是没几个用户，进程内通信和跨进程通信相比那点优势也微不足道。至于额外的复杂度，k8s 也基本能解决，没几个用户的项目又能复杂到哪儿去呢？ |
 |
64
javaZhenJuan 2023-08-04 11:28:18 +08:00
@qinxi 大佬您是做什么业务的
|
|
65
javaZhenJuan 2023-08-04 11:29:42 +08:00
@salmon5 说到点子上了
|
Select Language