Selection of distributed RPC service invocation framework: using Dubbo to realize distributed service invocation

Time:2021-12-1

Dubbo concept

  • Dubbo is a high-performance, lightweight RPC distributed service framework
  • Three core competencies are provided:
    • Interface Oriented Remote Method Invocation(@Reference)
    • Intelligent fault tolerance
    • load balancing
  • Dubbo features:The layered architecture can decouple the layers
  • Dubbo’s role:
    • Provider:Provider
    • Consumer:Consumer
    • Dubbo provides a very simple service model, either the provider provides services or the consumer consumes services

Dubbo’s service governance

  • Transparent remote call:Calling a remote method is like calling a local method. It only needs simple configuration without any API intrusion
  • Load balancing mechanism:The client side LB replaces F5 and other hardware load balancers in the intranet
  • Fault tolerant retry mechanism:Service mock data, number of retries, timeout mechanism
  • Auto registration discovery:The registry queries the IP address of the service provider based on the interface name, and you can add and delete service providers
  • Performance log monitoring:Monitor, a monitoring center that counts the number and time of service calls
  • Service governance center:Routing rules, dynamic configuration, service degradation, access control, weight adjustment, load balancing

Dubbo’s core functions

  • Remoting:Remote communication provides Abstract encapsulation of a variety of NiO frameworks, including information exchange modes of “synchronous to asynchronous” and “request response” modes
  • Cluster:The service framework provides transparent remote procedure calls based on interface methods, including:Multi protocol support, soft load balancing, fault tolerant retry, routing rules, dynamic configurationOther cluster support
  • Registry:Service registry, automatic service discovery. Based on the registry directory service, the service consumer can dynamically find the service provider, make the address transparent, and enable the service provider to smoothly increase and reduce the number of machines
Communication model:
Bio: sync and block
NiO: asynchronous and blocking
AIO: asynchronous non blocking

Communication framework: netty

Dubbo component role

Component role explain
Provider Service provider of exposed services
Consumer The service consumer that invokes the remote service
Registry Registry for service registration and discovery
Monitor Monitoring Center for counting service call times and call times
Container Service run container

Description of component call relationship

  • Service containerContainerResponsible for starting, loading and running the service provider
  • Service providerProviderAt startup, register your services with the registry
  • Service consumersConsumerAt startup, subscribe to the registry for the services you need
  • Registration CenterRegistryReturn the service provider address list to the consumer. If there is any change, the registry will push the change data to the consumer based on the long connection
  • Service consumersConsumerFrom the provider address list, select one provider to call based on the load balancing algorithm. If the call fails, select another provider to call
  • Service consumersConsumerAnd service providersProvider, accumulate call times and call time in memory, and regularly send statistical data to the monitoring center every minute

Dubbo admin admin console

  • Main functions of the management console:
    • Routing rules
    • Dynamic configuration
    • service degradation
    • access control
    • Permission adjustment
    • load balancing