Back-end Service development summary

Recently half a year has been doing distributed system development, just developed a small distributed system, now summarizes the experience of distributed system design.

1. Can not be distributed without distributed

The distributed system brings many problems such as data synchronization, data inconsistency, data delay and so on. Network link is unreliable, the distributed system is too dependent on RPC, the same room internal problems are not big, if there are cross-room problem data inconsistency problem is more prominent. We now generally use link interrupt reconnect, important message must answer, the message does not confirm resend to some extent to reduce the probability of inconsistency. But fundamentally solve the problem or the product design process to minimize cross-room business.

2. Select the appropriate message middleware

There are many message middleware, and it is not even possible to implement message delivery. Each message middleware has its own advantages and disadvantages and the scope of application, improper use may have a lot of pits. My project now uses MQ and Netty, and their pros and cons can be seen in another article.

3. Try to be a stateless application

At the beginning of the application design, it is possible to consider the possibility of complex equalization, if it is possible to design a stateless, so that can have a good lateral expansion capability. At the beginning of our server is stateful, load balancing can not do, only split, the state of extracting out into service, only on the load balance, the cost is larger.

4. Fair use of the cache

Caching can be the quickest way to improve performance. Our search service is all done in the cache, so the database pressure is very small, but the database update to update the cache at the same time, increasing the difficulty of development. So the cache is a good thing but not misuse, if the data is not so much can be directly in SQL search, simple and reliable.

5. Test-Driven development

Don't be overly confident about your logic, and the code that hasn't been tested is unreliable. Many developers write the code directly after they have finished writing it, and then they find the bug. I think the bad code is not a big problem, as long as the careful testing at least to ensure that the business on time to go online. The person who does not do the test cannot be determined!

6. Junior Engineer's code must be reviewed

At first, our team code did not have a review session, and the junior engineer code was not controlled enough. Later, the problem was controlled by using Gerrit to force the code submitter to participate in the review.

Back-end Service development summary