go-zero 、kratos 、micro?
希望能有使用过比较深的人来综合比较下。
go-zero 、kratos 、micro?
希望能有使用过比较深的人来综合比较下。
|
waisingAug 6, 2021
1
kratos 还有字节的 kitex 可以看下....我们用的原生 grpc
|
|
777777Aug 6, 2021
2
蹲,目前在用 go-zero
|
|
yuyoungAug 6, 2021
3
Micro 就不要了,资料少,Kratos 很不错
|
|
ahmcsxccAug 6, 2021
4
go-zero 、kratos 里选一个吧
|
|
NaVientAug 6, 2021
5
kratos 设计理念不错
|
|
6
说实话,这些都不需要,grpc + k8s 就可以了
|
|
webmasterisadogAug 6, 2021
8
@Hanggi 有没有轻量级的微服务架构?适合做写简单的开发和实验用于论文写作。
|
|
damngoodAug 6, 2021
9
grpc + 前置网关
|
|
labulaka521Aug 6, 2021
10
grpc+1 写个代码生成就可以了
|
|
PureWhiteWuAug 6, 2021
11
Kitex
|
|
mritdAug 6, 2021
12
kratos 、go micro 、go kit 吧
go zero 真的慎用... 看着都不错 用起来全是坑 |
|
masterclockAug 6, 2021
13
dapr
|
|
herozzmAug 6, 2021
14
golang 不需要什么微服务框架吧 直接开撸挺香啊
|
|
sb137885Aug 6, 2021
16
k8s 梭哈,再不行 istio,然后 dapr,还有 layotto,哈哈
|
|
17
@seyoatda #15 譬如你想同时暴露 grpc 接口和 http json 接口,那么你必须写 api 层,API 层是自己定义的一个 DSL,还要手撸一遍 rpc 层的结构体,然后手动 "copy" 过去;最难受的是 go zero 的序列化框架是自己写的,就比如序列化常用的 json 、form tag 啥的很多属性都是不支持的;然后你不清楚的情况下还可能会有迷之行为,而且最近开了两个 issue 来看,基本上你的 issue 项目管理者只要认为解决了就直接关了,不会有任何确认的,多了不说了,我也是帮别人弄东西的时候发现他们用了这个框架,我帮忙调试都快哭了。
|
|
yinheliAug 6, 2021
18
自研了,gRPC + gRPC-gateway,开源在 github
主要是让之前的项目,RESTful API 能比较平滑的过渡过来 |
|
bugyangAug 6, 2021
19
正在学习 go-zero
|
|
20
大而全的微服务框架不适合中小团队直接拿来用,而大团队自家定制、不太需要用别人的
单就 RPC: https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/ 帖子中的性能数据可能不准确,最好自己跑那个代码实测下,易用性和各方面优劣可用自行对比 |
|
21
|
|
zibberAug 6, 2021
22
用过 rpcx 和 go-micro 现在项目用的 go micro
|
|
buddyyAug 6, 2021
23
我感觉在使用 k8s 情况下,这些微服务框架是不需要的。
虽然不直接使用,但是有些设计理念是可以借鉴使用的,在适合自己场景下进行改造乃上上策。 |
|
caoyoumingAug 6, 2021
24
自己撸,用 gin 做路由不香么
|
|
wizzerAug 6, 2021
25
自己造轮子?
|
|
26
公司全部换成 go-zero 了
|
|
stirlingxAug 6, 2021
27
最好原生 grpc
|
|
rita413413Aug 6, 2021
28
@stirlingx 原生 grpc 服务发现,均衡负载,都要自己写,那不是很麻烦?感觉 go-zero 还可以吧。开一个接口时,先用 api 上,如果不够用,在将此接口改为微服务。
|
|
windfarerAug 6, 2021
29
又来大乱斗了,欢迎来看看我们的 go-kratos
|
|
LonensoAug 6, 2021
30
用过 rpcx 和 grpc
|
|
GoLandAug 7, 2021
31
字节 KiteX 的泛化调用很好用
|
|
dayeye2006199Aug 7, 2021
32
为啥需要框架? grpc + k8s 就可以起飞了。需要 tracing 熔断 metrics 这类就上个 istio 或者 linkerd 。业务和运维的代码高度解耦化,写起来很清楚的。
|
|
dcoderAug 7, 2021
33
kratos... 这框架名字太中二了 LOL
https://github.com/go-kratos/kratos/blob/main/README_zh.md |
|
kevinwanAug 7, 2021
34
@mritd 很多个月没来 V2EX 了,用户发给我,我来回答一下哈
api 是个聚合层,rpc 是基础服务层,你说的 copy 过去,可能是希望 api/rpc 共用一套定义?我比较倾向于单一职责,所以就出现了你说的『 copy 』 json, form tag 不支持是指啥意思? go-zero 支持 path, form, header, json tags 能否列一下哪个 issue 直接关的?我们都会回复的 BTW:别人弄的,你调试哪个框架不哭?:) |
|
ldmid666Aug 7, 2021
35
之前也是选择了很久,用 go-zero 有一段时间了,也提了几个 issue
感觉这个使用起来方便,但是自由度不够了。缓存设计那里有 bug,自带的 logx 库不好用,日志不太好用。 当然按照框架架构写代码还是挺舒服的。不够,我也想去尝试一下新的框架了 |
|
statumerAug 7, 2021
36
go-zero ? go-zero 背后的公司不是好未来么。。观望一下吧
|
|
johnsonaAug 7, 2021 via iPhone
37
说 kratos 的是不是因为有开源项目 手动 doge
|
|
HarveyZhAug 7, 2021
38
正在用 kratos,觉得还不错
|
|
DesdemorAug 17, 2021
41
现在用 rpcx
|
|
xmszAug 23, 2021
42
国内微服务框架
阿里 dubbo-go 头条 kitex 腾讯 tars-go b 站 kratos 我们最后选择了 kratos,原因 - dubbo-go 感觉被名字局限了,毕竟是 go 版的 dubbo,而不是 go 版的 spring 。当然 dubbo-go 也是朝着更多功能扩展,但感觉还是怪怪的,期待再独立一个项目出来。但是毕竟阿里还是 Java 为主,Java 生态无敌 - 腾讯,每次都让人有种格格不入的感觉,但是确实这里做的最『未来』的,整体性很强。还有一个原因虽然和 tars 没关系,但是微信开发团队真的非常糟糕给腾讯名号蒙羞 - 头条,没什么感觉也没什么推广 - b 站,有概念感、业务实践、也喜欢毛剑老师。唯一缺点就是 git 社区客服戾气太重,有点玩不起的感觉,不知道是不是 b 站人员,可能是最近生活不顺利啥的。 然后为什么要框架,其实如果你只是写『脚本』那完全不需要 但是如果你需要架构层面,那肯定需要这类框架,rpc 框架现在基本都是往 go 框架发展 为什么选国内框架 - 中文太重要了 |
|
wfhtqpAug 27, 2021
43
小项目用不到,大项目直接 k8s+istio
|
|
kongkongyztDec 26, 2021
44
@xmsz 腾讯内部目前在用 trpc, 存量的 tars 项目都在往 trpc 转. 虽然 trpc 还没开源, 但是使用体验很不错, 非常轻量, 可插拔, 兼容各种内部的 rpc 协议(如 tars), http 协议等等, 设计的理念也很先进. 感觉开源出来的话会是一个非常优质的选择
|
|
chiuanNov 8, 2022
45
@kongkongyzt 使用简单吗……
|
|
solitude2Dec 26, 2022
46
@kongkongyzt 设计的理念也很先进,这句可否展开说说?我感觉高性能这块实在看不起依据,易用倒是确实符合实际
|
|
solitude2Dec 26, 2022
47
腾讯的 trpc-go ,真的 nice
|