首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  index90  ›  全部回复第 1 页 / 共 13 页
回复总数  249
1  2  3  4  5  6  7  8  9  10 ... 13  
1 小时 31 分钟前
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@ABenmao 你这个场景里的 code 实际上是 error detail,你的程序不会去断言这个 code 做出相应的动作,而是透传到前端。最后由人捕获去排查问题。这种 code 的设计目的和 http 状态码的目的是不同的。这种 code 一般头几位代表系统或服务编号,中间几位代表模块,最后几位可能代表代码行或者顺序码。
1 小时 47 分钟前
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@l00t 所谓的错误处理,也就是 error recover,你无非做两件事。
1. 这个是你能处理的错误,记录日志,继续你的逻辑。
2. 这个你不能处理的错误,要么透传,要么收敛。

只有第一种你是需要断言错误的,这种情况十分的少,单靠返回码就能处理的更少,那么额外增加返回码的价值就更少了。

第二种,是你做得最多的,透传就不用说了。收敛的话,以登录接口举例,你可能先查询用户信息,然后验证密码,然后查询权限,等等。你接收到下游返回的错误情况有可能是用户不存在 404,密码错误 406,无权限 403 等等。你会将这些错误收敛为一个 403,并在 msg 中说明是哪一步出错了。

需要自定义返回码,并大量使用的公司,个人觉得有以下可能:
1. 接口定义得“太大”,即参数特别多,例如把登录和退出都做在一个接口里。
2. 不能“有效”地处理错误,大部分人截获到错误后,并没有做 recover 的操作,也没有做收敛的操作,而是转换成另一个他所理解的错误,再返回。这种“扩散”错误的做法,会给系统带来更大的复杂度,降低开发者处理错误的意愿,但带来的收益却很低。
简单来说,就是你给系统增加了 90%的麻烦,去处理你 10%的情况。
6 小时 12 分钟前
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
每次有人在纠结返回码问题的时候,我就贴出这个链接,然而每次都没有人看。
https://cloud.google.com/apis/design/errors

Google APIs must use the canonical error codes defined by google.rpc.Code. Individual APIs should avoid defining additional error codes, since developers are very unlikely to write logic to handle a large number of error codes. For reference, handling an average of 3 error codes per API call would mean most application logic would just be for error handling, which would not be a good developer experience.

试想想,如果下游服务返回一个错误码给你,你有两个选择
1. 识别并处理这错误码:
if code == some_error_code {
// do something
}
2. 不处理透传返回码:
if code != 0 {
return code
}

第一种,如果你错误码很多,那你就要写大量的错误码处理逻辑(每个接口)
第二种,透传到上层,那上层遇到的错误码可能性就越多,越不想处理。那么错误码的意义在哪里?出错是,方便定位?那一个字符串类型的 error detail 是不是表达能力更强?
16 小时 6 分钟前
回复了 Felldeadbird 创建的主题 程序员 程序员还是少点自黑好
自黑是为了与众不同
赞同 #31,听到过有人说,“然后就说明明一个请求搞定的事情,偏偏要转发几次请求”,最后得出结论是微服务没用。
不熟悉业务,不从领域设计出发,就是为了微服务而微服务了。
能不能低调一点?
4 天前
回复了 upday7 创建的主题 Go Go 到底优势是在哪里?
@stevenbipt #63
1. 水平不足就不写并发代码了?水平不足就可以不解决性能了?不止一次见到有人以水平不足去怪一项技术垃圾了。
2. 即使 Java 的热部署也是有要求的,不是所有更新都能够热部署,以前巨石架构用热部署还情有可原。都 9102 年了,微服务都快淘汰了,还不知道蓝绿部署,滚动发布。go 编写服务,配合容器化+k8s 编排,发布是很轻松的事情。
4 天前
回复了 upday7 创建的主题 Go Go 到底优势是在哪里?
@upday7 举个例子,搜索。100 万条数据找 10 条匹配度最高的。
一台服务器+一个数据库,基本上瓶颈会出现在数据库,因为你要在 100 万条记录的数据库中寻找 10 条数据。

换个做法,一台服务器,100 个数据库,每个数据库存 1 万条数据,那么一次搜索查询,需要并发出 100 个数据库请求,那么这时候瓶颈就会出现在应用服务器的并发性能上了。

所以 go 要扩大收益,架构也要跟着改变。
4 天前
回复了 upday7 创建的主题 Go Go 到底优势是在哪里?
没有 generic
4 天前
回复了 KaynW 创建的主题 程序员 Mac or Surface,大家会选哪个?
@ryanjmliao 同事一台 SB,屏幕底部漏光严重,找售后,说是正常情况,不予保修或更换。整个人都 SB 了。
5 天前
回复了 alexliux 创建的主题 程序员 mbp13 和 xps13,如何选择?
@alexliux 补充一下,我的是 14 年托香港读书的朋友,以学生价买的,定制 16G 内存,以当时汇率,9K 多 RMB。
我第一台的 T400,是在香港电脑展买的,8K 多 RMB。
对比下来,MBP 算是性价比高了。

重度开发者,墙裂建议升级内存。
5 年前毕业没多久,mbp13 靠自己勉强能付得起,下一台肯定换 15,13 屏幕对于开发实在有点小了。
PS:新版 mbp 的新键盘故障率超高,身边所有新版 mbp 全部中招。
5 天前
回复了 alexliux 创建的主题 程序员 mbp13 和 xps13,如何选择?
@alexliux 就是 14 年中买的啊,到现在 5 年多了吧
5 天前
回复了 alexliux 创建的主题 程序员 mbp13 和 xps13,如何选择?
第一台 T400,用了 3 年,报废。
第二台 MBP13 2014mid,用到现在,感觉还能再战个两年(或者等苹果哪天把键盘换回来)。

一句话总结,真香。

下一台,MBP15 或者传说中的 16。
7 天前
回复了 lasuar 创建的主题 Go 如何非侵入式的停止一个 goroutine
goroutine 不是线程啊,而 go 又没有 vm 给你做协程的控制,协程就是有用户(开发者)自己用代码控制的啊。
7 天前
回复了 lasuar 创建的主题 Go 如何非侵入式的停止一个 goroutine
标准的方式用 ctx 控制超时啊
7 天前
回复了 askfilm 创建的主题 Go Golang 是 Google 的 ?个人观点
感觉最近社会风气怪怪的,动不动就要国产这个,自研那个,造个飞机都恨不得连个螺丝钉都是国产的。什么事情什么领域都要“赢晒”,难道就不能合作么?
go mod graph| grep github.com/gogf/gf
首个?
根据原有的 API,编写 Proto 文件
根据 Proto 文件生成 gRPC 和 Rest 框架,注意,Client 和 Server 的 interface 应该只有一套,这样逻辑代码可以不用修改,就能使用两个框架。
Micro 公司有个 go-micro 项目,可以参考一下。
27 天前
回复了 XiLemon 创建的主题 硬件 旧电子产品该如何处理
我也想问这个问题,手上有一台摔坏的 iPhone6,电池鼓包的 iPhone5s。想丢垃圾桶,但是又觉得这些电子产品直接混着厨余垃圾埋到堆填区,实在太不环保了。

如果能有正规的回收就好了,换多少钱都不重要,留在家里还占地方。
1  2  3  4  5  6  7  8  9  10 ... 13  
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4086 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 34ms · UTC 09:08 · PVG 17:08 · LAX 02:08 · JFK 05:08
♥ Do have faith in what you're doing.