golang 微服务框架选择困惑

[h1apaazz]

主要考虑一下几点:
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

[povsister]

如果你是 go 高手，并且后期致力于 go 应用生态+灵活对接其他系统，选 kratos
如果你是只求糊出来业务逻辑，多的不想管，选 zero

kratos 不维护是不太可能的，但 kratos 可能不太积极维护（指实现 roadmap

[tangqiu0205]

3 年 kratos 开发经验，半年 go-zero 经验，现在每天心里默默吐槽 go-zero ，还是 kratos 好用。

[lekai63]

参考 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.

[to2false]

优选 kratos

[viking602]

kratos 吧 不维护应该不会 上一个 release 不是还在 12 月 其实也还好

[dp]

kratos 挺好用 除了文档不咋地、示例太老

[crackidz]

kratos 也没什么功能好加了吧

[ericguo]

gin 不好用吗？难道不是市场占比第一的框架吗？ kratos 第一次听到，非 Go 程序员。

[kkhaike]

实际上 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 你很快就能攒一个自己的框架

[jigujigushanshan]

@ericguo 说的是微服务框架，gin 算是个简单的 http 框架，在 kratos 的对应应该是他的 blademaster 那一部分

[log4j]

kratos+1

[wetalk]

OP 想要的所有，Spring 都可以满足，虽然 Java 啰嗦，但是你都用 Go 了，还用什么框架啊

[blackmatch]

gRPC: https://grpc.io/

[lasuar]

已经进化到不用框架了，自己搭建架构就好了。无非是网关/rpc/代码生成/服务发现

[voya]

不建议用 go-zero ，特别是在团队中，zero 太不灵活性，go 本身比较简单，不要被框架搞得太束手束脚。选 go-zero 除非能极大缩减开发成本，项目规模也不大

[jimmzhou]

只用过 go-zero 想请教下 , kratos 比 go-zero 好在哪里

[ninjashixuan]

不嫌自写服务注册与发现、限流熔断麻烦，选个趁手的 web 框架+ grpc 自己封装吧。go-zreo 太繁杂了小团队开发效率不高。

[gvison]

@ninjashixuan 我就是使用 gin+grpc 实现的 sponge 微服务框架，其核心理念是通过解析 SQL 、Protobuf 、JSON 文件逆向生成模块化代码，这些代码可灵活组合成多种类型的完整后端服务，接近以"低代码"方式进行开发微服务，只需专注写业务逻辑实现代码，同时内置了 AI 助手，也支持自定义模板，灵活扩展，使得开发微服务变得极其简单。
注：sponge 的目录层次和 kratos 目录层次类似。
https://github.com/go-dev-frame/sponge

[cyan]

@ericguo gin 主要是 web ，功能太少了

[Huelse]

goframe 也可以参考下，好像是站内的人发过的

[wysnxzm]

@povsister #1 你怎么头顶尖尖的

[qloog]

kratos ，不错，设计理念开放，扩展性强，部分设计和 go-micro 类似
但是我用： https://github.com/go-eagle/eagle 和 kratos , go-micro 也有类似之处

[me1onsoda]

为什么 go 还要搞这些乱七八糟的东西，随便一个框架，丢到 k8s 跑不就得了，天然的微服务

[Meld]

kratos 不需要频繁更新啊，一个轻量级的框架频繁更新的目的是啥？

[lesismal]

大搞微服务框架的基本都是脚手架堆屎山。如果非要用微服务框架、让我打分，哪家封装的少简单易用哪家分数高，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 都不需要

每次看见咨询微服务框架的尤其是推荐垃圾框架的，哎！
愁！

[gl3081]

@kkhaike 你说的不就是我的开源项目吗？
* https://github.com/GStones/moke-kit
* https://github.com/moke-game/platform

[fffq]

go-micro

[guochenglong]

kratos

[kkhaike]

@gl3081 已 star... 实际 fx 非常强大... 但感觉推的人很少...

[gl3081]

@kkhaike fx 对新人有一定的门槛，不像其他框架，上手就可以直接堆业务。

[layxy]

kratos+1 ，框架结构很清晰

[flyqie]

@lesismal #25

好奇对 connect-go 这种的评价。

感觉这个基础框架拿来写业务还是不错的。

[lveye]

go-kit （ https://github.com/go-kit/kit ），轻量好用，扩展性强

[maocat]

要不是 go-micro 作死，哪会有这么多杂七杂八的框架

[BeautifulSoap]

如果已经写过业务的话不是一般都慢慢会有自己的那套框架了吗
我是基于 Gin 配合 Dig 做 DI ，根据多年项目自己慢慢积累了一套框架，从各层的注入到日志等，实际都不太复杂，主要还是看你是不是真的熟悉业务指导要哪些功能

[lesismal]

@flyqie #32 没了解过 connect-go 。

[timethinker]

微服务不等于微服务框架。微服务只是一种架构风格，一种设计原则，或者一种部署策略，这两个东西虽然处在不同的层级，但是二者是正交的。为了实现微服务架构，不一定要使用微服务框架，但框架能让微服务更易落地。反过来说，使用了这些微服务框架开发的应用，也不一定能够实现微服务架构。

如果了解 service mesh 并使用容器，可以在不引入任何框架的情况下就能实现微服务这种设计理念。或者换句话说，开发者可以在不使用任何“微服务框架”的情况下，就能获得“微服务”的那些好处。毕竟微服务从一开始倡导的就是足够小、足够自治、灵活选择，支持跨语言、跨平台。

像 kratos 或者 java 中 spring cloud 这种“云原生”微服务框架可以在没有容器环境的情况下，也就是没有 sidecar 代理支持的情况下，直接把微服务需要的那些组件编译/打包进应用程序，在应用层内置微服务那些组件的功能。

因此，部分企业会直接使用 service mesh 作为基础架构，同时使用微服务框架来简化开发。最终，是否使用框架、使用哪种框架，取决于自身的架构需求和技术选型。关键是要明确：哪些能力应该由框架提供，哪些可以交给基础设施，从而找到最合适的微服务落地方式。