Exploration and practice of Node calling Dubbo service

1. Background

Our company is an e-commerce company in Hangzhou, which has a lot of technical system. The main language is JAVA/PHP/Node. In 2013, the company made a plan to de-php, depositing back-end logic into JAVA servitization, while Node took over part of servitization call related business. Communication with Java needs to go through Dubbo, so in the role of Consumer, we explore how to invoke Dubbo from Node.

2. Introduction of Dubbo

2.1 What is Dubbo

Dubbo is a high-performance, lightweight, open source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

2.2 the flow chart

• Provider: exposes the service Provider of the service.
• Consumer: Service Consumer that invokes the remote service.
• Registry: A Registry where services are registered and discovered.
• Monitor: monitors The Times and time of service invocation.
• Container: service running Container.

3. Implementation

3.1 Protocol Selection

Official support many kinds of agreement, but not many really suitable for our agreement, such as main target is the rmi protocol between the Java project called, is not suitable for heterogeneous language RPC scene, so we only for the next part of the protocol is analyzed, and combining with our actual business scenarios, finally to qualify for our agreement.

3.1.1 Protocol Selection – Dubbo

In terms of application scenarios, DuBBO protocol meets our actual business requirements. Compared with Http, its packets are much smaller and the transmission speed is faster. In addition, we can establish a long connection with the provider through socket, which can reduce unnecessary network overhead caused by repeated connection construction. A few points to note when using this protocol are

• Local load balancing policy
• Establish a TCP long connection with the Provider
• Hessian protocol parsing

Summary: If you want to use this protocol to connect providers, you can use dubbo2.js, which is recommended by Dubbo

3.1.2 Protocol Selection – REST

This protocol is based on HTTP, so there are virtually no restrictions on the consumer side. In addition, after stitching the parameters of this protocol, we can view the results directly through the browser or HTTP request tool, which is better than Dubbo in terms of friendliness. The consumer side can directly use the Request library to request, there are no problems of protocol parsing and socket state maintenance, and the code implementation of the consumer side is relatively easy. A few points to note when using this protocol:

• You need to use keep-alive to maintain the connection with the provider. Otherwise, repeated HTTP disconnection and reconnection may cause unnecessary network overhead
• Local load balancing policy
• This protocol is only supported on Dubbo 2.6.x+

Summary: Performance is not as good as Dubbo. However, they are friendly to developers and can be selected according to their own business scenarios.

3.1.3 supplement

For example, a service can be registered with both Dubbo :// and REST :// at the same time. If you want to use HTTP, but the protocol currently exposed by the company only supports Dubbo, you can consult the student who provides the service. The cost of adding an additional HTTP protocol is also within reach.

3.2 How Can I Reference a Service

Currently, there are two schemes for referencing services, namely

• Direct reference
• Reference services through a registry

3.2.1 Direct Reference service

Direct reference services, as the name implies, bypass the registry to get the service provider we want, because bypassing the registry, naturally can not achieve service discovery, and because of the single point of problem, can not achieve load balancing and high availability, so this pattern is not recommended for production environments.

However, this pattern can still be tried in a development/test environment due to its ease of development.

As shown in the figure above, in the process of developing classmate joint survey, it is necessary to directly connect the machine of the specified service developer in the project project, and other services that are not specified will go through the registry by default. In order to avoid the invasion of the project code, we will establish dubbo.properies for different environments in the project, and dubbo.properies will not be added to the version control of the project, which is mainly used to solve the problem of direct service connection in different environments. The control granularity of services can be precise to specific services.

3.2.2 Referencing services through the registry

Discover reference services through the registry. Dubbo references services in a common way to achieve automatic service discovery and load balancing. Formal environment calls are based on this pattern. The registry implementation there are many, such as the Zookeeper/Redis/Multicast. Zookeeper is officially recommended.

3.3 Definition of service request structure

Service request body structure is a layer of encapsulation after the abstraction of dubbo registration information in the registry. On the one hand, it can improve the development efficiency of developers and reduce the error rate of their own manual stitching requests.

3.3.1 Composition of services

We are based on dubbo/ REST two protocols, to analyze the two protocols in the registry registration information.

• dubbo : Dubbo: / / 192.168.1.2 instead: 10880 / com. Service. ProductService? Dubbo = 2.8 & the methods = getById getByName
• rest : Rest: / / 192.168.1.2 instead: 10081 / service/com. Service. ProductService? Dubbo = 2.8 & the methods = getById getByName

Let’s extract the common parts of these two protocols

• Protocol: indicates the protocol type. For example,dubbo://.
• Host: provider host address
• Port: indicates the port used by the provider to expose services
• Interface: indicates the exposed service name. In Java, the package name and service name are used, for examplecom.service.ProductService
• DubboVersion: dubbo version
• Method: Exposes the method of a service. A service contains multiple methods.
• Query: Another is the request parameter list, which is defined in the Java service and is not reflected in the registration information.

3.3.2 Definition of request body

Based on the above analysis of service structure composition, dubbO and REST service request structure are generally similar. We can define different protocol requests as follows.

// 1. Request body definition for dubbo protocol
services.ProductService = (dubbo) = > dubbo.proxyService({
    dubboInterface: 'com.service.ProductService'.methods: {
        getById(id) {
            return [java.Long(id)];
        },
        getByName(name) {
            return[java.String(name)]; }}});Copy the code

// Rest request body definition
services.ProductService = (dubbo) = > dubbo.proxyService({
    dubboInterface: 'com.service.ProductService'.methods: {
        getById(id) {
            return {
                method: 'get'.query: [parseInt(id)]
            };
        },
        getByName(name) {
            return [String(name)]; }}});Copy the code

The main difference between the two is in the definition of arguments. Dubbo requires strong casting, while REST does not.

3.4 Maintenance of service definitions

After the service definition is completed, we will face a problem in use. The most direct method is to create a service file for each project and each service. However, when we use it, we will find a problem that the files requiring the definition are scattered in different projects and cannot be maintained and upgraded uniformly, resulting in high maintenance costs.

Our first reaction is to abstract each service into an independent NPM package. For example, MemberService can be abstracted into @dubo-service /member-service, which can solve the maintenance problems caused by the scattered files in different projects.

3.4.1 Follow-up Questions

At this point, we have solved the problem of how services are uniformly defined, but we still have not solved the problem of unified management and maintenance. Such as:

• Responsibilities of maintenance personnel. Should the maintenance of the NPM package be left to the service provider or the service caller?
• Project migration cost issues. If the project migration problem is involved, it may involve a lot of existing Java service initialization problems, and manually defining the service is a huge amount of engineering, how to reduce the cost of migration is a problem we have to face.

4 the last

If you find this article helpful, please give it a thumbs up. Thank you very much

What questions can be directly comment reply or private letter to me, I will try my best to reply to you ~