Generally speaking, each private key should be unique, and private keys should not travel.
If you have several "applications" that expect HTTPS connections (on port 443, SSL/TLS handshake...) and that run on the same machine, then the application are not, actually, doing the SSL. The SSL is handled by the Web server frontend (say, an Apache or IIS): that frontend does the SSL, then (only then) receives the HTTP request, learns the target path, and thus knows to which application the request shall be dispatched. In that kind of setup, the private key and the certificate are not owned by the applications, but by the frontend. In that model, you would give one private key and certificate per machine.
The paragraph above assumes that your "micro services" really are all registered on a common HTTP+SSL engine, as is expected if they all use the default HTTPS port (443) and the same IP address. You could do otherwise, e.g. run the different services on distinct ports (the connection URL will then have to include the port name), or even on distinct IP addresses (if each machine owns several IP addresses). In that case, each micro service may run its own HTTP+SSL engine, and thus have its own certificate and private key.
There are two main reasons why you would want to make several private keys and certificates:
You want to give certificates to systems that are not equivalent to each other in terms of security, e.g. they belong to distinct customers who do not fully trust (or even know) each other. The idea is that knowing a private key used by a server allows (conceptually) impersonating that server. Similarly, having distinct certificates allows revoking one without revoking the others.
Private keys that travel around are "less private". It is best when private keys are generated on a machine and never leave that machine. Thus, if you have 10 servers, you would want to have (at least) 10 private keys. Moving private keys around safely is doable but requires care (copying over SSH connections should be OK).
