这是一个创建于 136 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近接手了几个 java springboot 项目，看到代码一刻血往上涌血压有点快压不住了。各位大神帮分析下什么样的项目会这样做。 api 服务接收传参定义 json 串->转 map->拼接参数 bean->转 json 串-> feign 调用第二个服务->接收 json 串->转 map->拼接参数 bean-> feign 调用第三个服务->接收 json 串->转 map->拼接入库参数 ——>返回到第二个服务数据库->json 转 bean->入库并返参。
而且吧三个服务没有做链路追踪处理，并且 feign 调用不打印调用日志。出一个问题排查到泪奔。
 |
1
xuanbg 136 天前
我只能表示写这种代码的人非蠢即坏，🤷♂️
写代码简单直接一点不好吗，非得绕来绕去。 |
 |
2
powerman 136 天前
Spring Cloud Sleuth
|
 |
3
Kaiv2 136 天前
用下 http://skywalking.apache.org/ 排查问题非常方便
|
 |
5
392039757 136 天前
猜测是因为 feign 的 RequestBody 只能有一个，非得传多个的时候又得写一个对象，用 map 可以直接 get 出来
|
|
6
xuanbg 136 天前
@3kkkk 我司微服务根本不这么干啊，服务间调用不是没有，但全都是上层业务服务调用下层基础服务，而且调用链就只有 1 层。哪有 A 调用 B ，B 再调用 C ，然后依次返回数据这种事情。业务间通信也不是没有，但都是通过消息队列实现的，从来就不用 feign 。
|
 |
7
v2gf 136 天前
强行微服务的后果
|
 |
8
xlsepiphone 136 天前 via Android
单应用就没这些破事了
|
 |
9
shyangs 136 天前
濫用微服務.
調用一個服務，要經過 3~5 個微服務主機，然後使用者說服務怎麼這麼慢. 網路 IO(微服務)遠慢於記憶體(單體), 時間都消耗在序列化、反序列化、網路傳遞上面了. PG 怎麼優化都幹不過架構師的渣架構. |
 |
10
oneisall8955 136 天前
真·代码和你，一个能跑就行
|
 |
11
banmuyutian 136 天前  5
A 君用 json 传参，B 君用 Map 传参，C 君用 java bean 传参，他们和微服务一起构成这座屎山
|
 |
12
boris93 136 天前 via iPhone
谢谢，已经在替你想辞职之前怎么开喷了
|
 |
13
newxhk 136 天前 via iPhone
雖然不做後端，但看到已經想跑路了
|
 |
14
ZSeptember 136 天前 via iPhone
和 spring boot 无关，和程序员有关
|
 |
15
akin 136 天前
这样串联，直接上 kafka 吧
|
 |
16
byte10 136 天前
(⊙o⊙)… 以前也有接收过一个项目全是 map 参数的接口，我估计这样写是方便吧，不用 class 对象，直接当脚本语言开发，休休的快。😂
|
 |
17
cocang 136 天前
看文字已经头皮发麻了，我觉得这是技术能力或者逻辑能力不够的问题，这是纯坏吧
|
 |
18
ixx 136 天前
故事要从第一个 springboot demo 开始.....
|
 |
19
dengji85 136 天前
服务之间不依赖实体，调用不就是 json 吗，而且参数容易扩展，只是多级调用搞复杂了
|
 |
21
sumulige 135 天前
个人征信报文吧
|
 |
22
remember5 135 天前
@banmuyutian #11 赞同
|
 |
23
abcbuzhiming 135 天前
很简单，动态语言写多了的结果，不愿意使用强类型约束数据结构，所以就用 map ，灵活彻底，就是接收的人要骂娘
|
 |
24
KevinBlandy 135 天前
我也刚接手维护了一个 sb （ SpringBpoot ）开发的项目。一言难尽。
1 ，登录用 GET 请求 2 ，不用 spring-data-redis ，自己写代码读配置文件创建 JedisPool 3 ，上传文件等等跟数据库没关系的业务方法，都开启了事务 4 ，HTTP 调用，使用的是`java.net.URLConnection` 5 ，客户端提交的数据，没有任何校验 6 ，IO 操作各种不 close 资源 ... 领导说这系统不好用，也要新增一些功能。让我维护改改。。。 |
Select Language