转载自 https://ruby-china.org/topics/40526
最近的工作本质上是公司收购了一个海外的创业公司,然后用 java 重写一个 ror 应用。
然后。。诡异的事发生了。。
原代码库目测大约 5-6 个 ruby 程序员的 code base,做微服务架构后,拆分成 5-6 个领域,一个团队 4-5 个 java 程序员。
阿里的大中台小前台概念火了,于是有前台团队做业务,中台团队提供 crud,再来个前端团队,约 80 人,这就算齐活了。
于是整件事朝着魔幻的方向演进了:
由于分布式监控做的不到位,一些同学花很多时间排查线上问题
过早使用分库分表,而且使用姿势不当,接口 SLA 出问题了
中台这边的一个本能是 “考虑通用性”,建模有大量过度设计,于是接口性能出问题了,一些同学玩命优化接口性能
没人说得清楚前台和中台究竟是什么,于是边界划分开始撕逼了,中台说要考虑通用,前台说这个系统不属于中台能力,花了大量时间在需求讨论上
划分不清楚,于是架构师来了,天天在处理域和域之间的划分问题,中台前台的划分问题;其实角色有点像劝架大妈
渐渐地,大家变得忙起来了。。。老板觉得流程需要标准化起来,需求要从前台产品经理流到中台产品经理,开发只根据中台产品经理 “提炼” 出来的需求进行开发,于是大家更忙了。。
在这个过程中,很多人的生产力已经被消磨殆尽。大家开始 996,白天各种开会拉群,晚上干活。但是看各个部门的老板的 ppt,一点不含糊: 通用能力服务各个业务场景、功能可以灵活拼装、定义标准能力、赋能业务。 各种描述都齐活。
但回到问题本身。这家公司,原来只是一个只有二十几个,甚至几个人干起来的产品,一个单体应用可以创造一个估值几百万的公司,我是感觉被降维打击了。
去大厂感受摩擦力;去小厂感受生产力。想起来已经 4 个年头没有做 rails 开发,最近突然遇到 rails 实打实的生产力的降维打击(尽管语言因素可能只占部分)。有点感慨。现在看来,普通的 web 应用,rails 还是将程序员的代码直接转化为生产力和产品力的大杀器。
1
chendy 2020-11-02 16:54:53 +08:00 11
强行拆微服务、强行搞中台是这样的
都是大厂架构师吹逼的东西,没场景没能力看个乐就行,谁上谁那啥… |
2
dk7952638 2020-11-02 17:00:59 +08:00
首先这肯定夸张的成分比较大,吹 ROR 是真的
对于国内大厂来说,招聘 10 个 Java 比招聘 10 个 Ruby 要简单太多,而且 Java 明显可以更好的压榨生产力 |
3
echo1937 2020-11-02 17:09:18 +08:00
就算以前是 Spring 一把梭的,按文中的改法也照样出问题。
强行微服务,强行中台就是这样子的,一路趟坑。 |
4
acmore 2020-11-02 17:13:41 +08:00
之前的一个评论在在这再贴一下:
> 其实确实没有必要为了微服务而微服务,虽然有很多理论指导和论证,但是真正应用的时候大多都是趟泥地。当拆分> 的好处远大于不拆分的坏处时自然就会拆分,而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 > Monolith 或者至少是有演化成为 Monolith 的趋势,这个时候开始制定拆分策略应该是比较合适的,很多项目大概都活> 不到这个时候。当然大多数时候都是拍板者拍板,干活的执行。 表面是 Overdesigning, 实质是 KPI Oriented Programming. |
5
acmore 2020-11-02 17:14:28 +08:00 1
@acmore 格式乱了。
没有必要为了微服务而微服务,虽然有很多理论指导和论证,但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分,而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势,这个时候开始制定拆分策略应该是比较合适的,很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板,干活的执行。 表面是 Overdesigning, 实质是 KPI Oriented Programming. |
6
Rwing 2020-11-02 17:16:48 +08:00 1
java 是这样的……我这也有一个案例,一个 C#的项目,原本 1.5 个人好好的,然后某个大佬心血来潮说要 java 重构,业务规模没变,现在要 7-8 个人忙前忙后……
|
7
acmore 2020-11-02 17:20:27 +08:00
@Rwing Java 相比 C# 确实会啰嗦很多,但不至于差别这么大,估计是用了体量不对等的框架和设计理念吧。大事有大框架,小事有小框架或者不用框架,而在人们写 Java 时习惯性地都用大框架(包括我自己)。
|
8
cmdOptionKana 2020-11-02 17:23:44 +08:00
但是 ruby 性能真的差啊,业务发展起来之后重写成别的语言也很正常。最主要的问题可能是缺少一个擅长 Java 的 CTO,才导致各种问题。
|
9
zhuangzhuang1988 2020-11-02 17:26:17 +08:00 1
|
10
KuroNekoFan 2020-11-02 17:27:10 +08:00 1
用 java 就是容易把简单的事情弄复杂,that's it
|
11
acmore 2020-11-02 17:29:07 +08:00
@zhuangzhuang1988 我是同意的,毕竟我司出品。
|
12
BBCCBB 2020-11-02 17:59:55 +08:00 1
这和 java 还是 ror 没啥关系,, 主要是你们拆拆拆, 过度设计了吧??
|
13
zhuangzhuang1988 2020-11-02 18:07:21 +08:00
@acmore 微软牛逼
|
14
gowk 2020-11-02 18:12:46 +08:00 via Android 5
“中台,我信了你的邪” https://36kr.com/p/1725013082113
这篇文章不错,一个字一个字的看完了 |
15
jones2000 2020-11-02 18:59:21 +08:00 3
说实话, 有活干,管他干什么呢, 工资照发不就可以了。 亏的都是投资人的钱, 爱怎么重写就怎么重写, 给足加班费就可以。 钱烧完了, 换一家。简历也好看,重构,微服务,中后台等等概念都有了。
|
16
WispZhan 2020-11-02 19:51:06 +08:00
最讨厌那种半吊子架构师。 啥都不知道就夏几把推微服务、拆微服务的。另外不会写代码的架构都是水货,有的架构是会写代码但是没时间写,有的是写都不会写就莫名其妙的是架构了。
|
17
hoyixi 2020-11-02 19:54:51 +08:00 1
很多时候搞事,不是为了事本身。人员重组,重立山头,立威望,分权力,抢话语权,这才是那些管理层关心的。
|
18
back0893 2020-11-02 20:01:45 +08:00
为了拆分而拆分...
|
19
nnws2681521 2020-11-02 20:06:54 +08:00
不就一个网页吗,搞那么多英文装逼吗
|
20
EminemW 2020-11-02 21:54:32 +08:00
这关 java 什么事,这明显是架构设计问题
|
21
Cbdy 2020-11-02 23:15:20 +08:00 via Android 1
java 社区过度设计确实挺厉害,混子可能也相对其他技术栈多一些,我也贴一篇文章
https://yuheng.io/articles/i-hate-java |
22
impl 2020-11-02 23:35:22 +08:00
阿里巴巴董事长兼 CEO 张勇在湖畔大学分享时也说:如果一个企业奔着中台做中台,就是死。
--- 划重点,要考 |
23
xuanbg 2020-11-03 00:07:34 +08:00
@cmdOptionKana 不不不,擅长 Java 并没有什么卵用。 @KuroNekoFan 这也不是什么语言的锅,只是没有找到正确的方法而已。
楼主的问题是没有人去把整个系统的结构梳理清楚,导致各项目搞不清楚自己的定位,和别的项目是一个什么关系。大家都按着自己的惯性思维去做事,没有纲领,也没人负责协调,出现冲突很正常,没有冲突反而不正常。 这种情况下搞微服务只是把单体架构掩盖的问题给暴露了出来而已。当然你要说没有暴露出来的问题就不是问题我也没法反驳的说🐶 |
24
kkbblzq 2020-11-03 00:18:31 +08:00
真就为了设计而设计了,这玩意需要有比较多实际的业务沉淀的吧。就一个项目而且还是买来的,整中台纯属领导脑补出来的需求吧
|
25
haohappy 2020-11-03 01:13:20 +08:00
就这样工资才能起来哈
|
27
lrh3321 2020-11-03 08:22:43 +08:00 via Android
多创造了 70 多个岗位
|
28
l00t 2020-11-03 08:58:10 +08:00
大厂创造工作岗位。
花的是老板的钱,积累的是自己的技术和经验,多好。 |
29
drackzy 2020-11-03 09:02:07 +08:00
Ruby 国内很少有人用了,薪资不行没有大厂。写 Java 大厂校招都 22 、24K 了。
|
30
Zatoichi1966 2020-11-03 09:05:50 +08:00
说实话现在大部分公司不都是搞分布式 微服务吗,感觉是你们的经验不足,搞得这么乱,,,
|
31
Zatoichi1966 2020-11-03 09:08:13 +08:00
说实话现在大部分公司不都是搞分布式 微服务吗,感觉是原文作者的公司经验不足,搞得这么乱,,,
|
32
Zatoichi1966 2020-11-03 09:11:24 +08:00
@WispZhan 确实
|
33
coolair 2020-11-03 09:15:33 +08:00
中台到底是个啥玩意?!
|
34
passerbytiny 2020-11-03 09:21:25 +08:00 via Android
就算是扩容后的团队,也才 80 个人,这点规模,拆个狗屁的中台。
|
35
cmdOptionKana 2020-11-03 09:43:50 +08:00 via Android
@xuanbg 也就是说 CTO 水平不行,要么就是故意花公司钱积累经验。总觉得不能怪 Java
|
36
lbp0200 2020-11-03 10:28:08 +08:00 via iPhone
国内通病
|
37
limboMu 2020-11-03 10:38:16 +08:00
其实真正有用的是 DDD,服务拆不拆没啥关系,忙前忙后瞎 JB 搞又不懂的人很多
|
38
molika 2020-11-03 10:51:23 +08:00
喜乐见闻
|
39
zencoding 2020-11-03 11:20:10 +08:00
楼主文字能力不错,再现那个我好熟悉的一幕幕哈哈
|
40
lbp0200 2020-11-03 11:28:44 +08:00
不然那些创业失败,最终负债几百万的人,是怎么来的???
|
41
neocanable 2020-11-03 11:33:01 +08:00
我是个 ruby 程序员,不得不说,做东西确实快,但是随之而来的问题也多。
但是你让我用 java 去重构一个 ror 写的服务,还是有点儿肝儿颤的 |
42
lonelymarried 2020-11-03 11:34:40 +08:00
我一个搞 frontend 的,都知道中台了。
|
44
woshiaha 2020-11-03 12:00:37 +08:00
中台这种东西应该是在业务迭代中逐渐演变出来的 而不是上来直接设计划分出来的
|
45
Kirsk 2020-11-03 12:34:08 +08:00 via Android
这锅 Java 不背 人的问题
|
46
danhahaha 2020-11-03 12:34:35 +08:00 2
以后多几个这种公司,可以解决广大程序员朋友的就业问题。
java 的用 C 重构 C 的用 go 重构 go 的改 php 中台微服务大数据各种新名词一起上,共同推动 gdp |
47
axex 2020-11-03 13:03:37 +08:00
这种应该一步步把之前的某个模块拆出来做一个微服务
|
51
yeahvov 2020-11-03 18:37:57 +08:00
相反 最近 Java 转 ror 了
|