再聊一个 Java 相关的话题

[skyworker]

今年又有一个客户的老项目维护, java 项目, 还是 spring cloud 微服务.

系统业务并不复杂, 还是被原来的开发人员精心强制分拆了 8-9 个微服务, 蛋痛.

更扯淡的是, 目前系统的数据量才不到 10 万, 但是主业务管理的查询, 已经超过了 6 秒...

java 工程师, 是不是主要把心思都花费在如何用最新的技术架构/如何拆分微服务, 但是连基本的数据库索引优化都不屑吗?

[yusheng88]

人的问题。

没人管，原开发人员用来练习简历技术栈。

请求超过 6s 都没人反馈，说明在这个公司或工作氛围中也不是问题

[chuck1in]

确实是人的问题，并不是 java 的问题。
Java 一样能做现代单体应用。。。比如 https://www.v2ex.com/t/1039258 这个技术栈。

当然，做 java 的人有很多特别喜欢搞这种微服务，规模越大越大，引用的中间件越多越好。

[chuck1in]

比如这套技术栈你要在主 java 的公司推广可能就很难，因为很多人都不会去用里面的一些东西，一定要用 mysql redis mybatis 微服务 zk/nacos rocktmq springcloud 那一套才舒服。。。。。。


[skyworker]

20 年前, javaer 感觉"企业级"应用太重, 太繁琐, 要"J2EE without EJB", 敏捷开发, TDD 各种方法论满天飞.

开始还好, 都是小而美的框架, webwork, spring, hibernate 之类.

后来, 直到现在的各种"微服务", 又恢复到了原来臃肿, 令人恶心的体系.

当年的屠龙少年, 终究是又变成了恶龙.

[yusheng88]

@skyworker
时代在进步，各种业务场景的解决方案一直在摸索。

spring 是小，但使用起来不“美”，所以才有后来的 springboot
hibernate 和小应该不沾边，使用起来也不“美”。

微服务不会让系统变臃肿，乱用微服务、乱划分才是系统变臃肿的原因。

[chuck1in]

@skyworker 现在的 spring boot 个人觉得其实也不大，spring boot 应该说生态现在发展的真的很完善。

只是用 spring cloud 走微服务那一套的话，这套框架看起来特别臃肿。实际上现在的现代微服务跟 spring cloud 也没什么关系了，都是在容器那一层做掉了。服务之间的调用有一些轻量级的库可以依赖来用。