本人前端，对接 Java ，实在忍不住要吐槽了

[zhoupeng199]

公司之前是用 python django 开发，目前新组建的 java 团队，一起开发一个后台管理系统，java 是 spring 那一套微服务，有以下感受不得不吐槽。

1. 后端把很多关联关系丢给前端处理，在 python 的后端开发下，明明一个关联查询就能搞定的事情，他们搞不了，导致前端得根据 id 调另一个接口拿数据，问他们能不能查询到，他们说：“我们这是微服务架构”。意思是前端能调就前端调，在业务不得已的情况下是不会写 rpc 接口的。这让我不得不怀疑是不是他们的微服务划分是否有问题，导致给前端加了不少工作量。

举个例子，界面上一个** [树形选择器] ** 里的数据，需要一个状态判断是否展示，但是这个状态在另一个微服务里。后端表示让我调两个接口，然后根据数据再过滤一下，可特么这是一个树形数据啊，不是说做不了，但这让数据库 sql 过滤不是更简单，据理力争之下后端才妥协。

1. 后端甚至一些业务逻辑都不写了，举个例子，一个审批流程，按业务流程来说，应该是轮到自己审批了才展示。目前是只要和自己关联统统展示，并且要前端来通过代码判断是否轮到了自己处理了，才展示对应表单，这合理？

所以以上问题到底是人的问题还是 java spring 微服务的问题。

[zlzdbf]

人

[Frank201888]

微服务和 spring 表示不背锅

[linauror]

从以上举例来看就是人的问题

[Simle100]

单纯的后台管理系统用微服务？

[daley]

搞管理后台还用微服务，可以好好摸一阵了

[bjzhush]

你居然分不清这是语言的问题还是人的问题，也难怪搞不过后端了
别说 Java 了，20 年前的 asp 都能按你的要求出接口
你说这是谁的问题呢？

[isno]

人的问题，微服务用错了。微服务不是把微单元暴露给前端。

微服务架构应该是：业务合理的拆分和解耦，并且细小单元在服务治理管理下，某个单元崩溃也不至于整体服务都不可用，而且在微服务的基础之上，后端还要增加一个层，尽可能完善业务的处理逻辑，整合微单元的资源提供给调用方。

[XSDo]

后端微服务不 rpc ，用前端来走网络调用多一次接口？ 后端 rpc 可以走内网，前端调接口是走公网的啊 想想都知道那个调用更高效。

[final7genesis]

如果真有那么多分散的微服务，架构设计是不是要来一个网关层？

[renfei]

既不是 前端的问题，也不是后端的问题，更不是 java spring 技术的问题。

我们曾经有一段时间也这样推广过，理由如下：

1.后端的需求基本不会怎么变，也就是说数据库表不会改来改去
2.需求变更常常发生在用户侧，今天想看 A 明天想看 B
3.前端最贴近用户侧

结果就是

1.后端就是 CRUD ，跟数据库是的，傻不拉几的，成了数据查询器
2.前端忙死，大量招聘前端程序员
3.尝试推广 graphql

后端只要保证服务健壮不挂，其他都由前端去折腾这种合作模式。

但是吧，确实有些场景不方面，数据全吐给前端，有些数据会泄露，慢慢又改回来一部分，目前前后端算是平衡了吧。

[yor1g]

就是跟风 瞎几把拆服务 系统上线后就特么就那几十人在线用

[daye]

人的问题，结贴

[brader]

你慌什么，像你那个树形结构，要根据 ID 调别的接口的，如果要你循环调 N 次的话，你调呗，他服务支撑不住让他们头疼去

[huang40614676]

@renfei #10 经典场景，太典了

[ChefIsAwesome]

往好的方面想，后端觉得自己搞好了，高枕无忧，前端天天忙。裁员就裁后端。

[JKeita]

这明显是人的问题

[yoyolichen]

用了微服务却不会写 rpc 接口，他是来搞笑的么

[chenPiMeiHaoChi]

微服务不写 rpc 还微个锤子，建议直接 java -jar 。

[LLaMA2]

如果你 TS 写的比较溜，那就偷偷的给他写一层网关吧。预留一点自己的奇技淫巧，保证在你被优化后项目成功跑不起来。黑嘿嘿。。。

[potatowish]

@final7genesis 不是网关层，应该需要一个独立的聚合服务层