Distributed System Architecture brief

table of Contents:

First, what is a distributed system?

Second, why go distributed system architecture?

Third, the system how to split?

Fourth, bring distributed after the technical challenges?

First, what is a distributed system?

Before talking about distributed system architecture, let's look at what is a distributed system?

Assuming that the original we have a system, the amount of over 30 million lines of code. 20 is now split into small systems, each small system over 10,000 lines of code.

Between the original code is directly based on the Spring Framework walk JVM memory calls, now open to the 20 small systems deployed on different machines, then engage in a rpc call based distributed service framework (such as dubbo), interfaces and interfaces between the request and the response to the communication over the network.

The distributed system is very important feature is the room service to make calls across the network, we look at the following chart:

In addition, a distributed system can probably be divided into two categories.

1. The bottom of the distributed system.

For example hadoop hdfs (distributed storage system), spark (distributed computing system), storm (distributed stream computing systems), elasticsearch (distributed search system), kafka (distributed publish-subscribe messaging system) and so on.

2. Distributed Business Systems

Distributed service system, the original chunk with a java development system, to split into a plurality of subsystems, each call between a plurality of subsystems forming a large overall system.

For example, suppose that you would do a OA system, which contains the permission module, staff module, leave the module, financial module, a project, which contains a bunch of modules, will be to call each other between the module and the module, 1 machine deployment.

Now if you put him to open the system, authority system, employee system, leave system, financial system, 4 systems, four projects were deployed on four machines.

Then came a request to complete the request, the system to call staff permission system, leave the system call, call the financial systems, four systems were completed part of things.

Finally, four systems have finished the job, then, to think that this request has been completed. This is called a distributed business systems.

Again, we come one picture, feel the above process:

Second, why go distributed system architecture?

Some students may want to ask, I have a server running properly, all systems a project all get much better. Why we must engage in any distributed system architecture, calling each other to go remote, it seems to have added a lot of work?

Here I am with a company I once worked at the tragic experience, for example, to talk about this issue.

Many years ago, at the time did not take the distributed architecture, the company's various business lines are perpendicular to me to be the " chimney " project.

With the rapid development of the Internet, the company's business also continues to develop, registered users increased functionality of web applications, have been expanding, particularly increased access channel development of mobile Internet, APP, micro-channel, self-service terminals, etc., each new kinds of business, the continuous influx of new demands, the system encountered a variety of problems.

The first is the project uncontrolled become bloated, increasing system complexity, large hundreds of thousands of lines of code, dozens of developers, service layer, dao layer is copy the code a lot of use, often merge various codes to deal with conflict very time-consuming.

I often change my code, others call my interfaces, leading to his code is also a problem, need to re-test, trouble death.

Then each release systems are hundreds of thousands of lines of code released together, together everyone was on tenterhooks ready on-line, on-line hundreds of thousands of lines of code, every time on the line have to do a lot of checks, a lot of problems to handle exceptions, everyone high tension, are made almost collapsed.

And if I now have a new business, it intends to upgrade its dependencies, such as upgrading to the latest version of the spring, it is not enough, as this may lead to other people's code error, not indiscriminate change technology. And every time you start a web project will take several minutes, which local IDE debug code once very painful.

Secondly, with the increase in user traffic, the system load pressure becomes large, becoming overwhelmed by the effect of increasing the number of instances, additional hardware can bring expansion has little, fault-prone and inefficient. The system is also increasingly difficult to guarantee the quality of the test cycle is getting longer, unable to meet the needs of business development of the company.

These are the company previously worked at some of the "painful" events of the past, generally speaking, the problem is mainly reflected in the following areas:

Application code coupling severe, difficult extensions
The new requirements development cycle interact with long, heavy workload test
New entrants to the development of co-workers take a long time to become familiar with the system
Upgrade and maintenance is also very difficult (to change any of that local governments should upgrade the entire system)
System performance difficult, low availability and unstable.

Well, since we have to deeply understand the pain of the coupling system, now take a look at the benefits the system brings the split:

First, the system splits the future, the whole world will feel refreshing.

The system hundreds of thousands of lines of code, assuming split into 20 service, service on the average 1-3 million lines of code, each service deployed on a separate machine. 20 projects, 20 will use git repository of code, 20 developers, that everyone maintains its own service on it.

Because it is its own separate code, it does not matter with others. No code violations, and cool!
Every time you test my own code on it, cool!
Every time you release a little of my own service on it, cool!
Technically thinking about how to upgrade on how to upgrade and maintain the same interface definition, the contents of the input and output unchanged on it, cool!

To sum up a word, after the split of distributed systems, can greatly enhance the efficiency of the development team of complex large-scale systems.

Third, the system how to split?

In general, the system is split, you first need to be familiar with the whole system. Can go many rounds split the idea is first split before each split large coarse-grained modules open.

For example, a system can be split into electricity supplier ordering systems, merchandise systems, store systems, membership systems, marketing systems, payment systems and so on.

Each system may later they become more and more complex, such as an order system can be further split up shopping cart system, inventory system, the price system.

Generally speaking is based on the idea and the practical lessons learned domain-driven design, as well as some general reference to industry practice, we come to discuss the split, and gradually optimized, multi-round split, small run, and ultimately achieve a relatively good state .

Fourth, bring distributed after the technical challenges?

The first is the selection of a distributed service framework, in terms of domestic mainstream or dubbo and spring cloud.

Let's think about using the service framework is mainly used to solve the problem? If you do not dubbo whether or spring cloud distributed architecture can do it?

Not dubbo or spring cloud services framework is of course possible, but this requires a lot of things to handle their own.

For example, each subsystem interface calls go restful, it is http call, when an object such as a transfer in the past, we must own mess a json, then the first call after an unsuccessful retry how to do?

In addition, in general, are clustered deployment, there are multiple instances of the target system, then we would also like to write a load balancing algorithm, how to call each randomly selected from a plurality of target machines?

Also, if the target system expansion deployed a new instance of a server failure or an offline example, how to dynamically allow the caller to perceive it? Many such questions, if not, then the service framework, so messing around himself, will encounter a variety of problems.

The above process, with a view of presenting it to you:

If you chose one distributed service framework, we need to master the use of depth of the underlying principles of the framework, such as dubbo need to carry out some problems to understand the following:

dubbo works?
dubbo support serialization protocol?
dubbo load balancing and high availability strategy? Dynamic proxy policy?
dubbo of SPI thinking?
How dubbo be based on service management, service degradation, failure retry timeout and retries?
How Idempotence dubbo service interface design (such as repeated charge can not, repeat can not generate orders, you can not create a duplicate card number)?
How sequential dubbo service interface request guarantees?
How to design your own rpc framework of a similar dubbo?

Use spring cloud, too, such as eureka works? Declarative principle feign call? And so on various underlying principle to get to know.

There are other common after walking a distributed architecture to solve the technical problems:

1. Distributed session
2. Distributed Lock
3. Distributed Transaction
4. Distributed Search
5. Distributed Cache
6. Distributed message queue
7. Uniform distribution center
8. Distributed storage, database sub-library sub-table
9. Current limiting, fuse, demotion and so on.

Reproduced in: https: //www.cnblogs.com/technologykai/articles/11018296.html