Dubbo RPC framework

 

Question 1: Why do we split the system into distributed? Why use dubbo?

1. Why do you want to split the system?

  1. If it does not split system, a large system of hundreds of thousands of lines of code, many people maintain a common code is simply a tragedy;

  2. After the split, a large system to split into many small services, the average system also tens of thousands of lines of code, each service is deployed to a single machine

2. How to split the service?

Most of the system is to split multiple rounds, the first time it is possible to split the original multiple modules split open.

But then each system may have become very complicated, split out each service module but also continue to split.

3. The resolution can not dubbo it?

Of course, a big deal among various systems, based on direct SpringMVC, to communicate with each other via an interface httpj pure. But there is definitely a problem, because the HTTP interface communications maintenance is costly to consider the timeout retry, load balancing and other issues.

So dubbo said plainly, is a rpc framework, is local is the interface to call, but dubbo will delegate the call request with the remote machine network traffic, handling load balancing, offline auto-sensing on the service, the timeout retries and so on, do not we do it yourself, to dubbo.

Question 2: talk about dubbo works, hung up the registry may continue to communicate it? Talk about a rpc request process?

1.dubbo works

2.dubbo stratified

  • The first layer: service layer, service providers need to achieve and consumer

  • The second layer: config layer, a layer configuration, mainly a variety of configuration dubbo

  • The third layer: proxy layer, a service agent layer, a transparent skeleton stub and server generating the client

  • The fourth layer: registry layer, end of service registration and discovery

  • Fifth layer: cluster layer, a cluster layer, a plurality of service providers package routing and load balancing, multiple service instances are combined into a

  • Sixth layer: monitor layer, control layer, on the number of calls and call times rpc interface monitor

  • Seventh layer: protocol layer, remote call level, packaging rpc call

  • Eighth Layer: exchange layer, an exchange of information layers, encapsulating a request response mode, synchronous asynchronous transfer

  • Ninth layer: transport layer, network transport layer, mina abstract and unified interface to netty

  • Tenth Layer: serilize layer, a data layer sequence

 

2. Register Center can continue to communicate it to hang up?

Is possible, because the client access to services for the first time from the end of the service after registration center will be in their own local cache, the next call to the server do not have to request registration center, therefore registry hung up can continue to communicate

 

Question 3: dubbo which communications protocols and serialization protocols support

1.dubbo support different protocols

  1. dubbo agreement

    The default is to take dubbo agreement, a single long link, NIO asynchronous communication

    (NIO Communication Theory: NIO employed Reactor pattern (similar to the observer pattern, except that the Reactor pattern can monitor multiple topics) to monitor network handles multiple clients via a multiplexer, upon listening to the customer end of the request message, the corresponding request message Handler (class service processing) to the corresponding)

    Suitable scene: a small amount of data transmission, but high concurrency

  2. rmi protocol

    Go java binary serialization, multiple short connection, for a similar number of consumers and providers for transferring files, generally less

  3. hessian agreement

    Take hessian serialization protocol, a plurality of short connection, are adapted to provide more than the number of consumers and the number, suitable for file transfer, the use of generally less

  4. http protocol

    Go json serialization

  5. webservice

    Take the soap text serialization

 

Question 4: dobbo cluster fault tolerance and load balancing policy strategy? Dynamic proxy policy?

dobbo load balancing strategy

1.random loadbalance

By default, dubbo is random load balcance random call load balancing, you can set different permissions for different provider instance, will follow weights load balancing, the larger the weight distribution the higher the flow, generally use this default on it .

2.roundrobin loadbalance

The default is evenly traffic hit each machine up, but if the performance of each machine is different, easily lead to poor performance of the machine load is too high and downtime. At this point need to adjust the weights so that the performance of the machine almost carrying less weight

3.leastactive loadbalance

This is the automatic perception that, if a machine performance is poor, so fewer requests received, about not active, inactive at this time will give the poor performance of the machine less request

 

4.consistanthash loadbalance

Consistency hash algorithm, the same request parameters assigned to a certain provider up, provider hang time, the remaining flow will be evenly distributed on the virtual node, the jitter is not too large. If the need is not random load balancing, to a class of requests to the node, then take this consistency hash strategy

 

dobbo fault-tolerant cluster strategy

1.failover cluster mode

Failure automatic switching, automatic retries other machines, dubbo default use this strategy

 

2.failfast cluster mode

A failure to immediately fail, common to write

 

3.failsafe cluster mode

Abnormal ignored, commonly used in the interface call unimportant, such as logging

 

4.failbackc cluster mode

Background automatic recording request failed, then the timing of transmission, the message queue is suitable for such a case

 

5.focking cluster mode

Parallel call multiple provider, as long as a successful return immediately

 

6.broadcast cluster mode

Call one by one all the provider

 

dubbo dynamic proxy policy

Default javassist bytecode generated dynamically created proxy class

 

Question 5: You do not understand the spi mechanism? How spi-based mechanisms dubbo be extended?

SPI mechanism

  • Simply put, the service provider interface; for example, has an interface A, now has three interfaces A implementation class, then at runtime which implementation class for the interface in the end use is it? This requires SPI, need to specify the configuration and the default configuration, to find the corresponding implementation classes loaded in, and then the implementation class of the object

    For example: Interface A -> implementation class implementation class A1 A2 A3 implementation class

    Arranged at the interface implementation class A = A2

    When the system is running, it will load this configuration, with the implementation class A2 instantiate an object to provide services

     

    • Let's say you have a project Demo, which has a port A, port A is not achieved in the project in the -> when the system is running, how to choose a class that implements the interface A do?

    • You can get yourself a jar package, META-INF / services /, put on a file, the file name is the interface name, interface A, interface implementation class of A = com.ultrapower.service. Implementation class A2. A project to make rely on this jar package, and then when the system is running, the project ran up to the interface a, it will scan all the jar packages rely on their own, look for the bag in each jar, there is no META-INF / service folder? If so, look inside, there is no interface A file of this name? If so, look at there are no interface implementation class A jar of your bag that class

Dubbo mechanism of SPI

dubbo also used the spi thought, but did not use spi jdk mechanism is a mechanism to realize their own SPI

   1 Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension() 
  • Protocol Interface, dubbo need to determine what, when the system is running, which should be used to this Protocol interface implementation class to instantiate an object to use it?

  • He will find you configure a Protocol, it would Protocol implementation class your configuration is loaded into the jvm in the past, and then instantiates an object, which will be used Protocol interface classes you offer

  • Microkernel, pluggable, a large number of components, Protocol responsible for the RPC call, you can implement your own rpc call components, to achieve Protocol Interface, you can give yourself an implementation class

  • This line is widely used in Dubbo, is for many components, have retained an interface and multiple implementations, and then dynamically based on the configuration to find the corresponding implementation class at runtime, if not configured, then take the default implementation class.

. 1   
2    @SPI ( "Dubbo" )
 . 3    public  interface Protocol {
 . 4         / ** 
. 5         * get the default port, when the user does use the port configuration.
. 6         *
 . 7         * @return default port
 . 8         * / 
. 9        int getDefaultPort ();
 10  . 11 / ** 12 is        * a remote service exposure: <br>
 13 is        * protocol 1. Upon receiving the request, the request should record the address information of the originator .: RpcContext.getContext () setRemoteAddress (); <br>
 14        * 2. Export () must be idempotent, which is exposed to the same URL Invoker twice, and exposure time is no different. <br>
 15        * 3. Export () Invoker implemented by the incoming frame and pass, the agreement does not need to be concerned about. <br>
 16       
            *
 . 17         * @param <T> service type
 18 is         * @param executable service invoker
 . 19         * @return Exporter exposed services references for canceling exposure
 20 is         * @throws RpcException when an error is thrown when exposed services, such ports are occupies
 21 is         * / 
22 is        @Adaptive
 23 is        <T> Exporter <T> Export (Invoker <T> An invoker) throws RpcException;
 24  25 / ** 26 is        * a remote service reference: <br>
 27        * 1. when the user invokes REFER ( when) invoke Invoker object returned () method, the protocol needs to execute the same URL corresponding distal export (incoming invoke Invoker object () method). <br>
 28       
          * 2. refer () Invoker returned by a protocol implemented, the protocol typically requires the remote transmission request in this Invoker. <br>
 29         * 3. When the url has set check = false, the connection failed not throw, and internal automatic recovery. <br>
 30         *
 31 is         * @param type <T> and services
 32         * @param type of service type
 33 is         * @param the URL address of the remote services url
 34 is         * @return local proxy service invoker
 35         * @throws RpcException when connection service Throws provider fails
 36         * / 
37 [        @Adaptive
 38 is        <T> Invoker <T> REFER (Class <T> type, the URL URL) throws RpcException;
 39 40        / ** 
41         * release agreement: <br>
 42         * 1. cancel the agreement has been exposed and all references to the service. <br>
 43         all resources * 2. Agreement to release occupied, such as connections and ports. <br>
 44         * 3. Agreement upon release, was still able to expose and reference the new service. <br>
 45         * / 
46 is        void the destroy ();
 47  48    }

 

In dubbo own jar, in the META-INF / dubbo / internal / com.alibaba.dubbo.rpc.Protocol file

dubbo=com.alibaba.dubbo.rpc.DubboProtocol

http=com.alibaba.dubbo.rpc.HttpProtocol

hessian=com.alibaba.dubbo.rpc.hessianProtocol

All said, this is dubbo default configuration, in fact, a Protocol Interface, @ SPI ( "dubbo") says is to provide an implementation class through the SPI mechanism for implementing class is looking through dubbo to the configuration file as the default key, configuration like when the full pathname of the file name and the name of the interface, as key by dubbo can find the default implementation class is com.alibaba.dubbo.rpc.DubboProtocol

dubbo default network communication protocol, the protocol is dubbo, with DubboProtocol

If you want to replace the default implementation class dynamic, use @Adapter Interface, Protocol interface, there are two ways to add a comment @Adapter, that is to say that both interfaces are proxy implementation.

For example: This Protocol Interface engage both @Adapter notes marked method, at run time, it will generate a proxy class for the Protocol, the two proxy class method which will proxy code, agent code will run when dynamic based on the url protocol to get the key, default is dubbo, you can also specify your own other key, it will get another instance of the implementation class.

The URL of different parameters, the different components can be controlled dynamically using implementation class

 

 

Question 6: How do dubbo-based service management, service degradation, failure retry timeout and retries?

1. Service Management

1. Call link generation

A large distributed system consisting of a large number of service components. How between these services is to call it? Call link is valid?

It would need to do a distributed system dubbo-based calls between the various services automatically recorded, and then automatically link the various dependencies and call out service generation, made a map, you can see

 

2. Service Access pressure and time statistics

Automatic statistics visits and calls the delay between each interface, but also to be divided into two levels. A level of granularity is the interface, the interface is the number of times each day the amount of each service is called, TP50, TP90, TP99, three grades of how many requests were delayed; the second level is the entrance from the source, a complete chain of request after dozens of road service, complete a request, a day full link to go many times, the whole link request delay TP50, TP90, TP99

How much are?

After these things get, behind only to see the current system's pressure Where? How to expansion and optimization?

 

3. Other

Availability monitoring service stratification (avoid circular dependencies), call monitoring and alarm link failure, the authentication service, each service

 

2. Service downgraded

A call services such as service B, service B hang result, few retries call service A service B, or not directly degraded, take a spare logic, returns a response to the user

Question 7: idempotency distributed service interface how to design?

The so-called idempotent, that is an interface with a request to initiate many times, you have to ensure that this interface results are accurate, such as no more deductions, you can not insert more than one data, statistics can not pay more 1. This is idempotent.

 

Idempotent of means to ensure the following:

  • For each request must have a globally unique identifier

  • After each request has been handled, there must be a record identifying the request is finished processing, such as the common program is recorded in a what state mysql, such as running water before paying a record payment of this order, and pay orderid using water as the only key. Only successfully inserted the payment of water before they can perform the actual payment charge.

  • Each time it receives a request needs to be determined whether the previously treated logic processing, for example, and if there is an order has been paid, has already paid a flow, then if the transmission request is repeated, the water at this time to pay the insert, However orderid has been in existence, unique key constraint into effect, error insertion fails, then you do not have a debit

  • General production can be set to ensure that the redis idempotent

 

Question 8: How to design a framework similar to Dubbo's rpc

Comb simple ideas:

  1. Put up on the registry service to register, you should have a registry, each reservation service address information, you can do with a zookeeper.

  2. The consumer then go pick up service registry information, each service may exist in more than one machine

  3. Then you initiate a request in respect of how to send it? Gets based on dynamic agent-oriented interfaces to a dynamic proxy, the proxy is a proxy local dynamic interface, then the agency will find the service addresses corresponding machine

  4. Then find which machine to send a request? Here there will be a load balancing algorithm, for example, you can use the random rotation training algorithm

  5. Find a machine, how to send to him? Can netty, nio way, the second question send what format? Format, or may be a sequence format json

  6. Service from there, the need for your services generate a dynamic proxy, listening on a network port, then your local agent service code, a request is received, it is the local agent of service method.

     

 

Guess you like

Origin www.cnblogs.com/ft-greate/p/12355290.html