A paragraph from the official website

1. The background

With the development of the Internet, the scale of website applications keeps expanding, and the conventional vertical application architecture can no longer cope with it. The distributed service architecture and mobile computing architecture are imperative, and a governance system is urgently needed to ensure the orderly evolution of the architecture.

 

 

Single application Architecture

When site traffic is low, only one application is needed to deploy all functions together to reduce deployment nodes and costs. At this point, data access frameworks (ORM) that simplify the work of adding, deleting, modifying and reviewing are key.

Vertical application Architecture

When the volume of traffic gradually increases, the acceleration caused by the increase of a single application machine is getting smaller and smaller. The application is divided into several unrelated applications to improve efficiency. At this point, a Web framework (MVC) for accelerating front-end page development is key.

Distributed Service Architecture

With the increasing number of vertical applications, the interaction between applications is inevitable. Core businesses are extracted as independent services, gradually forming a stable service center, so that front-end applications can respond to changing market demands more quickly. At this point, the distributed Services framework (RPC) for business reuse and integration is key.

Mobile Computing Architecture

As the number of services increases, problems such as capacity evaluation and waste of small service resources gradually emerge. In this case, a scheduling center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization. At this point, a resource scheduling and Governance center (SOA) for improving machine utilization is key.

 

Why did I post this paragraph, which describes the evolution of the Internet architecture, the key elements and the meaning of Dubbo’s existence, is simple but not simple. I will not elaborate on dubbo here

 

2, requirements,

　　

 

Before large-scale servitization, applications might simply expose and reference remote services through tools such as RMI or Hessian, invoke services by configuring service URLS, and load balance through hardware such as F5.

As there are more and more services, service URL configuration management becomes very difficult and the single point of pressure on the F5 hardware load balancer increases. In this case, a service registry is needed to dynamically register and discover services and make the location of services transparent. In addition, by obtaining the address list of the service provider from the consumer, the software load balancing and Failover can be implemented to reduce the dependence on the F5 hardware load balancer and reduce part of the cost.

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. In this case, dependency diagrams between applications need to be drawn automatically to help the architect clean up the relationships.

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? In order to solve these problems, the first step is to calculate the service’s current daily call usage and response time as a reference index for capacity planning. Secondly, it is necessary to adjust the weight dynamically. On the line, the weight of a machine has been increased, and the change of response time is recorded in the process of increasing, until the response time reaches the threshold, the page view is recorded at this time, and then the total capacity is reversed by the page view multiplied by the number of machines.

These are the basic requirements of Dubbo.

 

Dubbo has a unique monitor module, which can be used to monitor and analyze data

3, architecture,

This diagram, without further elaboration, describes a service registration and discovery scenario:

 

  1. The service container is responsible for starting, loading, and running the service provider.
  2. At startup, service providers register their services with the registry.
  3. At startup, service consumers subscribe to the registry for the services they need.
  4. The registry returns a list of service provider addresses to the consumer, and if there are changes, the registry pushes the change data to the consumer based on the long connection.
  5. The service consumer, from the provider address list, selects one provider to call based on the soft load balancing algorithm. If the call fails, selects another one to call.
  6. Service consumers and providers accumulate calls and call times in memory and regularly send statistics to the monitoring center every minute.

 

 

2. Use Spring-boot to quickly build dubbo

1. Project structure diagram

 

 

2. Write code for the service-API layer

IStudentService:

package com.hzgj.lyrk.dubbo.api;

import com.hzgj.lyrk.dubbo.dto.StudentDTO;

public interface IStudentService {

    StudentDTO getStudentById(Integer id);
}Copy the code

StudentDTO: Note that the serializable interface must be implemented

package com.hzgj.lyrk.dubbo.dto;

import lombok.Data;

import java.io.Serializable;

@Data
public class StudentDTO implements Serializable {

    private Integer id;

    private String name;


}Copy the code

 

3. Write the student-server module

3.1 Add a Gradle dependency first:

dependencies { // testCompile group: 'junit', name: 'junit', version: '4.12' compile 'com. Alibaba. The boot: dubbo - spring - the boot - starter: 0.1.0 from' / / https://mvnrepository.com/artifact/com.101tec/zkclient compile group: 'com.101tec', name: 'zkclient', version: '0.10' compile project (" : service - API ")}Copy the code

3.2 StudentServer:

package com.hzgj.lyrk.dubbo.student.server; import com.alibaba.dubbo.config.annotation.Service; import com.hzgj.lyrk.dubbo.api.IStudentService; import com.hzgj.lyrk.dubbo.dto.StudentDTO; @Service public class StudentService implements IStudentService { @Override public StudentDTO getStudentById(Integer id)  { StudentDTO studentDTO = new StudentDTO(); studentDTO.setId(id); Studentdto. setName(" student id = "+ id + "); return studentDTO; }}Copy the code

Note here @ Service to use com. Alibaba. Dubbo. Config. The annotation. Service

3.3 Writing startup classes:

package com.hzgj.lyrk.dubbo.student; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class StudentApplication { public static void main(String[] args) { SpringApplication.run(StudentApplication.class, args); }}Copy the code

3.4 application. Yml file

server: port: 8100 spring: application: name: student-server dubbo: application: name: student-server id: Student - server version: 1.0 scan: base - packages: com. HZGJ. Lyrk. Dubbo. Student. Server registry: address: zookeeper://localhost:2181Copy the code

In this we note the following points:

1) First define spring.application.name

2) Dubbo integration configuration usually starts with dubbo. XXXX

3) Dubo.scan. Base-packages: mainly for scanning dubbo annotation packages

4) Dubo.registry. Address: is the address of the specified registry. Here we use ZooKeeper as the registry

3.5 When zooKeeper is successfully started, the following nodes can be found using zkCli:

　　

The structure is: /dubbo/ the full class name of the interface/node

 

4. Write the consumer side: project-portal

4.1 Adding Gradle dependencies

Dependencies {compile 'com.alibaba.boot: dubo-spring-boot-starter :0.1.0' // https://mvnrepository.com/artifact/com.101tec/zkclient compile group: 'com.101tec', name: 'zkclient', version: '0.10' compile project (" : service - API ")}Copy the code

4.2 write a controller

package com.hzgj.lyrk.dubbo.portal.controller; import com.alibaba.dubbo.config.annotation.Reference; import com.hzgj.lyrk.dubbo.api.IStudentService; import com.hzgj.lyrk.dubbo.dto.StudentDTO; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController; @RestController public class StudentController { @Reference private IStudentService studentService; @GetMapping("/student/id/{stuId}") public StudentDTO getStudent(@PathVariable Integer stuId) { return studentService.getStudentById(stuId); }}Copy the code

Note: the use of the @reference annotation

4.3 Writing startup classes

package com.hzgj.lyrk.dubbo.portal; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class PortalApplication { public static void main(String[] args) { SpringApplication.run(PortalApplication.class, args); }}Copy the code

4.4 write application. Yml

spring: application: name: project-portal server: port: 8101 dubbo: registry: address: Zookeeper: / / localhost: 2181 application: version: 1.0 id: project - portal name: project - portalCopy the code

Test it out:

 

 

Dubbo and SpringCloud

In fact, both of these are typical technical solutions for micro services at the moment, which can be described as a bright moment. However, dubbo is more popular in China. The reason is actually very simple:

1. Dubbo official documents are detailed and in Chinese, and the operation principle and technical solution are described thoroughly

2. Many domestic architects come from Ali, which plays an indelible role in promoting Dubbo

3. Due to dubbo’s early existence, it is also open source. It was a big hit at the time, and companies rushed to use it. Even now, no one is willing to reinvent the original project with new technology.

 

In contrast, dubbo may not be as widely used as SpringCloud in foreign communities. The reason is clear: As a company, Dubbo was born of Alibaba and is a commercial company. I think the framework of Alibaba must be satisfied with its own business and interests first. Spring Cloud comes from the Spring product family, and the company itself is to simplify the development mode of enterprises, to serve various large enterprises. So they have a different starting point, and I think that’s a necessary factor.

But there are a few points I would like to highlight here:

1. In terms of functions accomplished: Dubbo is actually part of the SpringCloud component, which is equivalent to Eureka + Hystrix+ Ribbon + Feign in Netflix. However, the integration of SpringCloud, such as: link tracking, distributed configuration, gateway routing, etc., has not been found in Dubbo, or I may not have found it. So to use these features in Dubbo, we have to rely on third party implementations.

2. Dubbo implements remote invocation based on RPC, and calls between springCloud services are still called through HTTP, which is weaker than Dubbo in terms of performance. After all, Dubbo is tested by Alibaba’s huge business product family and concurrency, but this does not mean that SpringCloud’s performance will be poor

3. The common dubbo technology usage scheme is still based on Spring, so I would like to give spring credit for the hero behind the scenes

4. Spring-cloud is like a branded computer, which is very easy to use, so it is definitely a boon for small and medium sized companies (without too much effort and cost). Dubbo is like an assembly machine, where we assemble our own microservices solution from the complete documentation of the existing implementation.