From 0 to 10,000 words, we will explain the evolution from single architecture to distributed architecture intimately (Part 1)

In fact, life is not only about the hustle and bustle, but also poetry and distance. Therefore, today we will review the history and take a look at the evolution of the system architecture; grasp the present, learn the most popular technical architecture; look forward to the future, and strive to become an excellent Java engineer.

Hello everyone, let me introduce myself to you first.
I am the code on the code. You can call me brother code.
I am also the most ordinary student who graduated from an ordinary undergraduate course. I believe that most programmers or those who want to work in the programmer industry are ordinary families. My child, so I also rely on my own efforts, from graduating and joining a traditional company, to changing jobs without fail, and now working in a giant company in the Internet industry, I hope that through my sharing, I can help everyone.
Follow my column to learn , which can save you a lot of training costs or time to find information online, save most of your time costs, and make you faster to become an interview harvester and the best employee of the year

I have prepared 16 technical columns for everyone to lead you to learn together

"Billion-level traffic distributed system combat"

"Battery Factory Interview Must-Ask Series"

"Technical Talk"

"Zero Foundation takes you to learn java tutorial column"

"Take you to learn springCloud column"

"Take you to learn SpringCloud source code column"

"Take you to learn distributed system column"

"Take you to learn cloud native column"

"Take you to learn springboot source code"

"Take you to learn netty principles and practical column"

"Take you to learn Elasticsearch column"

"Take you to learn mysql column"

"Take you to learn JVM principle column"

"Take you to learn Redis principle column"

"Take you to learn java advanced column"

"Take you to learn big data column"

If there is any technology you want to learn, you can leave a message in the comment area and make progress together

Many fans responded that they want to learn distributed system architecture

From this article, the code brother will teach you to learn the application scenarios and solutions in the distributed architecture from scratch, and explain from both practical and theoretical aspects.

Remember to like , favorite, follow , and make progress together

If you have any questions, you can private message me, or leave a message in the comment area

0. Learning Objectives

• Understand the evolution of system architecture
• Understand the difference between RPC and Http
• Master the simple use of HttpClient
• Know what is SpringCloud
• Independently build Eureka registration center
• Independent configuration of Robbin load balancing

1. System Architecture Evolution

With the development of the Internet, the scale of website applications continues to expand. The surge in demand has brought technical pressure. The system architecture is also constantly evolving, upgrading, and iterating. From a single application, to vertical splitting, to distributed services, to SOA, and the current hot microservice architecture, as well as the surging Service Mesh led by Google. Should we take the ship of microservices to the distance, or should we just settle for a corner?

1.1. Centralized Architecture

When the website traffic is small, only one application is needed, and all functions are deployed together to reduce deployment nodes and costs. At this time, the data access framework (ORM) used to simplify the workload of adding, deleting, modifying and checking is the key to affecting project development.

Existing problems:

• Code coupling, difficult to develop and maintain
• Cannot be optimized for different modules
• Cannot scale horizontally
• Low single-point fault tolerance and poor concurrency

1.2. Vertical split

When the number of visits gradually increases, a single application cannot meet the demand. At this time, in order to cope with higher concurrency and business requirements, we split the system according to business functions:

advantage:

• System splitting realizes traffic sharing and solves concurrency problems
• Can be optimized for different modules
• Convenient horizontal expansion, load balancing, and improved fault tolerance

shortcoming:

• The systems are independent of each other, and there will be a lot of repetitive development work, which affects the development efficiency

1.3. Distributed Services

When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed, so that front-end applications can respond more quickly to changing market demands. At this time, distributed invocation for improving business reuse and integration is the key.

advantage:

• The basic services are extracted, and the systems call each other, which improves code reuse and development efficiency

shortcoming:

• The degree of coupling between systems becomes high, and the calling relationship is complicated and difficult to maintain

1.4. Service Governance (SOA)

SOA: Service Oriented Architecture

When there are more and more services, problems such as capacity evaluation and waste of small service resources gradually emerge, it is necessary to add a dispatch center to manage the cluster capacity in real time based on the access pressure and improve the cluster utilization rate. At this point, a Resource Scheduling and Governance Center (SOA) for improving machine utilization is key

What went wrong before?

• More and more services, need to manage the address of each service
• The calling relationship is complicated and it is difficult to sort out the dependencies
• There are too many services, the service status is difficult to manage, and it cannot be dynamically managed according to the service situation

What does service governance do?

• Service registration center, to realize automatic registration and discovery of services, no need to manually record service addresses
• Automatic subscription of services, automatic push of service lists, transparent service calls, no need to care about dependencies
• Dynamic monitoring service status monitoring report, manual control of service status

shortcoming:

• There will be dependencies between services, and once a link goes wrong, it will have a greater impact
• The service relationship is complex, the operation and maintenance, testing and deployment are difficult, which is not in line with the DevOps idea

1.5. Microservices

The SOA mentioned earlier, the English translation is service-oriented. Microservices, which seem to be services, are all about splitting up the system. Therefore, it is very easy to confuse the two, but in fact there are some differences:

Features of Microservices:

• Single responsibility: Each service in the microservice corresponds to a unique business capability, achieving a single responsibility
• Micro: The service splitting granularity of microservices is very small, for example, a user management can be used as a service. Each service is small, but "complete with all the internal organs".
• Service-oriented: Service-oriented means that each service must expose the Rest-style service interface API. It doesn't care about the technical implementation of the service, it has nothing to do with the platform and language, and it does not limit what technology is used for implementation, as long as the interface of Rest is provided.
• Autonomy: Autonomy means that services are independent of each other and do not interfere with each other
  • Team independence: Each service is an independent development team, and the number cannot be too large.
  • Technology independence: because it is service-oriented, it provides Rest interface, and no one interferes with what technology to use
  • Front-end and back-end separation: The front-end and back-end are separated and developed to provide a unified Rest interface, and the back-end no longer needs to develop different interfaces for the PC and mobile segments.
  • Database separation: each service uses its own data source
  • The deployment is independent. Although there are calls between services, the restart of the service does not affect other services. Good for continuous integration and continuous delivery. Each service is an independent component, reusable, replaceable, reducing coupling, and easy to maintain

Microservice structure diagram:

2. Remote call method

Both microservices and SOA are faced with remote calls between services. So what are the remote calling methods between services?

Common remote call methods are as follows:

• RPC: Remote Produce Call remote procedure call, similar to RMI. Custom data format, based on native TCP communication, fast and efficient. The early webservice and the now popular dubbo are typical of RPC

• Http: http is actually a network transmission protocol, based on TCP, which specifies the format of data transmission. At present, the communication between the client browser and the server basically adopts the Http protocol. It can also be used to make remote service calls. The disadvantage is that the message encapsulation is bloated.

  Now the popular Rest style can be implemented through the http protocol.

2.1. Understanding RPC

RPC, or Remote Procedure Call, is a computer communication protocol. The protocol allows a program running on one computer to call a subroutine on another computer without the programmer having to additionally program this interaction. To put it simply, computer A provides a service, and computer B can call the service of computer A just like calling a local service.

Through the above concepts, we can know that implementing RPC mainly accomplishes two things:

• Implement remote calls to other computers' services
  • To achieve a remote call, it must be to transmit data over the network. Program A provides services, program B passes the request parameters to A through the network, and A gets the result after local execution, and then returns the result to program B. There are two things to pay attention to here:
    • 1) What kind of network communication protocol is used?
      • The more popular RPC frameworks now use TCP as the underlying transport protocol
    • 2) What is the format of data transmission?
      • For two programs to communicate, the data transmission format must be agreed. Just like two people chatting, they must use the same language, otherwise they will not be able to communicate. Therefore, we must define the format of the request and response. In addition, data transmission in the network needs to be serialized, so it is also necessary to agree on a unified serialization method.
• Invoke a remote service as if it were a local service
  • If it is only a remote call, it is not considered RPC, because RPC emphasizes procedure calls, and the calling process should be transparent to users. Users should not care about the details of the call, and can call remote services just like calling local services. So RPC must encapsulate the calling process

RPC call flow chart:

If you want to know the detailed RPC implementation, I recommend an article to you: Do-it- yourself RPC

2.2. Know Http

Http protocol: Hypertext Transfer Protocol, is an application layer protocol. It specifies the request format, response format, resource location and operation mode of network transmission. However, there is no regulation on what network transmission protocol is used at the bottom layer, but now the TCP protocol is used as the bottom layer transmission protocol. At this point, you may think that the remote calls of Http and RPC are very similar. They both carry out network communication according to a certain prescribed data format, with requests and responses. Yes, at this point, the two are very similar, but there are some subtle differences.

• RPC does not specify a data transmission format. This format can be arbitrarily specified. Different RPC protocols have different data formats.
• Http also defines the resource location path, which is not required in RPC
• The most important point: RPC needs to be able to call remote services like calling local services, that is, encapsulating the calling process at the API level. The Http protocol does not have such requirements, so the details of requests and responses need to be implemented by ourselves.
  • Advantages: The RPC method is more transparent and more convenient for users. The Http method is more flexible, there is no specified API and language, cross-language and cross-platform
  • Disadvantages: The RPC method needs to be encapsulated at the API level, which limits the language environment for development.

For example, when we access a website through a browser, it is through the Http protocol. It's just that the browser encapsulates the request, initiates the request, receives the response, and parses the response for us. If it is not through the browser, then these things need to be done by yourself.

2.3. How to choose?

Since both methods can implement remote calls, how should we choose?

• In terms of speed, RPC is faster than http. Although the bottom layer is TCP, the information of the http protocol is often bloated, but it can be compressed by gzip.
• In terms of difficulty, RPC is more complicated to implement, while http is relatively simple.
• In terms of flexibility, http is better because it does not care about implementation details, cross-platform and cross-language.

So both have different usage scenarios:

• If the requirements for efficiency are higher, and the development process uses a unified technology stack, then using RPC is still good.
• If you need to be more flexible, cross-language, cross-platform, obviously http is more suitable

So how do we choose?

Microservices emphasize independence, autonomy, and flexibility. The RPC method has many restrictions, so in the microservice framework, Http-based Rest-style services are generally used.