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

[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 作为基础架构，同时使用微服务框架来简化开发。最终，是否使用框架、使用哪种框架，取决于自身的架构需求和技术选型。关键是要明确：哪些能力应该由框架提供，哪些可以交给基础设施，从而找到最合适的微服务落地方式。

[FrankAdler]

@lekai63 这个怎么挖出来的

[lekai63]

@FrankAdler 直接给的网站啊

cursor.diretory

[yrzs]

首选 kratos ，从 v0.6 到 v2 用到现在, 设计优雅轻量，可扩展性非常强。社区还算活跃的