问题
As I described in the question, if I were to implement a microservices architecture, would the centralized read/write database become a bottleneck?
To expand with an example, let's say I have three microservices: users, teams, and team_members. Each has its own microservice, but they all rely on each other in the database, so exclusive, parallel databases wouldn't be appropriate. Since microservices is meant to distribute the work to several different servers, doesn't the central database ultimately defeat the purpose of these microservices, as they all end up calling to the same server?
回答1:
...if I were to implement a microservices architecture, would the centralized read/write database become a bottleneck?
There is a assumption built-in to your question. The assumption is that the microservices must share the same master tables in the database.
In fact, further down your question you give voice to this concept directly:
...but they all rely on each other in the database, so exclusive, parallel databases wouldn't be appropriate.
If the microservices are sharing database tables then all you have effectively done is built one single "service" with multiple components which all happen to consume each other over some out-of-band transport rather than in-memory by direct binary reference.
One of the most important concepts behind service orientation is autonomy, which basically means each service should own its own data.
Extending your example, the users service will know about teams. How will it know? Well, the teams service will push team data to users service. Similarly, the team_members service will receive data from both services. Now, all services have all the data they need to do their jobs.
So by implementing your services as autonomous the potential for contention on the same set of base tables dissapears.
回答2:
To add to what was answered above...
When decomposing your domain, instead of using the single entity interaction model, use the properties/fields interaction and bounded context to compose your components/microservices.
So for example a user account registration will have only the user's fields it is modifying (changing state and therefore own these properties of the entity).
And another component might have the user's address, and another the user's age, gender and marital information, and another will have his credit card and bank details...
You will end up with separate tables for each bounded context.
How you host the tables is up to you and depends on your load and infrastructure (all tables in one database and one server or multiple databases/servers)
Just to clarify, these tables have no referential integrity, if you had referential integrity you would re-introduce coupling and that will bring you back to the database contention issue...
Watch this presentation by Udi Dahan for a lot more details
回答3:
Yes, this design does defeat the separation of concerns and can become bottleneck in future when your microservices will grow and database will undergo frequent changes.(for eg. changes needed in one microservice's database will need a down time for all three.)
Better to have separate database instance for each microservice and use caching for common tables/data.
来源：https://stackoverflow.com/questions/40208887/when-utilizing-a-microservices-architecture-will-the-underlying-read-write-data