go-zero
Orchestrationgo-zero is a Go-based framework for building web services and RPC microservices, positioned squarely in the "batteries included" camp.
What it is
go-zero is a Go-based framework for building web services and RPC microservices, positioned squarely in the "batteries included" camp. Its core pitch is resilience under load: built-in circuit breaking, rate limiting, adaptive load shedding, and timeout control are baked into the request path rather than bolted on. The other half of the pitch is goctl, a code generation CLI that scaffolds API services, RPC services, and their boilerplate (handlers, logic, config, Dockerfiles) from a .api or protobuf definition file. Despite the "Orchestration & Management" categorization, it's not a Kubernetes-native control-plane tool — it's an application framework that happens to produce services you'd deploy on K8s.
Who builds it and why
go-zero originated from a team at Shanghai-based tech company (commonly cited as a project spun out of a fintech/short-video-adjacent engineering org) dealing with high-QPS production incidents, and was open-sourced to share the resilience patterns they built to survive them. It's maintained by a core group with 332 contributors on GitHub — a healthy number for a framework project, indicating real external adoption beyond the original authors, not just a single-company internal tool thrown over the wall. It's popular primarily in the Chinese Go community, with documentation and community discussion historically skewed toward Chinese-language resources, though English docs have improved.
Production readiness signal
33,144 GitHub stars and a recent commit (as of the data given, actively maintained) suggest this is not an abandoned side project. 332 contributors is a strong signal of community engagement for a framework (not just a library). MIT license removes legal friction. Latest release v1.10.2 suggests a mature, iterating codebase rather than a 0.x experiment. CNCF maturity: not publicly available — go-zero is not a CNCF project, so don't expect CNCF-style governance, security audits, or a foundation backing it. Founding date: not publicly available, so exact track record length is unclear, but release numbering and star count imply multiple years of active development.
Who should use this
- Go teams building microservice architectures who want opinionated scaffolding instead of assembling their own stack from gRPC + Gin + Hystrix-equivalents + config libraries.
- Teams that have been burned by cascading failures and want circuit breaking, load shedding, and rate limiting as defaults rather than something they configure themselves after an incident.
- Teams comfortable with code-generation workflows (
goctl) as part of their dev loop. - Organizations already operating in the Chinese tech ecosystem, where go-zero has significant production usage and community support (Bilibili, Youzan, others reportedly use it).
Who should NOT use this
- Teams not using Go — this is a Go-only framework, full stop.
- Shops already standardized on a different Go stack (e.g., raw gRPC + Kratos, or Go kit) — rewriting working services to adopt go-zero's opinions isn't worth the churn.
- Teams wanting a thin, unopinionated HTTP layer — go-zero is opinionated about project structure, config format, and codegen; if you want minimal abstraction (e.g., just
net/http+ chi), this will feel heavy. - Anyone expecting Kubernetes-native orchestration features (operators, custom controllers, scheduling) — despite being filed under "Orchestration & Management," go-zero doesn't orchestrate anything; it's an app framework.
- Teams needing first-class English documentation and Western community support as a hard requirement — it exists, but it's thinner than the Chinese-language ecosystem.
Alternatives
- Kratos — Bilibili's Go microservice framework, similar goals (resilience, codegen), also strong in the Chinese Go ecosystem.
- Go kit — older, more modular/unopinionated toolkit for building Go microservices; more assembly required, less magic.
- gRPC-Gateway + plain gRPC — for teams who want to hand-roll their resilience and tooling stack instead of adopting a framework's opinions.
Pricing
Fully open source, MIT licensed. No paid tier, no commercial entity behind it selling support contracts (not publicly available otherwise). Cost is entirely your engineering time to adopt and operate it.