Getting Started with Dubbo - Building a Simplest Demo Framework

1. Dubbo background and introduction

1. Evolution of e-commerce system

  Dubbo started with the e-commerce system, so let's start with the evolution of the e-commerce system.

a. Single application framework (ORM)
  When the website traffic is very small, only one application is needed, and all functions such as order payment are deployed together to reduce deployment nodes and costs.
  Disadvantages: The single system architecture makes more and more resources occupied during the development process, and becomes more and more difficult to maintain as the traffic increases.

b. Vertical application framework (MVC)
  vertical application architecture solves the expansion problem faced by a single application architecture, traffic can be dispersed among various subsystems, and the volume of the system is controllable, which reduces collaboration and maintenance between developers to a certain extent. cost and improve development efficiency.
  Disadvantages: But in the vertical architecture, the same logic code needs to be copied continuously and cannot be reused.

c. Distributed Application Architecture (RPC) 

  When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed.

d.
  With the further development of service-oriented architecture (SOA), there are more and more services, and the invocation and dependencies between services are becoming more and more complex. The service-oriented architecture system (SOA) was born, and thus derived A series of corresponding technologies have been developed, such as service frameworks that encapsulate behaviors such as service provision, service invocation, connection processing, communication protocols, serialization methods, service discovery, service routing, and log output.

  From the above is the evolution of the e-commerce system, we can see the process of the architecture evolution: From the above is the evolution of the e-commerce system, we can see the process of the architecture evolution: 

a. Single application architecture
  When the website traffic is very small, only one application is needed, and all functions are deployed together to reduce deployment nodes and costs.
  At this point, a data access framework (ORM) that simplifies the CRUD workload is key.

b. Vertical application architecture
  When the number of visits gradually increases, the acceleration brought by the increase of a single application to the machine is getting smaller and smaller, and the application is divided into several applications that are not related to each other to improve efficiency.
  At this point, a web framework (MVC) for accelerating front-end page development is key.

c. Distributed service architecture
  When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed, so that front-end applications can respond more quickly to changing Market demand.
  At this time, the distributed service framework (RPC) for improving business reuse and integration is the key.

d. Flow computing architecture
  When there are more and more services, capacity evaluation, waste of small service resources and other problems gradually appear, at this time, it is necessary to add a dispatch center to manage the cluster capacity in real time based on the access pressure and improve the cluster utilization rate.
  At this point, a Resource Scheduling and Governance Center (SOA) for improving machine utilization is key.

2. Introduction to RPC

a. RPC (Remote Procedure Call Protocol): Remote Procedure Call
  Two servers A and B deploy different applications a and b respectively. When server A wants to call a function or method provided by application b on server B, it cannot be called directly because it is not in a memory space. It needs to express the semantics of the call and convey the data of the call through the network.
  To put it bluntly, you wrote a program on your machine, which I cannot call directly. At this time, the concept of a remote service call appears.
  RPC is a protocol for requesting services from a remote computer program over a network without requiring knowledge of the underlying network technology. The RPC protocol assumes the existence of some transport protocol, such as TCP or UDP, to carry information data between communicating programs. In the OSI network communication model, RPC spans the transport layer and the application layer. RPC makes it easier to develop applications including network distributed multiprogramming.
  RPC uses a client/server model. The requestor is a client, and the service provider is a server. First, the client calling process sends a call message with process parameters to the server process, and then waits for a reply message. On the server side, the process stays asleep until the call message arrives. When a call message arrives, the server obtains the process parameters, calculates the result, sends a reply message, and then waits for the next call message. Finally, the client calls the process to receive the reply message, obtain the process result, and then the call execution continues.

b. Problems to be solved by RPC
  Communication problem: mainly by establishing a TCP connection between the client and the server, all the exchanged data of the remote procedure call are transmitted in this connection. The connection can be an on-demand connection that is disconnected after the call ends, or it can be a persistent connection, where multiple remote procedure calls share the same connection.
  Addressing problem: How does the application on the A server tell the underlying RPC framework how to connect to the B server (such as a host or IP address) and a specific port, what is the name of the method, so that the call can be completed. For example, for RPC based on the Web service protocol stack, it is necessary to provide an endpoint URI, or to find it from the UDDI service. If it is called by RMI, an RMI Registry is also required to register the address of the service.
  Serialization and deserialization: When the application on the A server initiates a remote procedure call, the parameters of the method need to be passed to the B server through the underlying network protocol such as TCP. Since the network protocol is based on binary, the value of the parameters in the memory must be Serialize into binary form, that is, serialize (Serialize) or marshal (marshal), and send the serialized binary to the B server through addressing and transmission. In the same way, the B server needs to deserialize the parameters to receive the parameters. The result returned by the B server application after calling its own method for processing should also be serialized to the A server, and the reception by the A server should also go through the process of deserialization.

 

2. What is Dubbo

  Dubbo is a distributed service framework, a high-performance and transparent RPC remote service invocation solution, and an SOA service governance solution.
  It provides support for more than 3 billion visits per day for more than 2,000 services, and is widely used in Alibaba Group's member sites and other companies' businesses.

 

3. Dubbo architecture

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: The monitoring center that counts service calls and call times.

Call process
  0. The service container is responsible for starting, loading, and running the service provider.
  1. When the service provider starts, it registers the service it provides with the registration center.
  2. When the service consumer starts, it subscribes to the registration center for the services it needs.
  3. The registry returns the service provider address list to the consumer. If there is a change, the registry will push the change data to the consumer based on the persistent connection.
  4. The service consumer, from the provider address list, selects a provider to call based on the soft load balancing algorithm, and if the call fails, selects another provider to call.
  5. Service consumers and providers accumulate the number of calls and call time in memory, and regularly send statistical data to the monitoring center every minute.

 

4. Dubbo Registration Center

  For the service provider, it needs to publish services, and due to the complexity of the application system, the number and types of services are also expanding;
  for the service consumer, it is most concerned about how to obtain the services it needs, and faces complex applications. system that needs to manage a large number of service calls.
  Moreover, for service providers and service consumers, they may also have both roles, that is, they need to provide services and consume services.

  Through unified management of services, the process and management of service publishing/use by internal applications can be effectively optimized. The service registry can complete the external unification of services through specific protocols.

  The registration center provided by Dubbo has the following types to choose from:

  a.Multicast registry
  b.Zookeeper registry
  c.Redis registry
  d.Simple registry

 

Five. Dubbo advantages and disadvantages

advantage:

1. Transparent remote method invocation: Invoke remote methods
  like calling local methods; just simple configuration without any API intrusion.
2. Soft load balancing and fault tolerance mechanism
  It can replace hardware load balancers such as nginx lvs in the intranet.
3. Service registration center automatic registration & configuration management
  No need to write the service provider address, the registration center automatically queries the provider ip based on the interface name.
  Using distributed coordination services such as zookeeper as the service registry, most project configurations can be moved into the zookeeper cluster.
4. Service interface monitoring and management
  Dubbo-admin and Dubbo-monitor provide complete service interface management and monitoring functions. For different interfaces of different applications, multi-version, multi-protocol, and multi-registration management can be performed.
shortcoming:

  Only supports JAVA language

 

six.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324612719&siteId=291194637