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