Preface
I wrote an article on the spike system before, and finally buried myself in the pit of distributed transactions. Then many readers asked me to write distributed transactions. As a warm guy in the programmer class, I have always been responsive, even if it is I will write it for you if I don’t sleep! 
Because distributed transactions are: distributed + transaction = distributed transaction.
Of course, we must first talk about distributed, and distributed must talk about how this concept evolved. Therefore, as a creative talent, I will first talk about the evolution of architecture. What is distributed? What is a cluster? The relationship and difference between SOA and microservices will be discussed in the next part.
Because I found that most of my readers are students or just graduated just like me, so I have been tired of listening to distributed estimation. I guess I still don't know some details of distributed and the evolution route of the architecture. 
Let me start with a digression. I have always pursued a technical point not only to understand its principle, but also to know which pain points this technical point solves, and what causes these pain points? How was this technology solved before it was born?
That is the overall evolution process, historical context.
For example, why do you need HTTP? Why does HTTP0.9 need to evolve to HTTP1.0? Furthermore, it has evolved to 1.1 and 2 to the latest application of the UDP-based QUIC protocol developed by Google to HTTP3.
Understand these ins and outs, I believe you will not only have a deeper understanding of HTTP, but also a deeper understanding of the Internet. Of course, it doesn't mean that something has to be sorted out as soon as it comes. Some things are more complicated. It just means that we should learn in this direction.
This is also a learning thought that I always think is very important. Knowing the reason and knowing the reason will make everyone better understand many things.
Evolution of general architecture
Okay, let's return to today's topic, let's take a look at the evolution of the general architecture first.
Why is it general? For example, if a leading offline company wants to carry out online related business, it has the support of a large number of loyal offline users, and its own wallet is strong, and there is no shortage of human and financial resources.
Then the online software architecture has to be considered clearly. It is almost impossible to follow the initial stage. Of course, it should not be too hard. Actually, it depends on the architect and team strength to weigh.
Monolithic application architecture
What is a single application? Simply put, no matter what function is written in an application, such as an e-commerce system. User functions, product functions, order functions, etc., are all written in one application.
What are the benefits of this?
At the beginning of the project, small companies lacked human and financial resources and were eager to expand the market. This single application architecture was simple and rude. All functions were packaged in one application and deployed directly.
Local development and debugging is convenient, starting a project directly, debugging is also in one process, there is no lengthy call chain across processes, and errors can be quickly located.
Local function calls, without the overhead of network calls.
If something goes wrong online, just roll back this application (this is actually an advantage to some extent, and a disadvantage to some extent).
The conclusion is that development, testing, and deployment are convenient, and local calls have better performance for remote calls.
What's the disadvantage?
The high coupling of the system leads to low development efficiency.
At the beginning, the module structure may be very clear. As the demand increases, new functions are added continuously, the amount of code increases sharply, the boundaries between modules begin to blur, the calling relationship begins to be confused, and the overall code quality is very dependent on personal level.
If a colleague’s level is poor, the implemented code is redundant, and the logic is messy, it is actually very difficult to add new functions or modify old functions on it at this time. You cannot guarantee that the function modules you modify will not be affected. Other functions.
And the code will have a "broken window effect" (in fact, this is not just a single architecture, it is true for all architectures, but the single application is larger and the business boundaries are not clear, so this problem is more likely to be amplified ).
Some people may say that when they see this, they also say that development is convenient, which is inefficient? Yes, too much is too late.
Another example is the launch of a new demand, such as SMS-related, and some changes have been made to the order, but the SMS function has a bug. It is the entire application that needs to be rolled back. The order module is wrong, and it is rolled back together.
I am doing e-commerce activities in my old club, and one of our online requirements may involve 6 or 7 services, and all rollbacks must be rolled back, and they are all load-balanced, so there may be hundreds of machines.
The language is single, and a more appropriate language cannot be selected according to the scenario. For example, if you want to implement data analysis and the application language is Java, then you cannot use Python's rich class library.
The overall reliability of the system is not high, what does it mean? Let's talk about the SMS function. The new SMS function has bugs. Whether it is stack overflow or infinite loop, the core order and other functions will be affected. Therefore, the problem of your online function affects not only this functional module, but also the paralysis of the overall system. 
The system is not easy to expand and deploy. If you find that your product query traffic is extremely large, you have to add machines if you can’t stand it. Because it is a monolithic application, for the product query function, you need to deploy this application on the newly added machine. It is not possible to customize the deployment for this function alone, which will waste hardware resources.
In summary, the shortcomings are that as the demand continues to grow, the code structure is increasingly complex, the functions are mixed together, the system is highly coupled, and the maintenance of the boundaries between modules is very dependent on the developer's personal level.
There are often common functions between modules that are difficult to distinguish clearly. It is difficult to add or modify functions. It is not sure whether it will affect other modules. All functions are in a process. A problem with a function may affect the entire application, and it cannot be based on The characteristic scene chooses a more suitable language to realize the function, and the technology is single.
With the growth of users, it is impossible to expand the hotspot functions individually, and only the overall application deployment.
So far we have understood the advantages and disadvantages of the monolithic application architecture. It can be seen that the advantages of the monolithic application are outstanding in the initial stage. With the growth of demand and users, the monolithic application gradually cannot withstand, and the shortcomings are constantly enlarged.
In other words, your product needs to be developed to a certain stage before a single application can stand up. Before that, a single application is your best choice.
If you say that my product is definitely top-notch, so from the beginning, the design is drastic, and the single application is too low.
Yes, show your tricks, you have your Young. 
Let's take a look at the general architecture diagram of a single application again. Note that the single application is not really just one deployed online. At any rate, there are two sets, and each other should be backed up. 
After a while, you find that you still need to develop a mobile version. So your architecture becomes as shown in the figure below. 
That's right, in order to prevent each terminal from interacting with each other, crudely copy the existing applications and provide services for the mobile version and small programs with a little modification. You will find that many functional codes are duplicated. At this time, you need to change multiple copies of code.
Microservice architecture
After another period of time, you have strongly felt the pain points caused by the single application, which proves that your product is developing well. You will endure it at first, and continue to endure it. One day you will beat the table! We have to pay our debts for a meeting.
Of course, you will split different services according to different businesses, and you will sort out the current public functions into a public service. Each service is independently deployed and runs independently. The code is physically isolated. A small team maintains a service or Multiple services.
And generally speaking, service-oriented, the database will also be split out. Each service maintains its own database, and the data between the databases is passed through the interface instead of direct access.
At this point, your system becomes like the picture below.
So what is the problem of monolithic applications?
The coupling of the system is reduced, the boundaries between the modules are clear, and they are all physically separated by business.
Under certain measures (mentioned below), the overall system reliability becomes higher.
There is a rich selection of technologies, and different services can be implemented using different technologies or languages. For example, data analysis services can be implemented in Python. Some low-level service teams say that I want to use GO, then use GO.
The deployment can be expanded according to the service, and the number of visits to goods and services is extremely large. Then we will only expand the capacity of the goods and services, add machines, and other services as usual.
This is the microservice.
It seems that the microservice architecture solves all the pain points of a single application? Don't worry, the above is just a part of microservices. The real microservice architecture needs to include many things. Microservices are the pain points of the single application, but they also introduce new pain points! 
After servicing a certain demand online, you will feel very comfortable if it is within a single service that does not affect other services. If the change is an interface-level change that involves multiple services, you will feel a little uncomfortable.
Before going online, you need to customize the order of service online, and customize the rollback plan for each service. It involves cooperation between each team. Going online is no longer a simple packaging and deployment process.
When something goes wrong, it is not a simple rollback process, but it may be that each team rolls back their services separately. If there is a problem with your own service, you will be very anxious, and other teams are waiting. If there is a problem with other teams, you are also anxious, why is it not good?
You will also find that local development will be extremely uncomfortable if you rely on other services, especially if the services you rely on also rely on other people's services, debugging and testing will become complicated.
And you will find that the call link becomes longer, the call increases the network overhead and the performance deteriorates. And errors are difficult to locate the source of the problem. So you need to introduce a distributed link tracking service to locate the problem.
It is also necessary to introduce ELK to facilitate log viewing and analysis of problems.
In order to be able to dynamically expand, your service needs to be automatically registered and can be automatically discovered, so you need a registry.
Calls between networks are relatively unreliable, so you need to have a retry mechanism for calls to prevent bugs in other services or crazy calls to your services for other reasons, and flow-limited measures are also needed. In order to prevent a service from going down and leading to an overall avalanche, a circuit breaker is needed.
In order to give up hardware resources to core functions at special times such as big promotions, a downgrade strategy is also needed.
The above mentioned retry, current limit, fusing, and downgrade are the certain measures mentioned above, the reliability becomes higher.
And each service needs to be configured, so there must be a configuration center for unified management.
There are too many services and the calling relationship is complicated. In order to be more friendly to the caller, and also need to control the permissions and other calls, it is necessary to have a gateway to expose a unified interface to the outside world. Of course, what you want to limit can be implemented in the gateway.
Of course, overall monitoring is essential, and all services need to be fully monitored.
There are other DevOps, containers, etc. 
You can see that there are too many things that need to be introduced after servicing. Some people may say that you only have a few services. The services above can actually be subdivided.
For example, the modification and writing actions of the product must be much less than the browsing traffic of the product, so I will separate the product browsing and make a separate service, which is convenient for expansion.
With the increase in user volume and the increase in visits, you will find more and more services will be stripped away. The number of services will come up at that time, and the demand will continue to increase. There are many recommendations, search services, etc., just for Simple is not listed.
The components mentioned above that serve microservices must also be deployed, and reliability must be ensured... You see, the system is becoming more and more complex, so after the service is decoupled from the business, it is integrated into non-business related s things.
However, servitization is actually a natural result. Just like the service hall we usually go to is divided into different service windows according to the service category. In order to do a thing, I may need to move back and forth between the various windows. Is the link length called? The time consuming to walk is equal to the network overhead we call.
Therefore, the microservice architecture is a natural evolution product of a stage of development. Many companies have already done this before the concept of microservice was proposed.
What I mentioned above is actually the microservice 1.0 architecture, and the microservice 2.0 is proposed to separate non-business functions. The service governance function is placed on the SideCar, which allows developers to focus on application business development. , And then evolved Service
Mesh that is a service grid architecture.
SOA and microservices
When it comes to microservices, you will find that the term SOA often accompanies it.
I have consulted a lot of information about SOA and microservices, but the explanations for these two terms are different, and there is no unified answer. Today, I will talk about my understanding and provide some suggestions. Please correct me if there are any errors.
SOA, the full name of Service-Oriented Architecture, is service-oriented architecture. When it comes to SOA, it is inseparable from ESB, the full name is Enterprise Service Bus. SOA and microservices are both service-oriented. 
It can be seen that the SOA architecture interacts through the enterprise service bus, that is to say, centralization requires development and transformation in accordance with bus standards, while microservices are decentralized.
In fact, we can catch the keyword enterprise. I think SOA is an enterprise-level service-oriented concept, while microservices are an application-level concept.
Both are service-oriented, but SOA focuses on the reuse of enterprise resources and integrates various enterprise applications through ESB.
Microservices focus on application-level service division, which makes the service boundaries within the application clear and easy to expand.
The two are actually service-oriented in two directions and do not conflict with each other. It can also be an inclusive structure, as shown in the figure below
Distributed and clustered
Distributed can be thought of as a system formed by connecting multiple components through a network.
Broadly speaking, applications that are separated from the front and back can be considered distributed. The front-end js code runs in the browser and the back-end code runs in the server. Two different components work together to provide external services to form a distributed.
And the distributed one we often mentioned is in a narrow sense, referring to a system composed of different components through collaboration.
Clusters often refer to multiple instances of the same component to form a logical whole.
These two concepts do not conflict. Distributed systems can include clusters, like our commodity services can be cluster deployment.
Talk
Today I mainly briefly describe the evolution of the next architecture, the advantages and disadvantages of a single application, and the advantages and disadvantages of microservices.
Let’s talk about the difference between SOA and microservices, and the difference between distributed and clustered.
Having said so much, I don’t know if I have made it clear. Personal ability is limited. If there is any mistake, please correct me. Distributed transactions are also in madness.
This is Ao Bing. The more you know, the more you don’t know. See you next time!