这是一个创建于 32 天前的主题，其中的信息可能已经有所发展或是发生改变。
主要考虑一下几点:
1.希望是成体系的工程结构(结构层次分明，有一定的规范)
2.有成熟的脚手架，省去开发通用功能模块的时间(如权限、日志、字典等)
3.社区是否还在活跃，避免跑路了没人维护的尴尬
4.目前意向 go-kratos 、go-zero ，整体看来 go-kratos 比较轻量，扩展性和层次设计清晰，go-zero 封装了很多，但是感觉整体设计不如 go-kratos ，不是那么优雅，但 kratos 现在貌似不怎么更新了...
有没有懂这两个框架的或者有其他框架解决方案推荐的 xd 科普科普，tx :)
#Gin#Iris#Echo#Beego#Fiber#GoKit#GoZero#GoMicro#Kratos#Dubbo-Go
 |
1
povsister 32 天前  1
如果你是 go 高手，并且后期致力于 go 应用生态+灵活对接其他系统，选 kratos
如果你是只求糊出来业务逻辑，多的不想管，选 zero kratos 不维护是不太可能的，但 kratos 可能不太积极维护（指实现 roadmap |
 |
2
tangqiu0205 32 天前 1
3 年 kratos 开发经验，半年 go-zero 经验，现在每天心里默默吐槽 go-zero ，还是 kratos 好用。
|
 |
3
lekai63 31 天前 via iPhone
参考 cursor 提示词，可以用 servemux
You are an expert AI programming assistant specializing in building APIs with Go, using the standard library's net/http package and the new ServeMux introduced in Go 1.22. Always use the latest stable version of Go (1.22 or newer) and be familiar with RESTful API design principles, best practices, and Go idioms. - Follow the user's requirements carefully & to the letter. - First think step-by-step - describe your plan for the API structure, endpoints, and data flow in pseudocode, written out in great detail. - Confirm the plan, then write code! - Write correct, up-to-date, bug-free, fully functional, secure, and efficient Go code for APIs. - Use the standard library's net/http package for API development: - Utilize the new ServeMux introduced in Go 1.22 for routing - Implement proper handling of different HTTP methods (GET, POST, PUT, DELETE, etc.) - Use method handlers with appropriate signatures (e.g., func(w http.ResponseWriter, r *http.Request)) - Leverage new features like wildcard matching and regex support in routes - Implement proper error handling, including custom error types when beneficial. - Use appropriate status codes and format JSON responses correctly. - Implement input validation for API endpoints. - Utilize Go's built-in concurrency features when beneficial for API performance. - Follow RESTful API design principles and best practices. - Include necessary imports, package declarations, and any required setup code. - Implement proper logging using the standard library's log package or a simple custom logger. - Consider implementing middleware for cross-cutting concerns (e.g., logging, authentication). - Implement rate limiting and authentication/authorization when appropriate, using standard library features or simple custom implementations. - Leave NO todos, placeholders, or missing pieces in the API implementation. - Be concise in explanations, but provide brief comments for complex logic or Go-specific idioms. - If unsure about a best practice or implementation detail, say so instead of guessing. - Offer suggestions for testing the API endpoints using Go's testing package. Always prioritize security, scalability, and maintainability in your API designs and implementations. Leverage the power and simplicity of Go's standard library to create efficient and idiomatic APIs. |
 |
4
to2false 31 天前
优选 kratos
|
 |
5
viking602 31 天前
kratos 吧 不维护应该不会 上一个 release 不是还在 12 月 其实也还好
|
 |
6
dp 31 天前
kratos 挺好用 除了文档不咋地、示例太老
 |
 |
7
crackidz 31 天前
kratos 也没什么功能好加了吧
|
 |
8
ericguo 31 天前
gin 不好用吗？难道不是市场占比第一的框架吗？ kratos 第一次听到，非 Go 程序员。
|
 |
9
kkhaike 31 天前 5
实际上 golang 用框架还不如用各种开源项目的组合
1. 依赖注入: go.uber.org/fx 用好这个，手搓框架轻而易举 2. 路由表: /gorilla/mux + urfave/negroni 3. grpc 相关: grpc-ecosystem/go-grpc-middleware + grpc-ecosystem/grpc-gateway + bufbuild/buf 4. 遥测: go.opentelemetry.io/otel 5. 数据库看你风格选: gorm or (sqlc + dbmate) or didi/gendry 然后写代码中缺什么自己补点什么，基于 fx 你很快就能攒一个自己的框架 |
 |
10
jigujigushanshan 31 天前
@ericguo 说的是微服务框架，gin 算是个简单的 http 框架，在 kratos 的对应应该是他的 blademaster 那一部分
|
 |
11
log4j 31 天前
kratos+1
|
 |
12
wetalk 31 天前 1
OP 想要的所有，Spring 都可以满足，虽然 Java 啰嗦，但是你都用 Go 了，还用什么框架啊
|
 |
13
blackmatch 31 天前
gRPC: https://grpc.io/
|
 |
14
lasuar 31 天前
已经进化到不用框架了，自己搭建架构就好了。无非是网关/rpc/代码生成/服务发现
|
 |
15
voya 31 天前
不建议用 go-zero ，特别是在团队中，zero 太不灵活性，go 本身比较简单，不要被框架搞得太束手束脚。选 go-zero 除非能极大缩减开发成本，项目规模也不大
|
 |
16
jimmzhou 31 天前
只用过 go-zero 想请教下 , kratos 比 go-zero 好在哪里
|
 |
17
ninjashixuan 31 天前
不嫌自写服务注册与发现、限流熔断麻烦，选个趁手的 web 框架+ grpc 自己封装吧。go-zreo 太繁杂了小团队开发效率不高。
|
 |
18
gvison 31 天前 1
@ninjashixuan 我就是使用 gin+grpc 实现的 sponge 微服务框架，其核心理念是通过解析 SQL 、Protobuf 、JSON 文件逆向生成模块化代码，这些代码可灵活组合成多种类型的完整后端服务，接近以"低代码"方式进行开发微服务，只需专注写业务逻辑实现代码，同时内置了 AI 助手，也支持自定义模板，灵活扩展，使得开发微服务变得极其简单。
注：sponge 的目录层次和 kratos 目录层次类似。 https://github.com/go-dev-frame/sponge |
 |
20
Huelse 31 天前
goframe 也可以参考下，好像是站内的人发过的
|
 |
22
qloog 31 天前
kratos ，不错，设计理念开放，扩展性强，部分设计和 go-micro 类似
但是我用： https://github.com/go-eagle/eagle 和 kratos , go-micro 也有类似之处 |
 |
23
me1onsoda 31 天前
为什么 go 还要搞这些乱七八糟的东西，随便一个框架，丢到 k8s 跑不就得了，天然的微服务
|
 |
24
Meld 31 天前
kratos 不需要频繁更新啊，一个轻量级的框架频繁更新的目的是啥？
|
 |
25
lesismal 31 天前
大搞微服务框架的基本都是脚手架堆屎山。如果非要用微服务框架、让我打分，哪家封装的少简单易用哪家分数高，go-zero 这种大量搞营销、而不是真正提高代码质量的还是算了，随便扫下目录，比如：
core/codec 里放了 aes dh gzip hmac rsa ，加密、压缩、哈希算法放一块叫 codec ，你要是用这些组合起来实现个自己的编解码叫 codec 包也行，关键都是这些加密压缩哈希本身的简单封装、彼此之间也没什么关联，真的佩服 core/syncx 里把一堆标准库的强行再封装一些，比如 atomic cond_t ，标准库很多地方已经比较简洁了，一大堆这种强行二次封装，真美什么必要，我怀疑好未来是按代码行数评定绩效的吧，这么喜欢把简洁的 golang 搞成屎吗？ 几年前大量的营销行为，净吸收小白 star 了，真是仗着国家人口红利造就高 star 的巨大屎山，非常讨厌这些搞营销的污染 golang 环境，之前没骂过，今天蚌埠住了 kratos 我没看，也没看到他们团队有 go-zero 那种大量营销行为，不做评价 很多团队，根本不需要复杂的微服务框架，你门做这种复杂框架选型的时候，然后又要去学习这些复杂的垃圾框架的基础知识的时候，别人功能都写好了上线了而且更加轻便、更加高性能、更加易扩展 go 的基础框架，web 框架一大把 gin echo chi fiber 之类的，rpc 你要喜欢就 grpc ，要是想更好体验就用我的 arpc 这种，log 框架也是很多随便选个 star 多的都足够好用，其他的什么服务注册发现都 etcd 自己需要就提供了稍微按照自己喜好封装下都可以，业务量没那么大服务没规模都不需要注册发现这些，甚至 web 服务里做好限流熔断之类的 limiter 连 rpc 都不需要 每次看见咨询微服务框架的尤其是推荐垃圾框架的，哎！ 愁！ |
 |
26
gl3081 31 天前
|
 |
27
fffq 31 天前
go-micro
|
 |
28
guochenglong 31 天前
kratos
|
 |
31
layxy 31 天前
kratos+1 ，框架结构很清晰
|
 |
33
lveye 31 天前
go-kit （ https://github.com/go-kit/kit ），轻量好用，扩展性强
|
 |
34
maocat 31 天前 via Android
要不是 go-micro 作死，哪会有这么多杂七杂八的框架
|
 |
35
BeautifulSoap 31 天前 via Android
如果已经写过业务的话不是一般都慢慢会有自己的那套框架了吗
我是基于 Gin 配合 Dig 做 DI ，根据多年项目自己慢慢积累了一套框架，从各层的注入到日志等，实际都不太复杂，主要还是看你是不是真的熟悉业务指导要哪些功能 |
 |
37
timethinker 31 天前
微服务不等于微服务框架。微服务只是一种架构风格，一种设计原则，或者一种部署策略，这两个东西虽然处在不同的层级，但是二者是正交的。为了实现微服务架构，不一定要使用微服务框架，但框架能让微服务更易落地。反过来说，使用了这些微服务框架开发的应用，也不一定能够实现微服务架构。
如果了解 service mesh 并使用容器，可以在不引入任何框架的情况下就能实现微服务这种设计理念。或者换句话说，开发者可以在不使用任何“微服务框架”的情况下，就能获得“微服务”的那些好处。毕竟微服务从一开始倡导的就是足够小、足够自治、灵活选择，支持跨语言、跨平台。 像 kratos 或者 java 中 spring cloud 这种“云原生”微服务框架可以在没有容器环境的情况下，也就是没有 sidecar 代理支持的情况下，直接把微服务需要的那些组件编译/打包进应用程序，在应用层内置微服务那些组件的功能。 因此，部分企业会直接使用 service mesh 作为基础架构，同时使用微服务框架来简化开发。最终，是否使用框架、使用哪种框架，取决于自身的架构需求和技术选型。关键是要明确：哪些能力应该由框架提供，哪些可以交给基础设施，从而找到最合适的微服务落地方式。 |
 |
38
FrankAdler 30 天前 via Android
@lekai63 这个怎么挖出来的
|
|
39
lekai63 30 天前 via iPhone
|
 |
40
yrzs 30 天前
首选 kratos ，从 v0.6 到 v2 用到现在, 设计优雅轻量，可扩展性非常强。社区还算活跃的
|
 |
41
sciel 28 天前 via iPhone
goframe 的微服务不错哦简单方便
|
 |
42
b906604588 27 天前 3
我是包子，算是 Kraots 的主要负责人之一，我来回答下关于 Kratos 的问题。
1 、Kratos 现在功能很稳定了，没有什么要迭代的东西了，微服务就这么点东西，而且 Kratos 本身的设计就很轻量，用户不需要框架本身做修改，就能扩展很多能力了。 2 、Kratos 会持续维护的，Kratos 现在属于社区，不属于某个公司，我本身也不是 B 站员工。 3 、文档太老的确是这样的，实在没时间弄，社区同学可以贡献下，hhh 。 4 、我们很久没有主动推广了，但是社群还是一直在维护的，日常问题答疑也很积极。 5 、Kratos 最近会开一个新项目，可以关注下。 |
|
43
b906604588 27 天前
针对 3 ，补充下：主要下班之后就懒得动了，bugfix 和特性还是会积极看的。如果你 MR 有的长时间没有看，主要原因是改动代码太大了，实在看不下去了。
|
|
44
b906604588 27 天前
@flyqie connect-go 的定位对应 gRPC ，和微服务框架还是有一定区别的
|
 |
45
flyqie 26 天前 via Android
|
 |
46
veightz 22 天前 via iPhone
我在用字节的 cloudwego…… 因为有中文群可以尬问🥹
|
 |
47
brightguo 16 天前
前阿 b 员工，推荐用 kratos ，简单易用拓展性强，很多设计非常优雅。
现公司用的 gin ，缺很多东西，很多要自己造轮子，很多轮子我会参考 kratos 设计。 |
Select Language