This is a call diagram for Dubbo

The call relationship is described as follows:

1) The service container starts, loads, and runs the service provider; 2) Service providers register their services with the registry at startup; 3) Service consumers subscribe to the registry for the services they need at startup; 4) The registry returns the service provider address list to the consumer. If there is any change, the registry will push the change to the consumer based on the long connection; 5) The service consumer selects one service provider from the address list based on the soft load balancing algorithm to call, and selects another one if the call fails; 6) Service consumers and service providers accumulate call times and call time in memory, and regularly send statistical data to the monitoring center once a minute.Copy the code

Node Role description

node The role that
Container Service run container
Provider The service provider that exposes the service
Consumer The service consumer that invokes the remote service
Registry A registry for service registration and discovery
Monitor Statistics service calls here and call time monitoring center

Dubbo server registration and discovery process?

  • The Provider binds the specified port and starts the service.
  • The provider connects to the registry and sends the local IP, port, application information, and providing service information to the registry store.
  • Consumer, connects to the registry and sends application information and requested service information to the registry.
  • The registry matches a list of providers based on the service information requested by the Consumer and sends it to the Consumer application cache.
  • A Consumer invokes a remote call based on one of the cached Consumer lists.
  • Provider status changes are notified to the registry in real time and pushed by the registry to consumers in real time.




One. So why dubbo?

2.1 Why service

Technology is born for the business, architecture is born for the business. Along with the development of the business, the growth of the users, system, called dependencies also becomes complex, in order to make sure the system high availability, high concurrency requirements and architecture of the system is also from monomer time slowly migrated to service the SOA era, according to the requirements of different services on system resources is different, we can be more reasonable configuration system resources, maximize the system resource utilization.

  1. Single application architecture When site traffic is low, only one application is required, deploying 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.
  2. Vertical application architecture When the number of visits gradually increases, the acceleration caused by the increase of a single application becomes smaller and smaller, and 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.
  3. Distributed service architecture As vertical applications become more and more, interactions between applications are inevitable. Core businesses are extracted as independent services to gradually form a stable service center, enabling front-end applications to respond to changing market demands more quickly. At this point, the distributed Services framework (RPC) for business reuse and integration is key.
  4. Mobile computing Architecture When more and more services are available, problems such as capacity assessment and waste of small service resources gradually emerge. At this time, a scheduling center should 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.

Platforms can meet business needs from an All in One environment as the business evolves (in the case of Java, a war package or two might solve the problem); To develop to need to split multiple applications, and adopt MVC way to separate the front and back end, accelerate the development efficiency; In the development of more and more services, some core or common services have to be split out to provide real-time flow monitoring computing, in fact, at this stage of development, if the service split is detailed enough, and run independently, at least it can be understood as SOA architecture.

2.2 Service challenges

In the era of service SOA, we are faced with many problems to be solved, such as increased system complexity, service dependency, service performance monitoring, full-link logging, disaster recovery, circuit breakers, and traffic limiting. So why do distributed services in the face of these problems? Because only by forging ahead in the future can we go higher and farther. But don’t get discouraged when you see these problems. Let’s take a step by step look at what the problems are and what we’re trying to accomplish, and they’ll take care of themselves.

According to the current situation of the team’s business system, first of all, we need to sort out the existing problems:

  1. Multiple call transmission modes: HTTP, WebService;
  2. Service invocation dependencies: manual logging, review code analysis;
  3. Service invocation performance monitoring: logging, manually viewing the time;
  4. Tight coupling between services and applications: Services fail and applications become unavailable;
  5. Service cluster load configuration: Nginx configuration, a single point of problem;

When choosing the technical framework, the technical framework should basically solve the existing problems above, and at the same time, we should also confirm our expectations and what the goal is to achieve:

  1. Supporting current business requirements is the most basic requirement;
  2. Service to avoid single point of problem, decentralization;
  3. High availability and concurrency of services decouple service dependencies;
  4. Service generalization, support heterogeneous system call service;
  5. Service dependency self-maintenance and visualization;
  6. Service performance monitoring self-statistics, visualization;
  7. The service provides features such as registration, discovery, health check, and load balancing.
  8. High attention from developers, quick to handle, simple and light weight, low invasion;

And the most important point, which is often a lot of technical personnel into the mistake, “for technology, do not use for the sake of use, with the most simple and appropriate technology to solve the problem is the right way”. An architecture serves the business. An architecture that can meet business requirements quickly and conveniently is a good architecture.




How to use Dubbo?

Dubbo uses the full Spring configuration mode to transparently access applications without any API intrusion. You only need to load the Dubbo configuration with Spring.

# 3.1 Install the registry

Zookeeper is officially recommended as the registry, so this test uses Zookeeper and places it on the VM whose IP address is 192.168.1.1.

Unzip and transfer directoriesTar -zxvf zookeeper-3.4.8.tar.gz -c /usr/cd/ usr mv zookeeper - 3.4.8 zookeeperSet the configuration file
cd /usr/zookeeper/conf
cp zoo_sample.cfg zoo.cfg

# start the zookeeper
/usr/zookeeper/bin/zkServer.sh start

View the running status of ZooKeeper. If Mode: Standalone is displayed, the standalone is running successfully
/usr/zookeeper/bin/zkServer.sh status
Copy the code

# 3.2 Service provider

Create a Maven project (a Web project called Dubo-Service).

Pom. XML configuration:

The web.xml configuration:

Interface:

Implementation class:

ApplicationContext – dubbo. XML configuration:

<dubbo:application name= <dubbo:application name="hello-demo"/> // Expose the service address with the broadcast registry <dubbo:registry address=Zookeeper: / / "192.168.1.1:2181"/> // Expose the service on port 20880 with dubbo <dubbo:protocol name="dubbo" port="20880"<dubbo:service interface= <dubbo:service interface="com.light.dubbo.service.HelloService" ref="helloService"/>
    
    <bean id="helloService" class="com.light.dubbo.service.impl.HelloServiceImpl"/>
Copy the code

# 3.3 Service consumers

Create a Maven project (a Web project called Dubo-Consumer).

Pom. XML configuration:

The web.xml configuration:

Copy the HelloService interface from the Dubo-Service project into the project (Dubo-Consumer).

Control layer:

@Controller
public class HelloController {

    @Autowired
    private HelloService helloService;
    
    @RequestMapping("hello")
    @ResponseBody
    public String hello(String name) {
        returnthis.helloService.sayHello(name); }}Copy the code

ApplicationContext – dubbo. XML configuration:

    <dubbo:application name="hello-demo"/>
       
    <dubbo:registry address=Zookeeper: / / 192.168.2.14: "2181"/>
    
    <dubbo:protocol name="dubbo" port="20880"/>
    
    <dubbo:reference interface="com.light.dubbo.service.HelloService"/>

Copy the code

For springmvc. XML configuration:


Start the project for the service provider (8080) and then the project for the service consumer (8081). Open a browser to http://localhost:8081/hello? Name = Jack, the result is as follows:


Dubbo other points

What registries does Dubbo have?

  • Zookeeper registry: Based on the distributed coordination system Zookeeper, the Watch mechanism of Zookeeper is used to change data.

Can publishers and subscribers still communicate when Dubbo’s registry cluster is down?

It can communicate. When Dubbo is started, consumers will pull data such as the address interface of registered producers from Zookeeper and cache it locally. Each invocation is made according to the address of the local store.