[转] 最近公司在用 Java 重写一个 ruby on rails 应用，我的一些碎碎念。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1518 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近的工作本质上是公司收购了一个海外的创业公司，然后用 java 重写一个 ror 应用。

然后。。诡异的事发生了。。

原代码库目测大约 5-6 个 ruby 程序员的 code base，做微服务架构后，拆分成 5-6 个领域，一个团队 4-5 个 java 程序员。

阿里的大中台小前台概念火了，于是有前台团队做业务，中台团队提供 crud，再来个前端团队，约 80 人，这就算齐活了。

于是整件事朝着魔幻的方向演进了：

由于分布式监控做的不到位，一些同学花很多时间排查线上问题
过早使用分库分表，而且使用姿势不当，接口 SLA 出问题了
中台这边的一个本能是 “考虑通用性”，建模有大量过度设计，于是接口性能出问题了，一些同学玩命优化接口性能
没人说得清楚前台和中台究竟是什么，于是边界划分开始撕逼了，中台说要考虑通用，前台说这个系统不属于中台能力，花了大量时间在需求讨论上
划分不清楚，于是架构师来了，天天在处理域和域之间的划分问题，中台前台的划分问题；其实角色有点像劝架大妈
渐渐地，大家变得忙起来了。。。老板觉得流程需要标准化起来，需求要从前台产品经理流到中台产品经理，开发只根据中台产品经理 “提炼” 出来的需求进行开发，于是大家更忙了。。

在这个过程中，很多人的生产力已经被消磨殆尽。大家开始 996，白天各种开会拉群，晚上干活。但是看各个部门的老板的 ppt，一点不含糊： 通用能力服务各个业务场景、功能可以灵活拼装、定义标准能力、赋能业务。 各种描述都齐活。

但回到问题本身。这家公司，原来只是一个只有二十几个，甚至几个人干起来的产品，一个单体应用可以创造一个估值几百万的公司，我是感觉被降维打击了。

去大厂感受摩擦力；去小厂感受生产力。想起来已经 4 个年头没有做 rails 开发，最近突然遇到 rails 实打实的生产力的降维打击（尽管语言因素可能只占部分）。有点感慨。现在看来，普通的 web 应用，rails 还是将程序员的代码直接转化为生产力和产品力的大杀器。

Rails

前台

生产力

Java

51 条回复 • 2020-11-03 18:37:57 +08:00

chendy

2020-11-02 16:54:53 +08:00

强行拆微服务、强行搞中台是这样的
都是大厂架构师吹逼的东西，没场景没能力看个乐就行，谁上谁那啥…

dk7952638

2020-11-02 17:00:59 +08:00

首先这肯定夸张的成分比较大，吹 ROR 是真的
对于国内大厂来说，招聘 10 个 Java 比招聘 10 个 Ruby 要简单太多，而且 Java 明显可以更好的压榨生产力

echo1937

2020-11-02 17:09:18 +08:00

就算以前是 Spring 一把梭的，按文中的改法也照样出问题。

强行微服务，强行中台就是这样子的，一路趟坑。

acmore

2020-11-02 17:13:41 +08:00

之前的一个评论在在这再贴一下:

> 其实确实没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分> 的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 > Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活> 不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。

表面是 Overdesigning, 实质是 KPI Oriented Programming.

acmore

2020-11-02 17:14:28 +08:00

@acmore 格式乱了。

没有必要为了微服务而微服务，虽然有很多理论指导和论证，但是真正应用的时候大多都是趟泥地。当拆分的好处远大于不拆分的坏处时自然就会拆分，而很多情况下微服务都会显著增加开发和维护成本。项目首先还得是个 Monolith 或者至少是有演化成为 Monolith 的趋势，这个时候开始制定拆分策略应该是比较合适的，很多项目大概都活不到这个时候。当然大多数时候都是拍板者拍板，干活的执行。

表面是 Overdesigning, 实质是 KPI Oriented Programming.

Rwing

2020-11-02 17:16:48 +08:00

java 是这样的……我这也有一个案例，一个 C#的项目，原本 1.5 个人好好的，然后某个大佬心血来潮说要 java 重构，业务规模没变，现在要 7-8 个人忙前忙后……

acmore

2020-11-02 17:20:27 +08:00

@Rwing Java 相比 C# 确实会啰嗦很多，但不至于差别这么大，估计是用了体量不对等的框架和设计理念吧。大事有大框架，小事有小框架或者不用框架，而在人们写 Java 时习惯性地都用大框架（包括我自己）。

cmdOptionKana

2020-11-02 17:23:44 +08:00

但是 ruby 性能真的差啊，业务发展起来之后重写成别的语言也很正常。最主要的问题可能是缺少一个擅长 Java 的 CTO，才导致各种问题。

zhuangzhuang1988

2020-11-02 17:26:17 +08:00

@acmore https://bilyachat.com/blog/language-similarities C#大法好..

KuroNekoFan

2020-11-02 17:27:10 +08:00

用 java 就是容易把简单的事情弄复杂，that's it

acmore

2020-11-02 17:29:07 +08:00

@zhuangzhuang1988 我是同意的，毕竟我司出品。

BBCCBB

2020-11-02 17:59:55 +08:00

这和 java 还是 ror 没啥关系,, 主要是你们拆拆拆, 过度设计了吧??

zhuangzhuang1988

2020-11-02 18:07:21 +08:00

@acmore 微软牛逼

gowk

2020-11-02 18:12:46 +08:00 via Android

“中台，我信了你的邪” https://36kr.com/p/1725013082113
这篇文章不错，一个字一个字的看完了

jones2000

2020-11-02 18:59:21 +08:00

说实话，有活干，管他干什么呢，工资照发不就可以了。亏的都是投资人的钱，爱怎么重写就怎么重写，给足加班费就可以。钱烧完了，换一家。简历也好看，重构，微服务，中后台等等概念都有了。

WispZhan

2020-11-02 19:51:06 +08:00

最讨厌那种半吊子架构师。啥都不知道就夏几把推微服务、拆微服务的。另外不会写代码的架构都是水货，有的架构是会写代码但是没时间写，有的是写都不会写就莫名其妙的是架构了。

hoyixi

2020-11-02 19:54:51 +08:00

很多时候搞事，不是为了事本身。人员重组，重立山头，立威望，分权力，抢话语权，这才是那些管理层关心的。

back0893

2020-11-02 20:01:45 +08:00

为了拆分而拆分...

nnws2681521

2020-11-02 20:06:54 +08:00

不就一个网页吗，搞那么多英文装逼吗

EminemW

2020-11-02 21:54:32 +08:00

这关 java 什么事，这明显是架构设计问题

Cbdy

2020-11-02 23:15:20 +08:00 via Android

java 社区过度设计确实挺厉害，混子可能也相对其他技术栈多一些，我也贴一篇文章
https://yuheng.io/articles/i-hate-java

impl

2020-11-02 23:35:22 +08:00

阿里巴巴董事长兼 CEO 张勇在湖畔大学分享时也说：如果一个企业奔着中台做中台，就是死。
--- 划重点，要考

xuanbg

2020-11-03 00:07:34 +08:00

@cmdOptionKana 不不不，擅长 Java 并没有什么卵用。 @KuroNekoFan 这也不是什么语言的锅，只是没有找到正确的方法而已。

楼主的问题是没有人去把整个系统的结构梳理清楚，导致各项目搞不清楚自己的定位，和别的项目是一个什么关系。大家都按着自己的惯性思维去做事，没有纲领，也没人负责协调，出现冲突很正常，没有冲突反而不正常。

这种情况下搞微服务只是把单体架构掩盖的问题给暴露了出来而已。当然你要说没有暴露出来的问题就不是问题我也没法反驳的说🐶