Spinning up multiple sets of workers seems to be the easiest way to keep everything isolated as necessary, but also seems somewhat inefficient in terms of resources, as it requires.
Performance is not the main focus of microservices. This is a commonly misunderstood nuance.
Going by the traditional optimization focus on single-request performance (i.e. how long does it take one request to be resolved?), microservices would actually be judged as relatively underperformant. You need multiple machines, your databases are separated and cannot benefit from join optimizations, a single request (to the user) may warrant several calls to separate microservices, ... All of these separations incur the overhead cost of their respective communication layers.
In regards to your question, the inefficiency you're focusing on is not what you should be fixating on in your microservice architecture.
What microservices lack in single-instance runtime performance, they more than make up for by having a much simplified release process, rigorously enforced lack of tight coupling, and the ability to scale services based on concrete usage (without needing to scale services that aren't in such high demand).
In order to maximize these things, the better choice here is to keep your workers isolated, as it maximizes the independence (and therefore also scalability) of each individual microservice; which is precisely the strength of a microservice architecture.