这是一个创建于 549 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司之前是用 python django 开发，目前新组建的 java 团队，一起开发一个后台管理系统，java 是 spring 那一套微服务，有以下感受不得不吐槽。
- 后端把很多关联关系丢给前端处理，在 python 的后端开发下，明明一个关联查询就能搞定的事情，他们搞不了，导致前端得根据 id 调另一个接口拿数据，问他们能不能查询到，他们说：“我们这是微服务架构”。意思是前端能调就前端调，在业务不得已的情况下是不会写 rpc 接口的。这让我不得不怀疑是不是他们的微服务划分是否有问题，导致给前端加了不少工作量。
举个例子，界面上一个** [树形选择器] ** 里的数据，需要一个状态判断是否展示，但是这个状态在另一个微服务里。后端表示让我调两个接口，然后根据数据再过滤一下，可特么这是一个树形数据啊，不是说做不了，但这让数据库 sql 过滤不是更简单，据理力争之下后端才妥协。
- 后端甚至一些业务逻辑都不写了，举个例子，一个审批流程，按业务流程来说，应该是轮到自己审批了才展示。目前是只要和自己关联统统展示，并且要前端来通过代码判断是否轮到了自己处理了，才展示对应表单，这合理？
所以以上问题到底是人的问题还是 java spring 微服务的问题。
第 1 条附言 · 2023-05-25 19:57:28 +08:00
感谢各位回复，看来还是我态度不够强硬，需要和后端 battle battle.
 |
1
zlzdbf 2023-05-25 16:22:07 +08:00
人
|
 |
2
Frank201888 2023-05-25 16:23:06 +08:00  2
微服务和 spring 表示不背锅
|
 |
3
linauror 2023-05-25 16:23:26 +08:00
从以上举例来看就是人的问题
|
 |
4
Simle100 2023-05-25 16:23:51 +08:00
单纯的后台管理系统用微服务？
|
 |
5
daley 2023-05-25 16:25:51 +08:00
搞管理后台还用微服务，可以好好摸一阵了
|
 |
6
bjzhush 2023-05-25 16:28:05 +08:00
你居然分不清这是语言的问题还是人的问题，也难怪搞不过后端了
别说 Java 了，20 年前的 asp 都能按你的要求出接口 你说这是谁的问题呢？ |
 |
7
isno 2023-05-25 16:28:19 +08:00 6
人的问题，微服务用错了。微服务不是把微单元暴露给前端。
微服务架构应该是：业务合理的拆分和解耦，并且细小单元在服务治理管理下，某个单元崩溃也不至于整体服务都不可用，而且在微服务的基础之上，后端还要增加一个层，尽可能完善业务的处理逻辑，整合微单元的资源提供给调用方。 |
 |
8
XSDo 2023-05-25 16:30:11 +08:00
后端微服务不 rpc ，用前端来走网络调用多一次接口？ 后端 rpc 可以走内网，前端调接口是走公网的啊 想想都知道那个调用更高效。
|
 |
9
final7genesis 2023-05-25 16:31:13 +08:00
如果真有那么多分散的微服务，架构设计是不是要来一个网关层？
|
 |
10
renfei 2023-05-25 16:31:45 +08:00 1
既不是 前端的问题，也不是后端的问题，更不是 java spring 技术的问题。
我们曾经有一段时间也这样推广过，理由如下： 1.后端的需求基本不会怎么变，也就是说数据库表不会改来改去 2.需求变更常常发生在用户侧，今天想看 A 明天想看 B 3.前端最贴近用户侧 结果就是 1.后端就是 CRUD ，跟数据库是的，傻不拉几的，成了数据查询器 2.前端忙死，大量招聘前端程序员 3.尝试推广 graphql 后端只要保证服务健壮不挂，其他都由前端去折腾这种合作模式。 但是吧，确实有些场景不方面，数据全吐给前端，有些数据会泄露，慢慢又改回来一部分，目前前后端算是平衡了吧。 |
 |
11
yor1g 2023-05-25 16:34:18 +08:00 1
就是跟风 瞎几把拆服务 系统上线后就特么就那几十人在线用
|
 |
12
daye 2023-05-25 16:36:45 +08:00
人的问题，结贴
|
 |
13
brader 2023-05-25 16:46:46 +08:00
你慌什么，像你那个树形结构，要根据 ID 调别的接口的，如果要你循环调 N 次的话，你调呗，他服务支撑不住让他们头疼去
|
 |
14
huang40614676 2023-05-25 16:48:55 +08:00
@renfei #10 经典场景，太典了
|
 |
15
ChefIsAwesome 2023-05-25 16:50:58 +08:00
往好的方面想，后端觉得自己搞好了，高枕无忧，前端天天忙。裁员就裁后端。
|
 |
16
JKeita 2023-05-25 17:00:26 +08:00
这明显是人的问题
|
 |
17
yoyolichen 2023-05-25 17:37:03 +08:00
用了微服务却不会写 rpc 接口，他是来搞笑的么
|
 |
18
chenPiMeiHaoChi 2023-05-25 18:07:55 +08:00
微服务不写 rpc 还微个锤子，建议直接 java -jar 。
|
 |
19
LLaMA2 2023-05-25 18:33:33 +08:00
如果你 TS 写的比较溜，那就偷偷的给他写一层网关吧。预留一点自己的奇技淫巧，保证在你被优化后项目成功跑不起来。黑嘿嘿。。。
|
 |
20
potatowish 2023-05-25 18:59:48 +08:00 via iPhone 1
@final7genesis 不是网关层，应该需要一个独立的聚合服务层
|
 |
21
Helsing 2023-05-25 19:01:13 +08:00 via iPhone
现在主流做法都是尽量数据云端化了，前端基本只负责展示
你们的后端开发很有问题 |
 |
22
ByZHkc3 2023-05-25 19:05:10 +08:00
后端懒，在我们这是会被骂死的
|
 |
23
superchijinpeng 2023-05-25 19:13:11 +08:00
人的问题
|
 |
24
miv 2023-05-25 19:23:47 +08:00 via Android
这就是后端懒，想把事情交给前端做。
做一个业务，它的逻辑不在前端就在后端。 要么你前端搞了后端舒服，要么后端搞了你前端舒服。 作为一个前端，那肯定是让后端出靠谱的才行。 最好一开始要把接口规划好，需要什么给后端说，不能让他直接给你接接口自己去处理，因为太坑太大了。 如果后端能处理，最好是后端。因为前前端有很多地方会用到后端，一个接口需要对应，很多种情况，最好是后端处理聚合起来。 这个就是后端的问题。 |
|
25
miv 2023-05-25 19:25:44 +08:00 via Android
我前后端都搞，所以比较能中立的看待你这个问题。
后端如果这些不帮你搞，有可能是后端懒。 另外一个原因就是后端的抽象能力不够。 他只站在自己的业务上想问题没往接口层上做一个抽象。 建议你不要自己搞，因为如果其他业务很复杂的话，前端是需要处理很多工作的，你这样搞的话到时候接口很多很乱的。 最好是后端商量一下，然后统一处理聚合。 这样虽然后端工作量多一点，但是可以大大提高软件的健壮性。 测出来的 bug 也会少。 |
 |
26
tingyunsay 2023-05-25 20:42:31 +08:00
我跟你反过来了，我们这逻辑全给后端了，前端只有纯展示
|
 |
27
Quarter 2023-05-25 20:59:58 +08:00 via Android
如果是这样的话我觉得可以直接上 saas 了，前端自己生成接口，后端不需要的就裁掉吧
|
 |
28
silentsky 2023-05-25 21:22:21 +08:00 via Android
如果需要适配多个端，那肯定是后端处理好比较好，不然多端做重复的工作。我写后端接口的原则一般尽量让前端傻瓜似的调用
|
 |
29
darkengine 2023-05-25 21:41:43 +08:00
把情况反馈给 leader ，如果 leader 觉得这是合理的，边做边准备简历吧。
|
 |
30
carytseng 2023-05-25 23:14:00 +08:00
六年经验感觉你司后端不行
|
 |
31
ql562482472 2023-05-25 23:20:34 +08:00 1
看上面都说后端的，其实前端做也没什么问题，还是看频繁变动的在前端还是后端。还有数据的性质，界面展示的状况等等。这种小问题其实谁做都可以 只要理由充分。
|
 |
32
zcf0508 2023-05-25 23:25:09 +08:00 via Android
你说的是我司吧哈哈哈哈
|
 |
34
huzhizhao 2023-05-26 00:09:15 +08:00 via iPhone
纯粹就是人的问题，技术不背锅
|
 |
35
chihiro2014 2023-05-26 01:27:31 +08:00
纯粹是后端人懒。。。
|
 |
36
auh 2023-05-26 03:44:43 +08:00
权力的问题。
|
 |
37
iseki 2023-05-26 03:48:59 +08:00 via Android
微服务拆的有问题，拆的太碎了，然后缺了个 BFF 聚合层，压力就全跑到前端去了
|
 |
38
louisxxx 2023-05-26 05:49:08 +08:00
和 java 有啥关系，这明明是人员技术水平差
|
 |
39
0xsui 2023-05-26 07:49:20 +08:00 via Android
咱就说，你司这种情况的后端，薪资是多少(ÒωÓױ)！
|
 |
40
yosoroAida 2023-05-26 08:02:58 +08:00
人的问题，用微服务居然不用 rpc （都 2023 年了，居然还说 rpc 接口迫不得已不写，盲猜没有实践经验）
|
 |
41
zfy941 2023-05-26 08:13:40 +08:00
这后端倒是真省事 就是把数据表读取给你呗 啥关系都让你自己来
|
 |
42
bhbhxy 2023-05-26 08:44:13 +08:00
前端在很多公司是没什么地位的，就我在的公司，一个年过五旬的领导还把前端称之为美工，认知还停留在 20 年前，有些后端更是这样，觉得前端没技术含量，把工作都推给前端，接口写好测都不测，等你反馈问题后看心情自己改还是让你改。
|
 |
43
lei2j 2023-05-26 09:08:46 +08:00 via Android
不是微服务的问题，是人的问题
|
 |
44
lingeo 2023-05-26 09:54:16 +08:00
下次直接把办公室当八角笼跟他 battle 就是，你不会还没跟后端吵过吧。我虽然是个后端开发，但是根据你的描述，我还是站你这边。先跟他线上沟通，不服就跟负责人反馈，负责人和稀泥就直接线下开骂。
|
 |
45
Erroad 2023-05-26 10:03:03 +08:00
你不用试图理解他的逻辑，站在你的角度很简单的，这种需求本来就应该一个接口，至于你后端为什么做不成一个接口，那不是我的问题。如果容易造成更多风险，就该上升到负责人去协调。
|
 |
46
passon 2023-05-26 10:05:57 +08:00
前端自己做个 bff 层，或者后端加个 bff 层
|
 |
47
nothingistrue 2023-05-26 10:28:36 +08:00
本帖前面的楼层，大多数都是美工在回复，没有做过全局的程序员，或者高级的 UI 开发。
先指出楼主，以及楼上广大美工一个非常明显的问题：不管是主动还是被动，当你的定位是一个纯前端的时候，那么不要插手后端工作量的评估——这是后端的内部工作，不要插手让前端做还是让后端做的决策——这是架构师或者开发主管的工作。如果你插手了，那只能得到一种结果：你行你上。 然后再来说下具体问题。很不幸的是，说不了，因为这问题分析只能是楼主团队的架构师 /开发主管来做。这里只能提供一些经验之谈。 经验一：接口是双方的，不是单方面的。放在楼主环境中，后端可以随意定义接口，但前端没说能用，接口开发任务就不算完成。但请注意，前端只能反馈不能用，不能反馈后端没做好。 经验二：微服务是全局的，前端也是微服务里面的一个环节，所以前端也要参与对数据分散问题的解决，该在 UI 层整合的数据，就得前端做。 经验三：单体应用拆分成微服务之后，前端也可以有自己专用的「前端的后端服务」，像楼主所举例的 「树形选择器」，如果是组织机构数这种全局通用的数据，那么可以交给「前端的后端服务」来集中做。 经验四：微服务拆分，或者说数据拆分，不是简单的把蛋糕切成几块的过程。拆分打散之后，是要再造出一些新的数据，来整合离散的数据的。经验三所说的「前端的后端服务」，就是一种多出来的服务 /数据。楼主的怀疑是对的，微服务拆分，确实有问题。 经验五：即使不是微服务，前后端拆分之后，前后端就不再是一个程序，而是有关联的两个程序，应当有各自独立的数据模型，不能再用一个。简单来说，前端 MVC 、MVVM 等框架中的 Model ，是前端自己的数据层，跟后端 Model 没关系，跟后端用得数据库更没关系。这时候，前端是万万不能说出「这让数据库 sql 过滤不是更简单」这种话的，他应当说的是「没过滤的数据用不了」 最后那个关于审批流程的问题，这个跟微服务、前后端都没关系，这特么就是个 BUG 。后端就没把接口做好，压根无需考虑是否合理，直接当成 BUG 提出去。 |
 |
48
TaoLoading 2023-05-26 10:37:46 +08:00
差不多的遭遇，之前项目的子模块，所有的查询后端就一个接口是让我自己拼 sql 传过去，让我前端拼 TM 的 sql 传过去？？！！！当时刚工作不久还不会跟后端刚，那段时间真痛苦啊
|
 |
49
noreplay 2023-05-26 10:48:22 +08:00 via Android
前端的前端，前端的后端，后端的前端，后端的后端。不知道啥样的公司，啥样的业务要搞这么复杂。感觉每一个公司都是人均阿里，都去搞一个中台，数据湖。说出去可牛逼了。
|
 |
50
J3W4 2023-05-26 11:04:55 +08:00
虽然但是,后端不就是应该处理数据的嘛,
说白了后端就是不想干 |
 |
51
adoal 2023-05-26 11:20:41 +08:00
是从一线互联网大肠毕业出来的不懂关系数据库不懂传统 CRUD 只会在没毕业的夹狗屎指定的萎服务业务框架里填空的后端吧
|
 |
53
justin2018 2023-05-26 13:30:01 +08:00
遇到过这样的情况
后端想省事儿 1. 用 express egg.js 包一层 2. 接口挨个插 反正服务挂了跟你没啥关系 3. 跟组长反馈这个问题 现在前端都是万金油了 特么啥都给前端干~~ |
 |
54
uyoungco 2023-05-26 17:07:06 +08:00
后端懒，有问题再返工就是
|
 |
55
wellerman 2023-05-26 17:37:06 +08:00
> "举个例子，界面上一个** [树形选择器] ** 里的数据，需要一个状态判断是否展示，但是这个状态在另一个微服务里。后端表示让我调两个接口，然后根据数据再过滤一下，可特么这是一个树形数据啊，不是说做不了，但这让数据库 sql 过滤不是更简单，据理力争之下后端才妥协。 "
树形数据的接口，是不是只有这一个界面调用？如果是，那按前端的显示状态返回就是合理。如果不是，那就会有多种状态的可能。下次有其它状态，就得重新出一个接口，这样接口就冗余了。当然也可以整合在在之前那个接口里，这样就耦合了。 spring boot 里 RPC 调用很简单，也就几句话。但并不会出现“这让数据库 sql 过滤不是更简单”。微服务下，这其中的工作量并不会因为转移到哪个端实现，工作量就会变少。 > "意思是前端能调就前端调，在业务不得已的情况下是不会写 rpc 接口的" 微服务不但要避免 RPC 调用，还要避免 join 。 正确的做法是，树形数据的接口不变，只负责完整数据输出。其它服务根据自身的需求出状态接口，如包含所有要显示的 id 数组。前端只是在遍历树形数据时，顺便判断一下 id 是否在显示状态接口的 id 数组中，这能有多大的工作量。这样出现其它不同的状态需求，只要换一个状态接口就可以了。目前，无非是后端妥协了，在后面用 RPC 调同样的接口，把数据处理好返回。下次呢？再妥协，一个接口里加一堆 RPC 调用。最后，这个接口的并发肯定上不去，变成系统的一个短板。 同时，有（输出）状态接口，必然有设置状态的接口，这个也和状态接口在同一个微服务里吧。既然和“树形数据”分开了，说明树形数据只是其它业务的子项，是一个公共服务。在公共服务里强行耦合其它业务，也非常不合理。 举个实际的例子，如地区数据服务，需要在很多业务里调用。有些要省市的，有些要到地区街道的，有的要在一个范围里的。如果在接口里做显示状态的判断，那么每次调用都得做一遍无意义的计算，还要传一坨数据。如果显示状态独立出来一个接口，用白名单或黑名单，在前端判断。地区数据只要获取一次，缓存好。这样不管是前端还是后端，性能会更好，还会节省服务器 CPU 和带宽资源。 > "后端甚至一些业务逻辑都不写了，举个例子，一个审批流程，按业务流程来说，应该是轮到自己审批了才展示。目前是只要和自己关联统统展示，并且要前端来通过代码判断是否轮到了自己处理了，才展示对应表单，这合理？" 都“按业务流程来说”了，就变成流转中的业务要不要展示？审批过后要不要展示？工作流不会一直向前流，还有回流，如驳回后要不要展示？驳回后，按业务流程来说，就是还没轮到自己审批，是不是不应该展示？什么叫合理？我早上上班，看一下最近和我有关的审批事项，提前熟悉一下相关事项，准备好相关资料。等到我审批时，就直接提交，这样做合不合理？比如，在电子税务局里，常会出现一些项目没到申报期，点进去也不能申报。但会提示，还有-xx 天，这样合不合理？ 最后，10 几年前，是没有前端这个职业，基本只有美工和程序员这两种。还有很多美工都是由程序员兼职的，比如 V2 就是那个时代的典型。当然了，现在后端兼职前端的也不少，像 V2 这样就不需要独立前端。前端的出现，就是因为可以把原本在服务端的计算放到客户端，节省资源提高可用性。做为一个合格的前端，应该是去压榨客户端资源，而不是服务端资源。不然前端就失去存在的意义。 |
Select Language