V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wunonglin  ›  全部回复第 47 页 / 共 162 页
回复总数  3237
1 ... 43  44  45  46  47  48  49  50  51  52 ... 162  
2022-01-17 14:16:32 +08:00
回复了 windfarer 创建的主题 推广 Go 微服务框架 Kratos 线上直播年会,等你来围观!
太棒了。我就是跟着你们源码学的微服务
2022-01-17 14:14:26 +08:00
回复了 fengchen0vr 创建的主题 问与答 阿里云盘大于一百兆下载要装客户端了,这私有没有扫盘
@mxT52CRuqR6o5 #44 存二进制文件自己做非对称加密就行了
2022-01-17 11:37:14 +08:00
回复了 justNoBody 创建的主题 微信 2022 年了,微信能更好的实现云备份了么?
@justNoBody #2 电脑微信有备份功能,同一个局域网就行了
2022-01-17 11:31:41 +08:00
回复了 justNoBody 创建的主题 微信 2022 年了,微信能更好的实现云备份了么?
。。。那么重要的东西不另外存着?微信不是说要推出云存储聊天记录的功能了么,等等呗。

每日一句:微信垃圾
2022-01-17 11:27:06 +08:00
回复了 gongquanlin 创建的主题 macOS 请问为啥 mbp2021 插着电源,就不会休眠呀?
盒盖即休眠。插电状态下开盖的话是不会休眠的。
2022-01-16 20:24:51 +08:00
回复了 fengchen0vr 创建的主题 问与答 阿里云盘大于一百兆下载要装客户端了,这私有没有扫盘
???改什么吃屎,不是一直在吃?

再说,不会有人以为不会走百度的老路吧?不会把不会吧?想什么呢。真要没限制的去用 oss
2022-01-16 17:34:45 +08:00
回复了 smartwusir007 创建的主题 问与答 前端组件大家是怎么做的
1 、组件不符合需求就自己写一个。组件库只能覆盖 70%的场景,选一个自定义程度高度组件库就行,element 和 ant 耦合度很高,建议要用这种库的话就优化需求以符合组件库即可。
2 、好好学。
2022-01-15 23:00:23 +08:00
回复了 zorn 创建的主题 Node.js 基于 Express 和 TypeScript 写了一个快速开发的 API Server
这不就是 nest 么。。。
2022-01-15 22:06:54 +08:00
回复了 shinsekai 创建的主题 Apple Apple pay 银联卡码合一难产了?
谁的码合一了?
2022-01-15 22:03:42 +08:00
回复了 JL1990 创建的主题 问与答 golang 中 json 如何解析不同的结构体
@JL1990 #7 那为什么不把字段都做在一个 struct ,然后再判断那些有值不就行了么?

https://s2.loli.net/2022/01/15/4f1JIzoFEKeDp8g.png
2022-01-15 20:38:13 +08:00
回复了 zbzzh 创建的主题 宽带症候群 steam 官网部分地区疑似被墙
@ZztGqk #11 不在工信部备案的网站“按理”都不能打开,这不是我决定的[doge]。所以被墙了毫不稀奇。还有博主说想反抗😄,建议先开个群大家都加进去反抗。反正到时候谁先进去我就不知道了
2022-01-15 20:24:45 +08:00
回复了 JL1990 创建的主题 问与答 golang 中 json 如何解析不同的结构体
分别解析 V1 、V2 不行?你写的这个 parse 和直接调用 unmarshal 有啥区别
2022-01-15 15:30:19 +08:00
回复了 DinnyXu 创建的主题 MacBook Pro 大家使用 M1 感受如何?
太快了。不习惯
2022-01-15 15:25:15 +08:00
回复了 zbzzh 创建的主题 宽带症候群 steam 官网部分地区疑似被墙
很稀奇么?
2022-01-14 18:38:59 +08:00
回复了 firhome 创建的主题 程序员 请教后端同学这种写接口的方式对不对?
@hhjswf 这看你业务来着。我自己预想的是订单这个整体是一个服务
2022-01-14 17:51:49 +08:00
回复了 firhome 创建的主题 程序员 请教后端同学这种写接口的方式对不对?
@linglin0924 #89

我认为是因为 lz 习惯了 bookinfo 一股脑带出来可以直接渲染,页面不用太多异步逻辑,加上以前单服务的时候是可以 join 起来也方便,所以直接返回也没什么问题。这是 ok 的,因为那时候大家都这么做的。

但是到现在新微服务架构后,两个服务分开了,分别提供了 curd ,就没必要再加一个聚合的 bookinfo 接口,因为确实没必要。

这个构架不用考虑握手太多的问题。人少对系统没压力,人多接口分细了反而能降低系统负载,前端也可以用中间件做 ttl 缓存。问题很好解决,或者说压根不是问题。

时代变了呀~
2022-01-14 16:54:40 +08:00
回复了 firhome 创建的主题 程序员 请教后端同学这种写接口的方式对不对?
@wupher 他这个已经是微服务架构了。不同业务直接不要直接操作,更何况在不在同一个库都不一定
2022-01-14 12:53:44 +08:00
回复了 firhome 创建的主题 程序员 请教后端同学这种写接口的方式对不对?
@wunonglin #41

网站人流量多的可以在前端用用中间件做 ttl 缓存,网站人流量少的你也不用考虑多次请求带来的负载。

每个模块都有 curd 了,那就没必要再给你搞一个聚合接口,你说可不可以,当然可以,只是没必要而已。
2022-01-14 12:50:18 +08:00
回复了 firhome 创建的主题 程序员 请教后端同学这种写接口的方式对不对?
两者都合理,具体还是看业务场景。

但第二种明显更好,毕竟你是获取 bookinfo ,其他东西没必要带给你,你再根据 bookinfo 里面的外键 id 去其他对应的接口查询即可。

这样的话再根据各个客户端的需求,去做就好了。比如页面需要一次性显示,app 不需要,那这样接口拆分的就很合理

再者就是可以“渐进式显示”,打开 bookinfo 页面,先显示 bookinfo ,然后再去请求 order ,这样用户就能先看到页面,不至于要等全部数据出来才显示。

比较复杂的例子:一个 bookinfo 里面,可能有 tags 、orders 、images 、comments ,如果全部给你,数据多的话体验会很差。那我可以先显示 bookinfo ,然后再根据用户点击的 tab ,再去加载对应的数据(懒加载)那体验会好很多,这样系统负载也会小很多,毕竟可能有的用户只是想某几个模块而已
人家把你当傻子,结果你真以为是概率问题?就算这问题过了,还会有下一个破下线的,认真你就输了
1 ... 43  44  45  46  47  48  49  50  51  52 ... 162  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2251 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 15:55 · PVG 23:55 · LAX 07:55 · JFK 10:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.