[learn micro services from 0] [02] move from single application to service

---

Continuous learning & Ongoing update …

Keep breaking away

---

When should I split a single application ？ What are the standards for split monomer application ？

When is the service split

• The main goal of the first phase of the project is to quickly develop and validate ideas , Prove whether the product idea is feasible . At this stage, the functional design is generally not too complex , Development takes a fast iterative approach , Architecture is not suitable for over design . So all functions will be packaged and deployed together , Centralized development 、 Testing and operation and maintenance , For the initial stage of the project , Is the most efficient and cost-effective way . When the feasibility verification passes , The function is further iterated , You can add more and more new features .
• For example, do a social networking App, Early in order to quickly go online , Verify feasibility , Can only develop homepage information flow 、 Comments and other basic functions . After product launch , After a period of operation , The number of users is increasing , Pass the feasibility verification , In the next stage, we need to add more new features to attract more target users , For example, give this social intercourse App Add a home page to show 、 Message notification and other functions .
• If we continue to adopt single application architecture at this time , Multiple function modules are developed together 、 Test and deploy , It will lead to the interaction between different functions , One package deployment requires all functions to be tested OK To go online .
• More Than This , Multiple function modules are mixed together , It's also a huge challenge to the stability of online services . such as A A function of development is not comprehensive enough due to the consideration of code writing , Memory leak occurs after online , After running for a period of time, the process exits abnormally , Then all functions deployed in this service pool are inaccessible . A classic case is , There was a video App, Because in a short time, a paid video has a huge number of visits , It exceeds the carrying capacity of the server , This makes this video inaccessible . Unfortunately , The site deploys paid video and free video services together , It also spread to the free video , Almost the whole station collapsed .

Two postures of service splitting

• So how to implement the service splitting ？ One of the most effective means is to service different functional modules , Independent deployment and operation and maintenance . With the aforementioned social App For example , You can think of homepage information flow as a service , Comment is a service , Message notification is a service , Personal homepage is also a service .

• This service-oriented splitting method is Vertical resolution , It is split from the business dimension . The criteria are based on the degree of relevance of the business , Closely related businesses are suitable for splitting into a microservice , The relatively independent business is suitable to be separated into a microservice .

• Another way of service-oriented splitting is Horizontal resolution , It is split from the public and independent functional dimension . The standard is based on whether there are public calls by multiple other services , And the dependent resources are independent and not coupled with other businesses .

• Continue with the previously mentioned social App give an example , Whether it's the homepage information flow 、 Comment on 、 Message box or personal home page , All need to show the user's nickname . If the user's nickname function has a change in product requirements , You need to go online with almost all the services , The cost is a little high . Obvious , If I deploy the user's nickname function as a separate service , So if there is any change, I just need to launch this service , Other services are not affected , Development and online costs are greatly reduced .

Preconditions for service splitting

• In general , The introduction of new technologies into business systems will inevitably lead to an increase in the complexity of the architecture , Before making a specific decision , You must first recognize what new problems the new architecture will bring , Can you and your team solve these problems ？ How to solve ？ It's about investing in human resources , Open source solution in the industry ？

• Here are a few questions , When migrating from a single application to a microservice architecture, it must be solved as well ：

• How services define . For monomer applications , When different functional modules interact with each other before , It usually provides the function of each module in the way of class library . For microservices , Each service runs in its own process , In what form should we convey our message to the outside world ？ The answer is the interface , No matter what kind of communication protocol is used , yes HTTP still RPC, All calls between services are specified by the interface description , The contract includes the interface name 、 Interface parameters and interface return values .

• How services publish and subscribe . Single application is deployed in the same WAR In the bag , The calls between interfaces belong to in-process calls . After splitting into microservices for independent deployment , How should service providers expose their addresses , How can a service caller query the address of the service to be called ？ At this time, you need a place like a registry , It can record the address of each service provider for service callers to query , In the microservice Architecture , This is the registry .

• How does the service monitor . Usually for a service , What we care about most is QPS（ Adjust dosage ）、AvgTime（ The average time taken ） as well as P999（99.9% Within milliseconds of request performance ） These indicators . At this time, you need a general monitoring scheme , Be able to cover the business sites 、 data collection 、 Data processing , Finally to the full link function of data display .

• How services govern . As you can imagine , After splitting into microservice Architecture , The number of services has increased , Dependencies are becoming more complex . For example, when there is a problem with the performance of a service , The services we rely on are bound to be affected . You can set a call performance threshold , If this value is exceeded over a period of time , Then the call that depends on the service can directly return , This is fusing , It is also one of the most common means of service governance .

• How to locate the fault . After a single application is split into microservices , A user call may depend on multiple services , Each service is deployed on a different node , If there is a problem with the user call , You need a solution that can tag a user request , And continue to deliver... In multiple dependent service systems , In order to concatenate all paths , So as to locate the fault .

• For the above problems , You must have a workable solution after , In order to further split the service . Later, I will explain the corresponding solutions to you one by one .

summary

• Whether it's a vertical split or a horizontal split , It's all about splitting the complex functions of single application , Pull out into a separate service deployment .

• But it doesn't mean that the finer the function, the better , Excessive splitting will make it difficult to manage the expansion of services , Therefore, it is advisable to find a resolution granularity that is consistent with the current business situation and the technical level of team members . My suggested standard is that each developer is responsible for no more than 3 A big service as the standard , After all, everyone's energy is limited , So when splitting the microservices , It can be decided according to the total number of developers .

Reference resources

Geek time : from 0 Start learning about microservices -- First line practical experience of microblog service experts

---

The end of this paper , Thank you for your attention and support ！

---