Shulou(Shulou.com)06/02 Report--

[this article is transferred from the blog park author: Ah Hao chatting on practical information. Original link: https://www.cnblogs.com/hafiz/p/9236664.html]

I. Preface

In the last article, we talked about the evolution of distributed architecture, so in this paper, let's talk about the current mainstream distributed architecture and common theories in distributed architecture, and how to design a highly available distributed architecture. Among the distributed architectures, SOA and micro-service architecture are the two most common distributed architectures, and the concept of service grid is becoming more and more popular. So let's start with these common architectures.

II. Analysis of SOA architecture

The full name of SOA is: Service Oriented Architecture, which is defined as "service-oriented architecture" in Chinese. It is a design concept that contains multiple services, which ultimately provide a series of complete functions through interdependence. Each service is usually deployed and run independently, and the services are invoked through the network. The architecture diagram is as follows:

Compared with SOA, there is also a concept called ESB (Enterprise Service bus). To put it simply, ESB is a pipeline that connects various service nodes. ESB exists to integrate different services based on different protocols. ESB does the work of message conversion, interpretation and routing to interconnect different services. As our business becomes more and more complex, we will find that there are more and more services. Under the SOA architecture, the invocation relationship between them will become as follows:

Obviously, this is not what we want, so if we introduce the concept of ESB, the project call will be clear again, as follows:

The core problems to be solved by SOA

Integration between systems: from a system point of view, we first need to solve the communication problems between various systems, in order to sort out the scattered and unplanned network structure between the original systems into a regular and governable star structure. The implementation of this step often requires the introduction of some concepts and specifications, such as ESB, technical specifications and service management specifications. The core problem solved in this step is [order].

The service of the system: from the point of view of function, we need to abstract the business logic into reusable and assembled services, so as to realize the rapid regeneration of business through the choreography of services. the purpose is to abstract the original inherent business functions into general business services and realize the rapid reuse of business logic; the core problem to be solved in this step is [reuse].

Service-oriented business: from the point of view of the enterprise, if we want to abstract the enterprise functions into reusable and assembled services, it is necessary to transform the original functional enterprise architecture into a service-oriented enterprise architecture. in order to further enhance the external service ability of the enterprise. "the first two steps are to solve the problems of system call and system function reuse from the technical level." In this step, a business unit is encapsulated into a service with a business driver. The core problem to be solved is [efficiency].

III. Analysis of MicroServices architecture

Micro-service architecture is very similar to SOA architecture, micro-service is only the sublimation of SOA, except that micro-service architecture emphasizes that "business needs thorough componentization and service". Originally, a single business system will be split into multiple mini-applications that can be developed, designed, deployed and run independently. These small applications interact and integrate with each other through service. Components represent a unit that can be replaced and upgraded independently, just like CPU, memory, graphics card, and hard disk in PC, which can be replaced and upgraded independently without affecting other units. If we build the components in the PC as services, then the PC only needs to maintain the motherboard (which can be understood as ESB) and some necessary external devices. CPU, memory, hard disk, etc., are all provided as components. For example, PC needs to call CPU to do computing processing. You only need to know the address of the component CPU.

At present, the popular Service Mesh open source software are Linkerd, Envoy and Istio, and recently Buoyant (the company of open source Linkerd) released the Kubernetes-based Service Mesh open source project Conduit.

With regard to the difference between micro-services and service grid, I understand that micro-services pay more attention to the ecology between services and focus on service governance, while service grid focuses more on the communication between services and better integration with DevOps.

Characteristics of Service Grid

1. The middle layer of communication between applications

two。 Lightweight network agent

3. Application program is not aware

4. Decouple application retry / timeout, monitoring, tracking, and service discovery

VI. The basic theory of distributed architecture

Before we talk about the theory of CAP and BASE, we need to understand the problem of distributed consistency. In fact, for services of different businesses, we have different requirements for data consistency, such as 12306, which requires strict consistency of data, and cannot sell tickets to users only to find that there are no seats left; another example is bank transfer. when we transfer money through the bank, we usually receive a prompt: the transfer application will arrive within 24 hours. In fact, what this scenario satisfies is that in the end, as long as the money is transferred successfully, and if the money is not remitted, it is guaranteed that the money will not be lost. Therefore, users have different requirements for data consistency when using different services.

On the problem of distributed consistency

A very important problem to be solved in distributed systems is data replication. In our daily development experience, it is believed that most developers have encountered this problem: in the scenario of database read-write separation, suppose client A changes a value V in the system from V1 to V2, but client B cannot read the latest value of V immediately, but it will take some time to read it. This is perfectly normal because the storage between database replications is delayed.

The so-called distributed consistency problem refers to the data inconsistencies that may occur between different data nodes and can not be solved by computer applications after the introduction of data replication mechanism in the distributed environment. To put it simply, data consistency means that when making changes to one copy of data, you must ensure that other replicas can also be updated, otherwise the data between different replicas will be inconsistent. So how to solve this problem? According to the normal way of thinking, we may think that since the problem is caused by the network delay, then we block the synchronization action, and user 2 must wait until the data synchronization is completed when querying. But this scheme can have a great impact on performance. If more or more data is synchronized, blocking operations may make the entire new system unavailable. So there is no way to find a solution that satisfies data consistency without affecting system performance, so a level of consistency is born:

Strong consistency: this level of consistency is most in line with user intuition, it requires the system to write what is written and read, and the user experience is good, but it often has a great impact on the performance of the system.

Weak consistency: this consistency level restricts the system to read and write values immediately after a successful write, and does not guarantee that the data will be consistent after how long it takes, but will try its best to ensure that the data can reach a consistent state after reaching a certain time level (such as second level).

Final consistency: the final consistency is actually a special case of weak consistency, and the system will ensure that the data will be consistent within a certain period of time. The reason why the final consistency is put forward separately is that it is a kind of consistency model highly respected in weak consistency, and it is also a common consistency model used in the data consistency of large-scale distributed systems.

CAP theory

It is a classical distributed system theory. CAP theory tells us that a distributed system can not meet the three basic requirements of consistency (C:Consistency), availability (A:Availability) and partition fault tolerance (P:Partition tolerance), but can only meet two of them at most. CAP theory is widely known in the Internet field, also known as "hat theory". It is a famous conjecture put forward by Professor Eric Brewer in the ACM seminar held in 2000: Consistency, Availability and Partition-tolerance can not be satisfied at the same time in distributed systems, and can only satisfy two at most!

Consistency: data on all nodes is kept synchronized at all times

Availability: each request can receive a response, regardless of success or failure

Partition fault tolerance: the system should continue to provide services, even if messages are lost within the system (a node partition). For example, the switch fails, the URL network is divided into several subnets, resulting in brain cracks, network delays or crashes on the server, causing some server to lose contact with other machines in the cluster.

Partition is the inherent characteristic that leads to the reliability problem of distributed system. In essence, the accurate description of CAP theory should not be to select two of the three characteristics, so we can only be forced to adapt, there is no choice. CAP is not a universal principle and guiding ideology, it is only suitable for atomic read-write NoSql scenarios, not for database systems.

BASE theory

We know from the previous analysis that CAP theory is not suitable for database transactions under the premise of distribution (on multiple instances of database fragmentation or sublibraries) (failures caused by updating some wrong data, no matter what highly available scheme is used, because the data has an irreparable error). In addition, although the XA transaction ensures the ACID (atomicity, consistency, isolation, persistence) characteristics of the database in the distributed system, it also brings some performance costs, which is difficult to accept for the e-commerce platform with high concurrency and response time requirements.

EBay tries a completely different approach, relaxing the ACID requirements for database transactions and proposing a new set of guidelines called BASE. BASE is called Basically Available,Soft-state,Eventually Consistent. The system is basically available, soft state, and data is ultimately consistent. Compared with CAP, it greatly reduces our requirements for the system.

Basically Available (basic available)

Indicates that instantaneous partial availability is allowed in the event of an unpredictable failure in a distributed system

For example, when we search for products on Taobao, normally we return the query results within 0.5s, but the query response time becomes 2s due to the back-end system failure.

For example, the database uses sharding mode, and 100W user data is divided into five database instances. If one instance is destroyed, the availability is still 80%, that is, 80% of users can log in, and the system is still available.

When e-commerce is booming, in order to cope with the surge in traffic, some users may be directed to downgraded pages, and the service layer may only provide downgraded services. This is the embodiment of the loss of partial usability.

Soft-state (soft state).

Indicates that there is an intermediate state in the data in the system, and the existence of this intermediate state will not affect the overall availability of the system, that is, the system allows a delay in the process of data synchronization between replicas of data from different nodes. For example, if the order status has a pending payment, a payment is successful, and the payment fails, then the payment is an intermediate state, which is after the payment is successful and before the status in the payment table is synchronized to the order status. There will be an inconsistency in the middle.

Eventually consistent (ultimate consistency of data)

It means that all copies of data can finally reach a consistent state after a period of synchronization, so the essence of ultimate consistency is to ensure that the data is finally consistent, and there is no need to ensure the strong consistency of system data in real time.

The core idea of BASE theory is that even if strong consistency can not be achieved, each application can adopt appropriate ways to make the system achieve final consistency according to its own business characteristics.

7. High availability design under distributed architecture

Avoid a single point of failure

1. Load balancing technology (failover/ location / hardware load / software load / decentralized software load (gossip (redis- cluster)

two。 Hot standby (linux HA)

3. Multiple computer rooms (disaster preparedness in the same city, disaster preparedness in different places)

High availability of applications

1. Fault monitoring (system monitoring (cpu, memory) / link monitoring / log monitoring) automatic early warning

two。 Fault-tolerant design of applications, (service degradation, current limitation) self-protection capability

3. Amount of data (data fragmentation, read-write separation)

Scalable Design under distributed Architecture

1. Vertical expansion

two。 Improve hardware capability

3. Horizontal telescopic

4. Add servers

CDN that accelerates static content access

The full name of CDN is Content Delivery Network, and the Chinese definition is content delivery network. The function of CDN is to distribute the content that the user needs to the place closest to the user for response, so that the user can get the content they need quickly. CDN is essentially a network caching technology, which can put some relatively stable resources close to the end user. On the one hand, it can save the bandwidth consumption of the entire WAN, on the other hand, it can also improve the access speed of users and improve the user experience. In real systems, we usually put static files (pictures, scripts, static pages, etc.) into CDN.

1. When the user visits the content URL on the page of the website, after the local DNS system parses, the DNS system will eventually hand over the resolution right of the domain name to the CDN dedicated DNS server pointed to by CNAME.

2.CDN 's DNS server returns the global load balancing device IP address of CDN to the user.

3. The user initiates a content URL access request to the global load balancer device of CDN.

The 4.CDN global load balancer device selects a regional load balancer device in the user's region based on the user's IP address and the content URL requested by the user, and tells the user to initiate a request to the device.

5. The regional load balancing device will provide services for users to choose a suitable cache server.

The basis for selection includes: judging which server is closest to the user according to the user's IP address. According to the name of the content carried in the URL requested by the user, determine which server has the content that the user needs; query the current load of each server, and determine which server has the service capacity. After a comprehensive analysis based on the above conditions, the regional load balancer will return the IP address of a cache server to the global load balancer.

6. The local load balancer returns the IP address of the server to the user.

The user initiates a request to the cache server, and the cache server responds to the user's request and returns the content needed by the user to the user terminal. If there is no content that the user wants on this cache server, and the zone balancing device still assigns it to the user, then the server requests content from its higher-level cache server until it is traced back to the source server that contains the content and the content is pulled locally.

Under what circumstances do I use CDN?

The most suitable content is those that do not change often, such as images, js files, CSS files, image files including background images used in CSS files in the program template, and those images that are part of the content of the site, and so on.

Grayscale release

Even if our application has been tested by the testing department, it is still difficult to fully cover the usage scenarios of users. in order to be foolproof, we usually release new applications in grayscale, that is, new applications will be released in batches, gradually expanding the proportion of new applications in the whole and the cluster until the final completion. Grayscale publishing means that there is no perception of the user experience for new applications.

The role of the grayscale publishing system is that, according to its own configuration, the user's traffic can be directed to the newly launched system to quickly verify new features, and if something goes wrong, it can also be rolled back and released immediately. To put it simply, it is a set of AMagar B Test system.

VIII. Summary

Through this article, we analyze the mainstream SOA architecture, micro-service architecture and service grid architecture, and then know several basic theories of distributed architecture, and then analyze how to design a highly available distributed architecture. Is it very good? next article, we will analyze how to develop our micro-service system based on DDD through an example. Are you looking forward to it? Waiting for you in the comment area.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.