Writing in the front

Readers who have a certain understanding of Glacier know that glacier has gone through the whole research and development process from zero to hundreds of millions of users of the power supplier system, and later derived from the e-commerce system (mall + Secakilling) and real-time and accurate product recommendation platform based on massive data. Part of the core knowledge has been summarized in my two books — Massive data Processing and Big Data Technology Combat and MySQL Technology: Development, Optimization and Operation And Maintenance Combat. With the continuous development of the e-commerce system business, we need to constantly iterate and upgrade the system, during which Dubbo contributed a lot.

There are two well-known technology stacks in the microservices space: SpringCloud/SpringCloud Alibaba (currently SpringCloud Alibaba is poised to overtake SpringCloud) and Dubbo. Dubbo, as a RPC framework for service governance, is almost a must-ask technology in the interview process of large factories. Therefore, I plan to write an in-depth analysis of Dubbo series of special topics, to uncover the mystery of Dubbo, so that more partners can thoroughly master Dubbo.

This is the beginning of the Dubbo source code series!!

Note: Write SpringCloud Alibaba series after Dubbo.

The article has been included:

Github.com/sunshinelyz…

Gitee.com/binghe001/t…

Dubbo’s core competencies

Overall, Apache Dubbo is a high-performance, lightweight, open source RPC framework that provides six core capabilities:

  • High-performance RPC calls for interface proxy.
  • Intelligent fault tolerance and load balancing.
  • Services are automatically registered and discovered.
  • Highly scalable.
  • Run-time traffic scheduling.
  • Visual service governance and o&M.

For details, please refer to Dubbo’s official documentation.

Why learn Dubbo

Why deep learning Dubbo? It must be to solve some kind of business scenario. Next, let’s talk about why we learn Dubbo. But before we get to why we’re learning Dubbo, let’s look at how our systems have changed architecturally as our business has evolved.

Single application architecture

In the early stage of enterprise development, the website traffic of general companies is relatively small, and only one application is needed. All the functional codes are packaged into a service and deployed to the server to support the company’s business. This also reduces development, deployment, and maintenance costs.

For example, we are familiar with the e-commerce system, which involves mainly: user management, commodity management, order management, payment management, inventory management, logistics management and other modules, we will write all modules in a Web project at the beginning, and then unified deployment to a Web server.

This architectural feature has its advantages:

  • Simple architecture, low cost of project development and maintenance.
  • All project modules are deployed together, which is easy to maintain for small projects.

However, its disadvantages are also quite obvious:

  • All modules are coupled together, although easy to maintain for small projects. However, for large projects, it is not easy to develop and maintain.
  • The modules of the project were so coupled that if one module failed, the whole project would become unusable.
  • Performance cannot be improved for a specific module.
  • Unable to scale the project horizontally.

It is because of the shortcomings of single application architecture that it gradually evolves into vertical application architecture. Next, let’s look at vertical application architectures.

Vertical application Architecture

As enterprise services grow, single applications on a node cannot support service development. Therefore, enterprises deploy multiple applications on different servers. However, at this point, you will find that not all modules will have a large number of visits. If you want to optimize and improve performance for certain modules in a project, you can’t do that for a single application. Hence, the vertical application architecture was born.

Vertical application architecture is to split the original application of a project into several applications that do not want to work with each other to improve the overall performance of the system.

Here, we also take the e-commerce system as an example. Under the vertical application architecture, we can divide the whole e-commerce project into e-commerce transaction system, background management system, CMS management system and so on.

Once we split the monolithic application architecture into vertical applications, once the volume of access increases, we can only add server nodes for the high-traffic business, rather than for the entire project.

Advantages of this architecture:

  • The system has been split, according to the access of different systems, targeted optimization.
  • Horizontal extension of applications can be achieved.
  • Each system can share the overall access traffic to solve the concurrency problem.
  • Failure of one system does not apply to the operation of other systems, improving the overall fault tolerance rate.

Disadvantages of this architecture:

  • After splitting, each system is relatively independent and cannot call each other.
  • Each system inevitably has overlapping business, there will be repeated development of business, later maintenance is difficult.

Distributed architecture

As we evolve the system into a vertical application architecture, as more and more vertical applications are applied, more and more business code is written repeatedly. At this point, we need to abstract out the repeated code to form a unified service for other systems or business modules to call. At this point, the system evolves into a distributed architecture.

In a distributed architecture, we split the system into a service layer and a presentation layer. The service layer encapsulates the specific business logic that is invoked by the presentation layer, which handles the interaction with the page.

Advantages of this architecture:

  • The repetitive business code is abstracted to form a common access service, which improves code reusability.
  • You can optimize system and service performance to improve overall access performance.

Disadvantages of this architecture:

The coupling degree between systems becomes high, and the call relationship becomes complex and difficult to maintain.

SOA architecture

In distributed architecture, as more and more services are deployed, there will be more and more duplicate code, and there will be serious problems such as capacity evaluation and waste of small service resources. At this point, we need to add a unified scheduling center to manage the cluster in real time. At this point, the system evolves into an SOA (service-oriented) architecture.

Advantages of this architecture:

The use of registries solves the automatic registration and discovery of service dependencies and invocation relationships between services.

Disadvantages of this architecture:

  • There are dependencies between services, and if a service fails, it may cause an avalanche of services. (For more information about penetration, breakdown, and avalanche, please refer to my previous article: ).
  • The dependency and invocation relationship between services is complex, so it is difficult to test and deploy.

Microservices Architecture

As the business grew, we expanded on the SOA architecture, splitting it completely into a microservices architecture. Under the microservices architecture, we split a large project into small, independently deployable microservices, each with its own database.

Advantages of this architecture:

  • Services are completely separated, and each service is packaged, deployed, and upgraded independently.
  • Each microservice is responsible for a relatively clear business, facilitating later expansion and maintenance.
  • Microservices can communicate with each other using REST and RPC protocols.

Disadvantages of this architecture:

  • Development costs are high.
  • The fault tolerance of each service is involved.
  • It involves data consistency.
  • It involves distributed transactions (see my ongoing distributed transactions section).

Why learn Dubbo?

(1) Dubbo is needed to solve problems during system upgrade.

In the process of system architecture upgrade and micro-service implementation, we need to solve many problems, such as:

  • After splitting a project into services, how efficiently can services communicate with each other?
  • How can service invocation be load balanced and highly available?
  • How to limit the flow of service invocation? And how to quickly sense the dependent service outage?
  • How are service boundaries defined?
  • When more and more services exist in the system, how to carry out service governance and so on.

These are all problems that we can solve with Dubbo.

(2) Internet giants need to master Dubbo technology.

It is clear that many of the Internet’s biggest companies need a deep grasp of Dubbo. The depth of mastery here is not just a simple level of use, but a certain understanding of the core principles and source code of Dubbo. In other words, you need to be familiar with Dubbo’s core principles and source code, and be able to use them to analyze problems and perform performance tuning in high-concurrency, high-traffic scenarios.

Therefore, if you want to enter the Internet big factory, it is best to master Dubbo’s core principles and source code.

Usage scenarios for Dubbo

Dubbo has its place in distributed architecture, SOA architecture and microservices architecture. Some people may say: we use SpringCloud stack in our system, so we don’t need to use Dubbo. There is no conflict between SpringCloud and Dubbo, or even a combination of the two. For example, in the projects I have worked on, some independent modules use Dubbo as the RPC framework, while others use SpringCloud. The two are not in conflict, but can be mutually reinforcing.

In general, Dubbo can be used in the following scenarios:

RPC distributed service

As the website grows larger, it is inevitable to split applications for servitization to improve development efficiency, tune performance, and save key competitive resources.

For example, in order to adapt to changing market demands and facilitate data interaction between multiple vertical applications, we extract common businesses as independent modules to provide services for other applications, and the system gradually relies on abstraction and RPC remote service invocation.

Configuration management

As there are more and more services, the URL information of the service explodes, configuration management becomes very difficult, and the single point of pressure on the F5 hardware load balancer increases.

Service dependencies

As the dependencies between services become so complex that it is not even clear which application should be launched before which, the architect cannot fully describe the application’s architectural relationships.

Service capacity

Then, as more and more services are invoked, the capacity of the service is exposed. How much machine support does the service require? When should you add machines? And so on…

Dubbo summary

To summarize, in official terms: Apache Dubbo is a high-performance, lightweight, open source Java services framework that provides six core capabilities: High-performance RPC calls for interface proxy, intelligent fault tolerance and load balancing, automatic service registration and discovery, high scalability, run-time traffic scheduling, visual service governance and operations.

Dubbo’s six core capabilities enable us to better provide RPC and service governance capabilities for rapid iterations of microservices projects. If you want to get into a big factory, you better master Dubbo.

Ok, that’s all for today, I’m Glacier, if you have any questions, you can leave a comment below, you can also add my wechat: sun_shine_LYz, exchange technology together, advance together, together awesome ~~