十几年不搞 Java ,重新看起了微服务

2020-06-27 13:34:04 +08:00
 skyworker
十年内前搞过 java,当时主要搞得是 hibernate, spring,webwork 之类的 J2EE 框架, 后来工作后转行金融证券. 5 年前恢复搞 IT, 一直用 laravel, 相对于十年前 J2EE 的啰嗦, 觉得 laravel 非常不错.


最近接收一个项目, 是一个 app 项目的后台, 基本上就是一个论坛吧, 用户注册发帖什么的, 有 iOS/安卓 /微信客户端. 同事把原后台发来后, 看到是 java 的, 心头一震"又要搞这些啰嗦的玩意了", 但是拿到代码后,发现远比"啰嗦"更复杂.

原开发者把后台的 api 做成了 Spring cloud ribbon with eureka 的微服务架构, 用户认证 /帖子获取之类的接口用"微服务"来实现....

嗯, 这种方式很 JAVA, 很"企业级"

我也理解 ,当年有 Hibernate 或者 ORM 的时候, 有些人会说 "拼 SQL 才是最高效的,其他都是奇巧淫技". 用更高级的方法来替代原有的旧架构, 是发展的需要, 不要螳臂档车.

但是, 一个 app 的后台接口, 有必要用 ribbon/eureka 这类的"微服务"来实现吗? 没有太复杂的业务逻辑, 基本上都是对数据库的 CRUD, 难道不是这个项目的"发起人"又是某个 "企业级架构师" 主导的项目吧?


企业级 /架构师 /微服务 /J2EE....

这些玩意现在真是看一次, 吐一次
8994 次点击
所在节点    程序员
76 条回复
skyworker
2020-06-28 14:13:48 +08:00
@NoString 只是一个小 APP, 能发帖, 类似百度贴吧 app 那样, 比贴吧还要简答. 朋友的项目, 让我帮忙维护的.

是的, 目前用的就是 Laravel, 基本上能做到"快乐开发", 把精力放在 "如何解决问题"上
jimrok
2020-06-28 14:48:13 +08:00
10 万规模以下，没有必要上这些东西，徒增复杂性。
daimubai
2020-06-28 14:50:01 +08:00
额，我学 SpringCloud 纯粹就是学个组件怎么用，然后写在简历上，上家公司 120 万的用户量也就是两台服务器做了集群，没有分布式也没有微服务，业务功能也有四十多个，我觉得微服务就是给千万级的用户量用的，如果有人在公司把一个管理系统拆分成几个服务部署，我会反思我为什么会和他成为同事……
kop1989
2020-06-28 15:07:37 +08:00
其实很多行业都有这个问题。

一旦行业领头企业开始偏向某个方向，就会有一堆“跟风者”。
跟风者不考虑合理性，只是因为行业领头人这么选了。
然后紧接着就是“行业头部”整个都偏向这个方向，因为你不偏向你就不是行业头部了，你就 out 了。

然后就是“行业头部”固步自封，认为方向和自己不一致的都是异教徒。
随着“跟风者”的体量越来越大，越来越多的人也就被逼着必须“跟风”。

直到行业领头企业转向，开启下一波循环。
mysunshinedreams
2020-06-28 15:39:41 +08:00
@dog82 出门买烟穿燕尾服，不应该是自己的架构能力，技术选型不到位的问题吗？
mysunshinedreams
2020-06-28 15:41:09 +08:00
LZ 的问题还是看实际业务场景，比如日活超 1000W 的论坛，使用 Spring Cloud 技术体系没什么问题吧，并且还会比这个要更复杂一些。
但是如果只是几千日活，Python+Flask 就能玩了。
所以不要脱离实际业务场景谈架构。
rykinia
2020-06-28 16:01:53 +08:00
@sampeng 有点前后矛盾，如果使得开发效率降低，那多半是拆分不合理，比如原来一条 sql 就能完成的，现在搞成了分布式事务，徒增复杂性；
如果合理，开发难度降低，使得开发人员可以任意替换，但这种情况下，开发效率显然会更高。
cuiweieee
2020-06-28 16:44:52 +08:00
脱离场景直接下结论都是扯王八犊子
miracleyao
2020-06-28 18:16:04 +08:00
我觉得现在有些“架构师”、“技术总监”被微服务荼毒了，动不动就要微服务，项目还没落地，业务也没经过市场验证，直接就上 Spring Cloud 那一套，动不动就要好几台服务器，老板问为什么要这么多，美其名“考虑到后面数据量上来”。
casillasyi
2020-06-28 20:01:18 +08:00
@Vegetable 只能说 Java 的群体很大，哪天 go，php，rust，Clojure 也有这么大的群体，你同样会说对应的人有普遍问题。
sun1993
2020-06-28 22:12:58 +08:00
@tctc4869 服务注册&发现、熔断&限流、分布式链路追踪等，是独立的技术，微服务是架构思想，之所以提到微服务就跟着这些概念，是因为这些技术可以更好的管理微服务架构系统，而 spring cloud 就全套提供了这些东西。
其实不用 spring cloud 也可以，我们公司的注册&发现系统是自研的，服务拆分用的 grpc，链路追踪系统用的 jaeger，熔断器用的 Resilience4j，微服务是架构思想，实现它的方式有很多种。
PDX
2020-06-28 23:13:23 +08:00
真的是分久必合 合久必分，微服务火了一段时间，现在又开始说增加运维负担又开始揉一起去了，你赶了个晚集
elintwenty
2020-06-29 11:42:47 +08:00
微服务是架构思想，和 Java 没什么关系，不依赖于具体语言的实现。能说出“微服务”很 Java 这种话，根本就不了解微服务。如果业务场景不需要做解耦和控制，就没有用微服务的必要。你可以说技术选型有问题，也可以说微服务太盛行导致大家都想攒攒经验，但这不是微服务和 Java 本身的问题
yiyi11
2020-06-29 15:07:55 +08:00
Java 就是这么厉害，有这么丰富的生态上限，其他语言有吗？别管我用不用得上，就问你有没有？
CantSee
2020-06-30 15:35:12 +08:00
只有最适合的架构,没有最好的架构,crud 项目强行上微服务只会让项目变得臃肿
tesguest123
2020-07-02 12:24:54 +08:00
不上微服务 ppt 咋写

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/685030

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX