Distributed architecture: principle, design and actual combat. At present, the company has to pay out every month, and the bill is to calculate the previous month’s accounts clearly every month, so that there is no tolerance for errors, and no one can be wrong. , The wrong customer will find you, partial accuracy. Four nines and five nines are not meant to be designed later, but to be considered at the beginning of development.
The development history of distributed services
- J2EE architecture
Commonly known as JEE. For veterans with more than five years of work experience, they should have heard this term. Basically divided into 3 layers.
- web container
- EJB container
- ORM for database and data access
At that time, there was no physical isolation between the containers, and they were all deployed on the same jvm. So over time, their mutual coupling and mutual dependence, the business is inexhaustible before, when adding and modifying to add new business, they become very complicated, often resulting in service unavailability. There are levels in this era, but there is no physical isolation before levels. Brings some problems.
- SSH architecture
The open source framework SSH = struts + spring + hibernate, in fact, it is basically similar to the JEE architecture, and the components are divided into three layers.
- struts MVC UI components
- Spring business components, which implement business logic
- ORM object management mapping layer, connected to the database
SSH was very popular at that time, because at that time, the system was built for traditional industries and manufacturing industries, and the SSH architecture in the Internet industry was not working.
- Web Service architecture
The Internet industry tends to be servicing. The most popular microservices originated from servicing, and servicing was first embodied in web services. Web services are standards set by major companies headed by IBM. After the development of webservice features, they are not deployed on the same platform. The machine, on the same JVM, is split into different services, such as web service1, web service2, and web service3 in the figure. These three have their own roles and have their own functions. Services and services were previously called remotely. To achieve mutual realization and communication, remote calls follow the established standards. At that time, the standard was the SOAP protocol. This protocol was based on the http protocol to transmit xml. With these services. The service discovery mechanism is needed, which is realized through the webservice directory. All services that provide services to the outside world need to be registered in webservice. Find service UDDI, find service WSDL find service. The main characteristics of services in this era are: separation of duties, isolation of service deployment, and service invocation compliance with agreements. The protocol defined by webservice is very heavy. First of all, xml is serialized, and xml has redundant tags, and the service performance cannot be improved. Webservice registers for communication-based services, and communication-based registration services must ensure high availability. If it is not highly available in the Internet, the service is not the most optimized.
- ESB architecture
Enterprise Service Bus, focusing on Enterprise Service Bus. The top is the service provided, and the bottom is the database data source, message queue, big data, ERP. As long as all services and resources enter the ESB, they will be orchestrated to complete specific functions. During this period, the ESB function was split, and it also had its own responsibilities, all of which were split, in different physical machines, in different JVMs. Mainly reflected in the pluggable, fast adding and deleting services, and fast adding resources.
- Microservice architecture
The most popular architecture is in line with the traditional architecture and is not contradictory. The concept of layering is adopted. The services of the upper layer depend on the services of the lower layer. There are basically two layers, the first layer: business service one; the second layer: business service 2, 3, 4. The upper layer and the next layer are dependent, but not circularly dependent. Each service uses the database itself. In fact, the database cache and message queue are autonomous. This allows the microservices to have the authority to manage themselves. The microservices can quickly digest the needs, quickly go online, and improve development and operation. The efficiency of dimension, microservices was previously realized through remote service calls. For remote service invocation, there is no specific requirement whether to use restful or rpc. There must be a contract between services. The contract can be proposed by the service producer or the service producer contract proposed by the service consumer, or it can be multiple services. Consumers ask the producer of the service together to make a request, and the producer of the service provides a public contract to ensure that there is no problem in communication. For example, when a demand comes, first split the service and split it into different microservices. The microservices have a good communication contract, and the needs are digested in the service regardless of the external functions. Going online and responding to the market is also very agile. The split of each node of the microservices is relatively single, and they are all relatively detailed. After the responsibilities are single, professional people do professional things, it is difficult to make mistakes, and the usability of the system is improved.
- Team management of microservices
The team is actually autonomous. There may be products, operations, testing, and development in the microservice team. If the system is assigned to a team, the development within the team can communicate very quickly, and the development will go online quickly. There is no need for cross-team communication or cross-team coordination. Looking back at the original SSH, the company is divided into UI groups , The development team, the test team, and the DB team communicate, and the team that is not a microservice leads to low communication efficiency. So this is what microservices advocate is agile, professional people do professional things.
- The essence of distributed service architecture
Agile online and autonomy under microservices effectively reduce unavailability factors. Servicing and microservices both use the idea of divide and conquer. In distributed services and distributed system architectures, whether it is to improve performance, increase throughput, and improve agility.
- Pain points of microservice architecture
- consistency
Strong and weak consistency
- high performance
Capacity assessment and performance testing
- High availability
4 9s and 5 9s
- Scalable
Modifiable, iterative new functions, pluggable
- adjustable
Application layer and resource layer, with the increase of hardware investment, performance and capacity increase correspondingly
- safety
Anti-peeping, anti-leakage, anti-repudiation, anti-tampering, anti-man-in-the-middle attack
The best solution to ensure distributed consistency
During the Zhou Dynasty, divide and conquer, and later did not listen to Zhou Wang, resulting in inconsistency. The pain points caused by inconsistency are great. How to resolve inconsistencies. Sharing of pits and summarized experiences online.
- Principle of consistency
Essentially, you need to understand the following three types, what they are, and the application scenarios.
In ACID, database theory, we have all learned that ACID is strong consistency. The four nouns represent that a transaction cannot be split, either all succeed or all fail. In traditional databases, there are monolithic applications, and monolithic applications must maintain strong consistency, especially our relational databases. Hesitate on the high concurrency of the Internet. The number of users is very large, thousands, tens of thousands, hundreds of millions. It is difficult for a single service architecture and a single database to support such a large amount. Therefore, they need to be divided and conquered before, separated on the Internet, separated, and divided. sheet. The problem is whether these applications can work normally when the network has problems. This introduces the CAP principle.
CAP must have network communication between them, and there must be partition fault tolerance, that is, when a node network cannot communicate normally. If the network is down or intermittently, work will continue between each other. P is definitely necessary. The principle is that if the three can only choose two of them, and P is already necessary, then one needs to choose between C and A. For example: There is a piece of data on the network, and the data is completed by copying. One is the master data and the other is the slave data. When you save a copy of the data to the master data, you also need to save a copy in the slave data. If there is a problem with the slave, whether to continue or return to the master, this It is the interpretation of consistency and usability. If the master and slave must be consistent, and the master and slave can be returned only after they are saved, then consistency is guaranteed, and availability is not good. If there is a problem with the network, they must wait for the consistency before returning. Requests that will not be returned to the client within a limited time have poor availability, so consistency and availability are mutually exclusive. If it is returned to the client quickly, it may sacrifice consistency to maintain availability. The conclusion is that on the basis of fault tolerance, availability and consistency are mutually exclusive. Can't have both.
BASE is basically available, with a soft state in the middle, and finally remains consistent. Basic availability is the condition, and consistency is the goal. The soft state is the BASE method in advance, that is, we have to do one thing. The process of achieving the goal requires two or three stages. After finishing one stage, we can record the state information, and then we can do the second stage. We can start from the problematic one. The location is restored to where the problem occurred. Many high-concurrency projects on the Internet use distributed transactions and are discounted to achieve final consistency. Using the BASE principle, CAP restricts that it is impossible for the three to exist at the same time.
- Conformance Agreement
Coordinator of two stages
Three-phase coordinator
TCC（Try）
- Final consistency
Query mode
Compensation mode
Asynchronous Guaranteed Mode
Regular proofreading mode
Reliable message mode
- Service interaction mode
Sync mode
Asynchronous mode
Message mode
- The choice between synchronous and asynchronous
Try to use asynchronous instead of synchronous operations
Problems that can be solved by synchronization, do not introduce asynchrony
- Timeout mode
Synchronizing the interface of the two states timed out
Internal timeout for synchronizing two states
Internal timeout for synchronizing three states
Asynchronous call timeout
Message queue sending timeout
Message match receiving timeout
- Compensation game
Service 1 calls service 2. If service 2 responds to service 1, and tells service 1 that I have received the message, then the task of service 1 ends. If service 2 fails, service 2 should be responsible for retrying or compensation. In this case, service 2 usually persists the message first and then tells service 1 to receive it successfully, and then service 2 starts to process the persistent message to avoid the situation that the service process is foolishly lost.
Service 1 calls service 2. If service 2 does not give a clear reception response, then service 1 should continue to try again, knowing that service 2 clearly stated that it has received the message. In this case, message duplication is prone to occur, so in service 2 Usually, filter weight or idempotence should be guaranteed.
- Consistency mode used by the cache
The cache is used for acceleration, at the expense of consistency, to obtain high performance, and is only suitable for special scenarios.
Maintaining strong consistency between database and cache is a false proposition
If the performance requirements are not very high, try to use the distributed cache instead of the local cache. The local cache may be turned on when you read it. In fact, other people are reading it at another time. It’s scary if you think about it.
When kind of caching, it must be complete. If part of the cached data is valid and part of it is invalid, I would rather give up the kind of caching instead of putting part of the data in the cache.
Under normal circumstances, the order of reading must be cached first, then the database, and the order of writing must be database first, then cache
- Design pattern of migration switch
Migration of old and new systems.
Do not use a unified configuration switch, the switch is defined on a certain business. Doing filter weight in one system is easier than doing filter weight in multiple systems.
Do not use node independent switches
Migration switch must use order switch
The switch should be controlled by authority. The importance of the switch is operated by someone with specific experience.
The switch must be able to turn on and off
The migration switch needs to be both large and small
PS: Understanding the distributed architecture is a kind of mental improvement for oneself, typing code is just looking down, it is recommended to look forward. The road of architecture is not easy to follow. It requires more contact, multiple trips, and multiple walks in order to break through the road ahead.