The emergence and significance of micro service

The emergence of micro service and the exploration of its significance

With the development of Internet , The number of users is also growing rapidly , And a variety of original simple problems are due to the rise of traffic and a series of problems ... And the traditional application architecture model is also gradually difficult to support such a large amount of traffic , How can we increase the load of our application by changing the traditional architecture pattern , It has become a problem that every programmer often discusses ...

Don't make too many changes on the original application layer , By means of web Load balancing on the server , To alleviate web Layer pressure , adopt mysql Separation of reading and writing , To reduce the pressure of reading operation （ Read / write separation , Can only greatly reduce the pressure of data read operation , There is not much pressure on write operations ）; By introducing caching （redis etc. ） To reduce the pressure on the data layer ... That's true ！ Cluster through the machine is indeed an important way to quickly improve the application load ; But through the test of time , We also found that ： As the business grows , The content of the app will grow rapidly , Applications are getting bigger and bigger , Only through the hardware into the group to solve the problem of bearing capacity, the resistance will be more and more big ; Such as ：

1. More and more applications , The maintenance cost is extremely high
2. Business level things can't , Independent online , It affects each other a lot
3. The internal functions of the application are also separated “ Low coupling 、 High cohesion ” More and more far away

In fact, there are a lot of problems, just a little casually written on it , So we often notice that some big bulls share their architecture , Always say , Because of so and so , We provide micro services , Our company has developed a service governance framework .

That's the question. What is microservice ？ In fact, my understanding is very simple , That's the function “ modularization ”, Of course, this modularity is different from the modularity we use when we write code , But it's not far away , In fact, it is equivalent to making modular things independent projects , Decoupling is achieved by external calls （ Simple understanding is interface mode ）, Different function modules provide different services ;

After reading so much, I still have some understanding words ！ Now I will elaborate my opinion through a mall project ：

1. Traditional single service support application

Be careful ： Above mentioned nginx Service layer , And the data layer , There are also some dynamic code parsing , Single service delivery , It doesn't mean they are all installed in the same computer ... This is different , for example ：nginx,php-fpm,mysql It doesn't have to be all on one computer , Can be separately installed on different computers through the network call yo ;

This way is to compare the original application mode ;

Open a service to provide all services of the whole mall project ; In fact, we can see that , Single service layer , It is difficult to provide a relatively large carrying capacity for an application ;

Since the service capacity provided by a single machine is limited , Then we try to build a cluster of machines , With a bunch of machines ... Then we derive the architecture of cluster mode that appears later ！

2. Cluster support services

This architecture is also now , Architecture commonly used in medium-sized projects ,web Layer through load balancing to reduce the pressure of the machine , The database is read-write separated by master-slave replication , Hot backup of database can be realized by master master replication . In the business layer, we introduce caching components （redis） To reduce database pressure .

In fact, in my opinion, the above architectures are all monomer architectures ：

That's the question , What is a single architecture ？

In a nutshell , All functions , The business is focused on one project , Unified release , Unified deployment , Deployed in the same process ; This is the monomer architecture ; As can be seen from the above figure, it can be seen in fact Whole All functions of mall project , Basically all run in the same process ; Or it can be understood as " David and Jonathan ";

What are the benefits of a single architecture ？ The existence must have its rationality ;

1. Simple function development ： Simple addition of single function
2. Easy to redeploy the entire system ： Directly package and publish all code to the specified environment
3. Easy to test ： Release a single system to test
4. The overall horizontal expansion is convenient ：nginx Simply do load balancing

Now that there's evolution , That must be because of the development of the times , Monomer architecture faces new challenges ;

1. Fast code expansion , Maintenance costs are huge
2. Long delivery time
3. Difficult handover of team members
4. Poor scalability （ Different modules need different system resources ：CPU, Memory , disk space ; There is no single point correspondence ）

Maybe you'll find out , The advantages and disadvantages of monomer architecture seem to be contradictory , It's not , After all, in a different environment , At different times , The advantages and disadvantages are mutually transforming ; Let's give a few examples in detail ：

With the development of the project , Expansion of business scope , Increase of user volume , Growth of development team , From the original 5~6 Human maintenance , Now it's a hundred people working together to protect , There will be problems ：

1. As the user system grows larger , The access pressure of some modules will continue to increase , In fact, some modules don't need larger load capacity with the increase of user system ; But because the system is still centralized , So there is no way to achieve single module expansion ; This is actually a waste of resources ;（eg： There's no way to be single User module load ）
2. Business scope expansion , Single system architecture also brings great difficulties to maintenance and upgrade , When the first mock exam is released, the whole system will stop providing external service ; To avoid such a problem , It often requires a lot of regression testing ; It also leads to a lot of human resource consumption ..
3. The risks are huge, too , When the first mock exam is wrong ; Large consumption of system resources , It will cause other modules to fail to provide services ;
4. The system is constantly upgrading , Function accumulation , As a result, the amount of system code is increasing , The complexity of system code is getting higher and higher , It's also a huge challenge for new employees ;
5. When there is a problem with the system , Because the system is bloated , We can't locate and solve problems quickly

3. The emergence of microservices

Since with the development of the times , Monomer architecture faces great challenges , Traditional technology architecture is difficult to support the current Internet user system ; Micro service came into being ;

So what is micro service ？

1. The system is split into multiple services , Each service runs in a separate process ;
2. Use lightweight communication mechanisms
3. Deployment through automation
4. It has a relatively independent and complete alarm and fail over mechanism

Features of microservices

1. Single responsibility ： Each service provides a single service ; This also greatly improves the positioning of the problem and the speed of solving .. After all, which service is which person is responsible for , Everybody knows that .
2. Lightweight Communications ： In fact, this is also very easy to understand , It's cross platform , Cross language communication is particularly important ; The system is divided into multiple services , When providing different services , May appear “ flowers ” The situation of ; And cross platform , Cross language communication is particularly important (http,rpc etc. )
3. Isolation, ： Each service will be deployed in a relatively separate space , Realize the isolation of system resources ; In short, it's to prevent your code from losing my business ..（docker It's a good choice ）
4. With independent data : The simple understanding is to use independent data storage services ;
5. The diversity of Technology ： Different service bottlenecks will lead to the diversity of technology selection （eg: A lot of push may use queues instead of rabbitmq; a large number of cup The operation may be selected go or c As the choice of development language ; Business level rendering more services , May choose php To quickly iterate ）

Here's a simple architecture diagram

Be careful ： The picture above says that API Gateway It's a simple gateway ; Can achieve ip Limit , Flow limit , Interview Statistics , Load balancing and other functions （ It's an interesting thing .. We will discuss and learn in detail later ..）

No best architecture , Only the most suitable , In fact, microservices also have their own disadvantages ; Especially the lack of team members , Or over service , The relevant mechanism is not well done （ heartbeat , Risk control , Fail over , Log summary and analysis ） Will cause the problem to enlarge infinitely ;（ I have suffered a lot ...）

1. Division of services ： Put aside technology implementation （ After all, there is a mature and relatively complete technical architecture on the market that can be copied ）, I think service division is the most important key to the success of servitization , How many services are split ？ What functions should be in the same service ？ What is the strength of service splitting ？ These problems need to be determined according to specific projects and specific company resources , Only through trial and error and detection can we find the right answer for our company ... However, many companies have no way to , Through these difficult and dark times .. So microservices are not for every company .. But I think it is an important topic that every company has to learn and explore ..
2. Data consistency ： When the service is split , Data consistency has also become a very important issue ; Common solutions are ：a) Through middleware to achieve transactions many times commit; To achieve the ultimate commit; If you are interested, you can learn about “TCC Distributed transactions ” b) My company uses transactional final consistency ; Through the queue （rabbitmq） Ensure that all services call each other, and the final modification must be submitted successfully ..
3. Troubleshooting of complex functions ： After service , You will find that your complex functions call each other between different services . When a problem arises , You need to find the corresponding link , You'll find it hard ... Of course, if you have a perfect micro service, you have done a perfect “ Distributed log link ” and You have a complete set of Alarm log collection and analysis （eg：elk） Mechanism ; You'll find that It's so easy to solve problems ..（ However, many companies do not achieve these better infrastructure ..）
4. Huge increase in communication costs ： This is also an obvious problem , In the past, you worked it out by yourself .. Now dozens or even hundreds of people are working together ... Communication becomes the biggest consumption ... Sometimes you find out , One of your functions will be implicated 5-6 Service assistance （ It's no exaggeration ..）