这是一个创建于 583 天前的主题，其中的信息可能已经有所发展或是发生改变。
今年又有一个客户的老项目维护, java 项目, 还是 spring cloud 微服务.
系统业务并不复杂, 还是被原来的开发人员精心强制分拆了 8-9 个微服务, 蛋痛.
更扯淡的是, 目前系统的数据量才不到 10 万, 但是主业务管理的查询, 已经超过了 6 秒...
java 工程师, 是不是主要把心思都花费在如何用最新的技术架构/如何拆分微服务, 但是连基本的数据库索引优化都不屑吗?
6 条回复
 | 1 a5X77vajGRyLA2aF 2024-05-16 09:42:52 +08:00 人的问题。 没人管，原开发人员用来练习简历技术栈。 请求超过 6s 都没人反馈，说明在这个公司或工作氛围中也不是问题 |
 | 2 chuck1in 2024-05-16 10:30:50 +08:00 确实是人的问题，并不是 java 的问题。 Java 一样能做现代单体应用。。。比如 t/1039258 这个技术栈。 当然，做 java 的人有很多特别喜欢搞这种微服务，规模越大越大，引用的中间件越多越好。 |
| 3 chuck1in 2024-05-16 10:33:06 +08:00 比如这套技术栈你要在主 java 的公司推广可能就很难，因为很多人都不会去用里面的一些东西，一定要用 mysql redis mybatis 微服务 zk/nacos rocktmq springcloud 那一套才舒服。。。。。。  |
 | 4 skyworker OP 20 年前, javaer 感觉"企业级"应用太重, 太繁琐, 要"J2EE without EJB", 敏捷开发, TDD 各种方法论满天飞. 开始还好, 都是小而美的框架, webwork, spring, hibernate 之类. 后来, 直到现在的各种"微服务", 又恢复到了原来臃肿, 令人恶心的体系. 当年的屠龙少年, 终究是又变成了恶龙. |
| 5 a5X77vajGRyLA2aF 2024-05-16 18:17:15 +08:00 @skyworker 时代在进步，各种业务场景的解决方案一直在摸索。 spring 是小，但使用起来不“美”，所以才有后来的 springboot hibernate 和小应该不沾边，使用起来也不“美”。 微服务不会让系统变臃肿，乱用微服务、乱划分才是系统变臃肿的原因。 |
Select Language