All Projects → Azer0s → quacktors

Azer0s / quacktors

Licence: MIT license
The quacking awesome Go actor model framework!

Programming Languages

go
31211 projects - #10 most used programming language

Projects that are alternatives of or similar to quacktors

serverless-plugin-epsagon
Epsagon's plugin for Serverless Framework ⚡️
Stars: ✭ 53 (+278.57%)
Mutual labels:  tracing, distributed-tracing
reacted
Actor based reactive java framework for microservices in local and distributed environment
Stars: ✭ 17 (+21.43%)
Mutual labels:  actor-model, actor-framework
Go2sky
Distributed tracing and monitor SDK in Go for Apache SkyWalking APM
Stars: ✭ 234 (+1571.43%)
Mutual labels:  tracing, distributed-tracing
dropwizard-zipkin
Dropwizard Zipkin Bundle
Stars: ✭ 48 (+242.86%)
Mutual labels:  tracing, distributed-tracing
smallrye-opentracing
An MicroProfile-OpenTracing implementation
Stars: ✭ 17 (+21.43%)
Mutual labels:  tracing, distributed-tracing
Zipkin
Zipkin is a distributed tracing system
Stars: ✭ 14,969 (+106821.43%)
Mutual labels:  tracing, distributed-tracing
dogactor
Distributed Systems,Based on Actor Model
Stars: ✭ 70 (+400%)
Mutual labels:  actor-model, actor-framework
Apm Agent Rum Js
Elastic APM Real User Monitoring JavaScript agent
Stars: ✭ 166 (+1085.71%)
Mutual labels:  tracing, distributed-tracing
nodejs
Node.js in-process collectors for Instana
Stars: ✭ 66 (+371.43%)
Mutual labels:  tracing, distributed-tracing
lambda-python
SignalFx AWS Lambda Python Wrapper
Stars: ✭ 15 (+7.14%)
Mutual labels:  tracing, distributed-tracing
Csharp Netcore
OpenTracing instrumentation for .NET Core & .NET 5 apps
Stars: ✭ 225 (+1507.14%)
Mutual labels:  tracing, distributed-tracing
uptrace
Open source APM: OpenTelemetry traces, metrics, and logs
Stars: ✭ 1,187 (+8378.57%)
Mutual labels:  tracing, distributed-tracing
Brave
Java distributed tracing implementation compatible with Zipkin backend services.
Stars: ✭ 2,117 (+15021.43%)
Mutual labels:  tracing, distributed-tracing
Dd Trace Java
Datadog APM client for Java
Stars: ✭ 228 (+1528.57%)
Mutual labels:  tracing, distributed-tracing
Opencensus Web
A stats collection and distributed tracing framework
Stars: ✭ 168 (+1100%)
Mutual labels:  tracing, distributed-tracing
Opencensus Node
A stats collection and distributed tracing framework
Stars: ✭ 249 (+1678.57%)
Mutual labels:  tracing, distributed-tracing
Apm Agent Php
Elastic APM PHP Agent
Stars: ✭ 129 (+821.43%)
Mutual labels:  tracing, distributed-tracing
Pinpoint
APM, (Application Performance Management) tool for large-scale distributed systems.
Stars: ✭ 11,883 (+84778.57%)
Mutual labels:  tracing, distributed-tracing
Orleans.CosmosDB
Orleans providers for Azure Cosmos DB
Stars: ✭ 36 (+157.14%)
Mutual labels:  actor-model, actor-framework
thundra-agent-python
Thundra Lambda Python Agent
Stars: ✭ 36 (+157.14%)
Mutual labels:  tracing, distributed-tracing

logo

quacktors

Github Action Go Reference Go Report License: MIT

quacktors or "quick actors" is a Go framework that brings Erlang/Elixir style concurrency to Go! It allows for message passing, actor monitoring and can even deal with remote actors/systems. Furthermore, it comes with plenty of useful standard modules for building actor model systems (like Supervisors, Relays, etc.). Oh and btw: quacktors is super easy to use!

rootCtx := quacktors.RootContext()

pid := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
    fmt.Println("Hello, quacktors!")
})

rootCtx.Send(pid, quacktors.EmptyMessage{})

Getting started

To get started, you'll need an installation of qpmd (see: qpmd). The quacktor port mapper daemon is responsible for keeping track of all running systems and quacktor instances on your local machine and acts as a "DNS server" for remote machines that want to connect to a local system.

import "github.com/Azer0s/quacktors"

foo := quacktors.NewSystem("foo")

pid := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
    switch m := message.(type) {
    case quacktors.GenericMessage:
        fmt.Println(m.Value)
    }
})

foo.HandleRemote("printer", pid)

quacktors.Run()
rootCtx := quacktors.RootContext()

node := quacktors.Connect("foo@localhost")
printer, ok := node.Remote("printer")

rootCtx.Send(printer, quacktors.GenericMessage{Value: "Hello, world"})

Custom messages

To be able to send and receive messages from remote actors, you have to register your custom messages with quacktors. If you don't need to send a message to a remote machine, you also don't need to register it.

Note: the Type method is used to identify your message across machines (i.e. your message names have to match between machines). The recommended way of naming your types is to use a, sort of, package structure (e.g. "mypackage/MyMessage"). These can then be versioned by appending @{version} afterwards (e.g. "mypackage/MyMessage@v1 could reference the MyMessageV1 struct).

package mypackage

type MyMessage struct {
    Foo string
    Bar float32
}

func (m MyMessage) Type() string {
    return "mypackage/MyMessage"
}

Since GenServer handler names are resolved via Type, GenServers cut the package prefix and append the version if there is any. So "mypackage/MyMessage@v1" could be referenced in a cast handler with HandleMyMessageV1Cast (note: letters in the version name are automatically turned to upper case).

Monitoring actors

quacktors can monitor both local, as well as remote actors. As soon as the monitored actor goes down, a DownMessage is sent out to the monitoring actor.

pid := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
})

quacktors.SpawnWithInit(func(ctx *quacktors.Context) {
    ctx.Monitor(pid)
}, func(ctx *quacktors.Context, message quacktors.Message) {
    switch m := message.(type) {
        case quacktors.DownMessage:
            ctx.Logger.Info("received down message from other actor", 
                "pid", m.String())
            ctx.Quit()
    }
})

quacktors.Run()

Tracing

quacktors supports opentracing out of the box! It's as easy as setting the global tracer (and optionally providing a span to the root context).

cfg := jaegercfg.Configuration{
    ServiceName: "TestNewSystemWithHandler",
    Sampler: &jaegercfg.SamplerConfig{
        Type:  jaeger.SamplerTypeConst,
        Param: 1,
    },
    Reporter: &jaegercfg.ReporterConfig{
        LogSpans: true,
    },
}
tracer, closer, _ := cfg.NewTracer()
defer closer.Close()

opentracing.SetGlobalTracer(tracer)

span := opentracing.GlobalTracer().StartSpan("root")
defer span.Finish()
rootCtx := quacktors.RootContextWithSpan(span)

a1 := quacktors.SpawnWithInit(func(ctx *quacktors.Context) {
    ctx.Trace("a1")
}, func(ctx *quacktors.Context, message quacktors.Message) {
    ctx.Span().SetTag("message_type", message.Type())
    <-time.After(3 * time.Second)
})

rootCtx.Send(a1, quacktors.EmptyMessage{})

quacktors.Run()

Metrics

quacktors has a metric system in place (not the 📏 kind, the 📊 one) and offers many useful components to collect and metrics (like the TimedRecorder and the accompanying TimedRecorderHook to make collecting metrics in a specified interval super easy).

Supervision

quacktors comes with some cool standard components, one of which is the supervisor. The supervisor (as the name implies) supervises one or many named actors and reacts to failures according to a set strategy.

quacktors.SpawnStateful(component.Supervisor(component.ALL_FOR_ONE_STRATEGY, map[string]Actor{
    "1": &superImportantActor{id: 1},
    "2": &superImportantActor{id: 2},
    "3": &superImportantActor{id: 3},
    "4": &superImportantActor{id: 4},
}))

Location transparency

Sending messages in quacktors is completely location transparent, meaning no more worrying about connections, marshalling, unmarshalling, error handling and all that other boring stuff. Just send what you want to whoever you want to send it to. It's that easy.

Floating PIDs

PIDs in quacktors are floating, meaning you can send a PID to a remote machine as a message and use that same PID there as you would use any other PID.

foo := quacktors.NewSystem("foo")

ping := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
    switch m := message.(type) {
    case quacktors.Pid:
        ctx.Logger.Info("ping")
        <- time.After(1 * time.Second)
        ctx.Send(&m, *ctx.Self())
    }
})

foo.HandleRemote("ping", ping)

quacktors.Run()
rootCtx := quacktors.RootContext()

bar := quacktors.NewSystem("bar")

pong := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
    switch m := message.(type) {
    case quacktors.Pid:
        ctx.Logger.Info("pong")
        <- time.After(1 * time.Second)
        ctx.Send(&m, *ctx.Self())
    }
})

bar.HandleRemote("pong", pong)

foo := quacktors.Connect("foo@localhost")
ping := foo.Remote("ping")

rootCtx.Send(ping, *pong)

quacktors.Run()

GenServers

As part of the default component set, quacktors supports Elixir style GenServers. The handlers for these are configured via the method names via reflection. So a GenServer with a Call handler for a PrintRequest would look like so:

type PrintRequest struct {
    //our printing request message
}

func (p PrintRequest) Type() string {
    return "PrintRequest"
}

type Printer struct { 
    //printing magic
}

func (p Printer) InitGenServer(ctx *quacktors.Context) {
	ctx.Trace("printer")
}

func (p Printer) HandlePrintRequestCall(ctx *quacktors.Context, message PrintRequest) Message {
    //print stuff
	
    return quacktors.EmptyMessage{}
}


pid := quacktors.SpawnStateful(genserver.New(Printer{}))
res, err := genserver.Call(pid, PrintRequest{})

So you don't even have to write your own actors if you don't want to. Cool, isn't it?

Quacktor streams

quacktors supports stream processing out of the box. Currently, there is only a connector for Apache Kafka but many more will come in the future.

context := quacktors.RootContext()

consumer, _ := quacktorstreams.NewConsumer(consumerImpl)
producer := quacktorstreams.NewProducer(producerImpl, "test")

pid := quacktors.Spawn(func(ctx *quacktors.Context, message quacktors.Message) {
    fmt.Println(message)
})

_ = consumer.Subscribe("test", pid, func(bytes []byte) (quacktors.Message, error) {
    val := quacktors.GenericMessage{}
    err := json.Unmarshal(bytes, &val)
    return val, err
})

context.Send(producer, quacktors.GenericMessage{Value: 1})
context.Send(producer, quacktors.GenericMessage{Value: 2})

quacktors.Run()

On message order and reception

In quacktors, message order is guaranteed from one actor to another. Meaning that if you send messages from A to B, they will arrive in order. The same is true for remote actors.

For multiple actors (A, B & C send messages to D), we can't make that guarantee because we don't know when each actor will execute.

As with basically all other actor systems, there is no guarantee (or even acknowledgement) that a message has been received. Send is a non-blocking call and doesn't return anything (even if the sending procedure failed).

On PID logging

When starting quacktors for the first time, you might notice that sometimes quacktors logs with a global PID (i.e. PID + machine ID) and sometimes just a local PID is logged. This is because sometimes there is ambiguity as to where (on which machine) a PID lives (e.g. when telling a PID to quit) and other times it's clear that the PID is on the local system (e.g. when starting an actor). Global actor PIDs are named gpid when logging. When we know that a PID lives on a remote machine, we don't only log the gpid but also the machineId.

Configuring quacktors

quacktors has some configuration options which can be set by using the config package during init.

func init() {
    config.SetLogger(&MyCustomLogger{})
    config.SetQpmdPort(7777)
}
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].