问题
We have a monolithic web based CRUD application (call it A) which does a certain task. Now, we have a new requirement which is more or less independent of A functionally. The audience is different, the times of use, the functionality etc. are all different. Because of this, we decided to build this into a new service B.
The problem started when B required authentication information from A. Anticipating that this might happen again, we pulled out the auth from A and put it as separate provider C. Both A and B can authenticate against C which now contains the user information.
The next question that came up was what about user profiles A used to hold the user profiles but now, we moved most of it to C. However, there are a few extra fields that we need to keep which B needs. The question is whether I should
- Keep all the fields in
Csince it is the authentication service and the place to keep all user information. - Keep it in
Bsince it's the only place it will be needed.
More generally, my question is how to decide how to carve up the monolith into separate pieces, how to split the data and what do I do about things like userids which are "shared" across all the services?
回答1:
I agree with Gilbert's comment: Data fields that are related to the user should be kept in the user authentication service.
In general, there is probably not the one "correct" way to set the boundaries, but there do exist some general concepts such as the idea of bounded contexts. Also, an important objective that you should keep in mind when dealing with a microservices architecture is that services should be able to be developed and deployed independently of each other.
Some more resources and best practices on the topic that I have found useful:
- How to break a Monolith into Microservices
- Using domain analysis to model microservices
来源：https://stackoverflow.com/questions/60705991/how-do-i-create-boundaries-for-my-microservices