Big system with small scale and service splitting are the characteristics of Internet applications and also conform to the concept of agile delivery. For traditional software, such as Windows and Office, they all have to go through a long cycle of demand, research and development, testing and release. In the Internet era where "speed is everything", this obviously cannot meet business requirements. Even if it is finally launched, it may no longer be applicable due to the long cycle.

Therefore, for an Internet service, the most core functions will generally be completed first, launched quickly, and continuously iterated, and then auxiliary functions will be followed up. For core functions, as the number of users increases, services will be continuously split. How to split and to what granularity? Is microservice the silver bullet to solve the problem? These must be evaluated according to the actual application scenario. It is not the case that the finer the better, but to achieve an elegant balance.

Concurrency control and service isolation. Concurrency control has now become a basic requirement for Internet services. There are also mature solutions on the application side and the database side. If ignored, it may cause disastrous consequences. For important services, we also need to isolate them.

For example, the same service needs to be provided for internal calls, company-level calls, and open service calls outside the company. We generally believe that open service callers are unreliable and may even be malicious. If we do not isolate them, open service calls may fill up service resources and make it impossible to provide services internally. Technically, it can be hardware-level isolation, full isolation, or isolation of front-end applications.