- Database problems when microservices are split
Note: After the microservice is split, the corresponding database will also be split. That is, a simple function that can be solved in a single query, split across multiple microservice queries. If one of the tables has less data, it can be solved in a code loop; if each microservice has more data, it can be troublesome.
Scheme 1: Use view to strongly associate the middle table of two libraries through view. Of course, this also avoids the decoupling of microservices
Scheme 2: Temporary table or cache, through the temporary table or cache to build temporary associated data, clean up after use
Scheme 3: data redundancy, sacrificing space for time. Similar to index, sacrifice index space for query speed.
In scenario 3, the problem of data synchronization can be solved by MQ
- Microservices split granularity
The issue of microservice granularity has been discussed many times. Splitting is an iterative process, don’t try to make it very thin all at once, don’t make it too thin at first. In general, the finer the microservice segmentation, the more complex the integration before the module. Business and database can be combined together to split and cross-reference.
- Each micro service between the development of their own snow
After micro-service, everyone should focus on their own services. When it is necessary to increase or adjust the business of the other party indirectly, it is difficult to coordinate the business. It is suggested to use some old technology of the team to serve as business experts (common technology sinks, and focus on business instead of technology).