<p>I have this project idea of implementing a multiple agents systems that consist of 2 main components: </p>
<ul>
<li>triggers: they emit events, e.g: timer that fires every 5h, http webhook that receives requests...</li>
<li>workers: they react to events: e.g: a scraper, an email notifier, a db handler...</li>
</ul>
<p>think of something close to ifttt.com, multiple combinations of workers/triggers are also possible, this diagram can help visualize a use case (<a href="http://imgur.com/a/w8qEA" rel="nofollow">http://imgur.com/a/w8qEA</a>) </p>
<p>I'm not sure how i should desing this project in Go in order to take advantage of its concurrency features, I tried to follow javascript like approach using event listeners but didn't feel right to me.</p>
<p>I was wondering if there's any known design pattern that can help me solve this problem using channels and goroutines?</p>
<hr/>**评论：**<br/><br/>muesli: <pre><p>This sounds a lot like Beehive, which I've worked on in the last couple years: <a href="https://github.com/muesli/beehive" rel="nofollow">https://github.com/muesli/beehive</a></p>
<p>It intentionally doesn't do concurrent execution currently, but you could easily adapt it. Feel free to contribute, too!</p></pre>zianwar: <pre><p>This is great! will definitely check it out</p></pre>etherealflaim: <pre><p>The simplest model is probably to have triggers (that might implement some kind of interface so that the framework can monitor them and report general status information in a GUI or status page) that have a Subscribe-style API. You don't want to use channels in exported APIs, but your trigger framework could provide some helpers for notifying a set of subscribers concurrently.</p>
<p>By way of illustration, you could have a trigger package that you use to register triggers for monitoring:</p>
<pre><code>package trigger
type TriggerStats struct {
CurrentSubscribers int
SuccessfulNotifications int
// ...
}
type Trigger interface {
Name() string
Stats() TriggerStats
}
func Register(t Trigger) {}
</code></pre>
<p>An event package for whatever common format you want your events to take:</p>
<pre><code>package event
type Event struct {
// ...
}
</code></pre>
<p>A subscriber package to implement helpers for dispatching notifications</p>
<p>Packages for your triggers:</p>
<pre><code>package webook
type Trigger struct {
Path string
}
type Subscriber interface {
RequestReceived(Event)
}
func (t *Trigger) Subscribe() { /* ... */ }
func (t *Trigger) ServeHTTP(w http.ResponseWriter, r *http.Request) {
// ... compute ev *Event
for _, sub := range t.subscribers {
subscriber.Dispatch(ctx, func(ctx context.Context) {
sub.RequestReceived(ctx, ev)
})
}
}
</code></pre>
<p>etc.</p>
<p>Internally, the Dispatch helper would spawn a new goroutine, correctly using <a href="https://golang.org/pkg/context/#WithTimeout" rel="nofollow">context.WithTimeout</a> and friends to make sure that the recipient doesn't take too long.</p>
<p>The channels might come into play in the worker packages; depending on the incoming volume and workload, you could either just do your work in the goroutine the trigger starts for you, or you could have a work queue implemented as a buffered channel with a configurable number of workers pulling jobs off of it.</p></pre>
