问题
I have two modules(mod1 with DB1 and mod2 with DB2) hosted as microservices. Both modules have some common functionality which can interact with DB1 and DB2 both.
Approach_1:- Make another mod3 as shared library jar for common component and inject it in both modules to avoid duplication of code
Approach_2:- Make another micro service for common component instead of shared library jar.
Not sure which approach is better in term of design and what criteria I need to consider here?
Per my understanding, It should be a shared library instead of microservice as it will interact with multiple DB. If it is shared jar, that module logically lies with caller module business wise.
回答1:
If you have two micro services that both access the same two databases, and you are thinking about factoring the common database-access code out into a library, then you should at least consider the idea that you really only have one microservice.
Think about what would happen if you changed the schema of one of the databases. You'd have to update both of the microservices in order to deal with the change. If you had a library, you'd have to update the library, then build and release both of the micro services. What are you gaining by maintaining two microservices instead of just one? It just seems like more work.
You might say, well sometimes I might make a change that only affects the logic of one microservice, and then I could build and release just that service. That's true, but if you had one microservice, you'd still just be building and releasing one microservice. It's not easier to build and release one microservice just because there exists some other microservice that you're not building and releasing.
回答2:
If you have common functionalities that use the DBs of two different microservices, follow this two steps:
- Re-check the bounded context i.e. your initial understandings and assumptions based on which you took the design decision to seggregate the functionalities into the two microservices. Maybe you need some refactoring there or maybe not.
- If you are convinced that your bounded context is correct. Try to merge the common functionalities into appropriate microservices (one of the two services) such that you will update only the local microservice DB directly and the other micro service DB either through an API exposed from the other microservice (this will definitely cause tight coupling but maybe appropriate in some circumstances) or by using streaming as explained in this answer.
Note that the slight delay (maybe a few seconds) to update the second microservice DB may not be as bad as it may appear initially. "Apology" plays an important role here. Many e-commerce site sends apology to the customer for not being able to fulfill their orders even though the order is successfully submitted. From that perspective Saga pattern maybe useful where it would do compensating transaction in the first microservice if it cannot apply the changes in the second microservice as the business logic doesn't hold anymore by the time the streaming event reaches the second microservice.
In short, the two approaches you mentioned go counter to microservices architecture
来源：https://stackoverflow.com/questions/54662192/select-micro-services-vs-library-as-dependency