基于角色的框架,具有网络透明性,可在 Golang 中创建事件驱动架构。受 Erlang 启发。无依赖。
Goroutines and channels work great until your system grows. Then come the mutexes, the race conditions, the service discovery configs, the retry logic, the connection pool management. Ergo replaces all of that with one model: isolated processes that communicate through messages, supervised automatically, addressable across any cluster.
Inspired by Erlang/OTP. Zero external dependencies. Pure Go.
…No locks. No race conditions. Sequential message handling is the guarantee.
| Goroutines + channels | Ergo | |
|---|---|---|
| Shared state | You manage with mutexes | No shared state by design |
| Failure recovery | Manual | Supervision trees restart automatically |
| Cross-node messaging | Build it yourself | Same API, transparent |
| Service discovery | External tool needed | Built in |
| Race conditions | Possible | Impossible within a process |
Real-time backends. Each WebSocket connection becomes an addressable actor. Any node in your cluster can push to any specific client. No pub/sub intermediaries.
IoT platforms. One actor per device. Thousands of devices per node. Supervisors restart failed device actors automatically.
Multi-agent AI systems. Each agent is an isolated actor with a mailbox. Crash isolation, supervision, distributed addressability, and an MCP endpoint served by Observer that opens the running cluster to any AI assistant (Claude Code, Cursor, and other MCP-compatible clients). See AI Agents for patterns and diagnostics.
Financial and event-driven systems. Four priority queues per mailbox, guaranteed delivery, no dropped messages.
Distributed Pub/Sub across the cluster. Producer registers an event once; any process on any node subscribes. The framework delivers one network message per node, not per subscriber. 1M subscribers across 10 nodes cost 10 network messages, not 1M.
// Producer on any node
token, _ := producer.RegisterEvent("prices", gen.EventOptions{})
producer.SendEvent("prices", token, PriceUpdate{Asset: "BTC", Price: 95000})
// Subscriber on any other node, identical API
process.MonitorEvent(gen.Event{Name: "prices", Node: "producer@host"})
func (s *Sub) HandleEvent(event gen.MessageEvent) error {
fmt.Println(event.Message.(PriceUpdate))
return nil
}Lock-free queues. Processes sleep when idle. No CPU wasted.
The numbers come from make bench, which measures four scenarios: one process
sending to one process, and one pair per CPU, each on a single node and across a
connection between two nodes. msg/sec is the rate messages are carried end to
end - the send loops included, not the rate Send is called at.
On an AMD Ryzen Threadripper 3970X (32 cores, 64 threads):
…On an Apple M4 Max (14 cores: 10 performance, 4 efficiency):
$ make bench
go test -run XXX -bench . -benchmem -benchtime 5s ./testing/benchmarks/...
goos: darwin
goarch: arm64
pkg: ergo.services/ergo/testing/benchmarks/ping
cpu: Apple M4 Max
BenchmarkLocal11-14 31014296 191.4 ns/op 5224960 msg/sec 58 B/op 2 allocs/op
BenchmarkLocalNN-14 100000000 64.97 ns/op 15390843 msg/sec 72 B/op 2 allocs/op
BenchmarkNetwork11-14 13759047 431.2 ns/op 2319322 msg/sec 262 B/op 6 allocs/op
BenchmarkNetworkNN-14 27716260 193.6 ns/op 5166431 msg/sec 137 B/op 6 allocs/op
PASSThe two machines answer two different questions. A single pair costs 191ns per message on the M4 Max against 459ns on the Threadripper - that is per-core speed. Aggregate throughput goes the other way: 25.6M msg/sec against 15.4M, because there are 64 threads to fill instead of 14. What does not move is the allocation count: 2 allocations per local message and 6 per message that crosses the network, on both machines.
The cpu: line of the Linux run reports the hypervisor's string; the hardware
underneath is the Threadripper.
Full benchmarks: benchmarks repository.
Observer is a real-time web UI for monitoring and inspecting Ergo nodes. It provides live visibility into every layer of the system:
Add Observer to your node as an application:
import "ergo.services/application/observer"
options.Applications = []gen.ApplicationBehavior{
observer.CreateApp(observer.Options{}),
}To see it in action with a fully loaded cluster, see the observability example. For more information, visit the Observer documentation.
Actor Model: isolated processes communicate through message passing, handling messages sequentially with four priority queues. Supports asynchronous messaging and synchronous request-response, with per-process mailbox latency measurement (-tags=latency) for production diagnostics.
Network Transparency: actors interact the same way whether local or remote. Uses EDF (Ergo Data Format), a custom binary serialization with type caching, pointer support, and message versioning for seamless upgrades. Includes connection pooling, compression, message fragmentation, and application-level keepalive for silent failure detection.
Supervision Trees: hierarchical fault recovery where supervisors monitor child processes and apply configurable restart strategies. Supports One For One, All For One, Rest For One, and Simple One For One supervision types with Transient, Temporary, and Permanent restart policies.
Meta Processes: bridge blocking I/O with the actor model through dedicated meta processes handling TCP, UDP, Port, Web, WebSocket, and SSE protocols without affecting regular actor message processing.
Distributed Systems: service discovery via embedded or external registrars (etcd, Saturn), distributed publish/subscribe events with token-based authorization and buffering, remote process spawning with factory-based permissions, remote application orchestration across nodes, and Raft-style leader election - terms, votes and heartbeats, with no replicated log - without external dependencies for coordinating exclusive work across cluster replicas.
Observability: real-time cluster inspection via the Observer web UI, native distributed tracing that follows message chains across nodes with automatic propagation (exportable to OTLP backends like Grafana Tempo or Jaeger via Pulse), and production metrics via Radar with a ready-to-use Grafana dashboard covering process lifecycle, mailbox pressure, network traffic, and event fanout. The extensible Metrics actor adds custom Prometheus collectors alongside built-in node telemetry.
AI-Native: Observer serves an MCP endpoint beside its web UI, opening the full cluster to AI agents (Claude, Cursor, and any MCP-compatible client). Inspect processes, query events, capture goroutine dumps, stream logs, and run real-time samplers through natural language, turning any AI assistant into an interactive SRE for your Ergo cluster.
Cloud Native: built-in Kubernetes health probes (liveness, readiness, startup) via the Health actor, Prometheus metrics endpoint, and mTLS support for zero-trust deployments.
Ready-to-use Components: core framework includes Actor, Supervisor, Pool, Router, and WebWorker actors plus TCP, UDP, Port, and Web meta processes. Extra library provides Leader, Metrics, and Health actors, Observer, Radar, Pulse, and Grid applications, WebSocket and SSE meta processes, and Colored, Rotate, and Sentry loggers.
Erlang Interoperability: native support for the Erlang distribution protocol enables heterogeneous clusters where Ergo (Go) and Erlang/Elixir nodes participate as equal peers. Send messages, spawn processes, and set up links and monitors across language boundaries without any proxies or bridges.
Flexibility: customize network stack, certificate management (mTLS, NAT traversal), compression and message priorities, Cron-based scheduling, important delivery for guaranteed messaging, and logging. The [ergo](https:
暂无开放 Issues，或尚未同步最近议题。