microservice architecture questions about code res

问题:

I have the following questions about micro service architecture

1. How common code/utility-libs are being reused between different micro services? Where this common code is also being developed

2. In my micro-service some services are for clients and some can be internal ( for other micro services to use). What is the best option to make internal services secure?

3. What if two micro-services has to use the same database? Say they do totally different operations but using the same database table?

4. Micro services are mostly about the back end but the GUI is going to be the same. In that case each micro service deployment requires website update as well. Is that consider as a disadvantage?

回答1:

DISCLAIMER: These are answers based on my point of view based on my experience working with various microservice based architecture.

1. Ideally microservices should be independent and they shouldn't share binary dependencies (specially for domain concepts). In reality, specially for big architectures, that is more challenging than it seems at first sight. One of the idea behind microservices is that you could swap one for another without any other microservice noticing, provided they reply to the same messages. This becomes easily a nightmare when you start introducing binary depdencies.

2. One of the possible approaches would be to treat other microservice as a particular client, giving them a specific role that allows for certain operations to be executed. However, you can consider deploy a specific microservice that only answers on a subnet non visible by the outside network. I would still perform some kind of access control between parties (although I never used it, http://jwt.io/ seems to be picking up). The mechanism for authentication would be similar to the one used to authenticate your clients.

3. I wouldn't - specially because of what I described on point 1. You'll be introducing a high risk of services stepping on each other toes, losing the "independent" part which is key for a microservices oriented architecture. Every service should own its own storage, because you should be able to be change storage engine for a single microservice at any given time without changing behaviour of the other services.

4. I'm not entirely sure what you mean here. It's very important to maintain backwards compatibility when dealing i.e. with frontend client. You can version your microservices (e.g. /v1/messages if you're using a REST like approach over HTTP), then have your client use a specific version of the service. By using different version, you can decouple frontend and backend service releases so - again - they're independent.

It looks like a lot to think about (and it actually is), but using good practices from the start will lead to avoid a lot of problems later.