Thinking about using Go as a composite service.

<p>I have a composite service aggregating data from other microservices, I was wondering how go would handle thousands of aggregations.</p> <hr/>**评论：**<br/><br/>xy8_t_rel_: <pre><p>define composite service.</p></pre>lolomfgkthxbai: <pre><p>Is that the buzzword of the year? Composite services that aggregate all the microservices everyone built last year...</p></pre>heyPerseus: <pre><p>Yes and yes</p></pre>Redundancy_: <pre><p>Is this an api gateway service perhaps?</p></pre>heyPerseus: <pre><p>It is.</p></pre>heyPerseus: <pre><p>a service that is calling multiple api&#39;s, joining the data and returning it.</p></pre>mishudark: <pre><p>Probably you need to manage a queue, could be implemented inside your Go program or with any solution like Nats.io</p></pre>caseynashvegas: <pre><p>It&#39;s sort of a vague question, but I believe this is a good use case for Go and it might help to read this blog post about concurrency patterns in go: <a href="https://blog.golang.org/pipelines" rel="nofollow">https://blog.golang.org/pipelines</a> I think you are specifically going to look at the fan-in / fan-out patterns.</p></pre>heyPerseus: <pre><p>You&#39;re right it&#39;s pretty vague. I&#39;m planning on writing a go version of a Java app that is in use(I didn&#39;t write it so I&#39;m not sure what&#39;s totally involved. I wrote a service that feeds into it). I want to see what the performance difference would be. I&#39;ll read that article, thanks!</p></pre>hobbified: <pre><p>Probably pretty well. The code might get a bit verbose, especially for failure propagation, but goroutines are a pretty good model for this sort of thing. Sending off some requests and then doing stuff when the responses come in doesn&#39;t require major contortions code-wise, and the performance should be good. Thousands of concurrent reqs isn&#39;t anything to worry about.</p> <p>Use <a href="https://golang.org/pkg/context/" rel="nofollow">Contexts</a> to manage cancellation of outstanding requests on failure, timeouts (overall and for various phases), and holding values that are needed several levels apart in the call stack.</p></pre>unimpaired: <pre><p>Definitely! Apps like this are where Go really shines.</p></pre>Redundancy_: <pre><p>I do something similar at a small scale using objects that manage requests and caching to each service to ensure that they&#39;re updated on schedule, based on events etc. You have to think it through to watch out for sending on closed channels and avoiding deadlocking the messaging of a service based on waiting for another, but it works well.</p> <p>In general, doing thousands of aggregations probably means you benefit from a bit of intelligence avoiding redundant queries that you have to wait for, high levels of concurrency and careful management of connection pools.</p> <p>However, if you have to do that much, it may be that there&#39;s a mismatch between the microservice APIs and the way that you want to actually use them, which would be worth trying to fix to reduce this issue.</p></pre>