A list,
The official website
1. Official notes
Apache Dubbo is a highly available, Java-based open source RPC framework. The Dubbo framework not only has RPC access capabilities, but also includes service governance capabilities
2. Development history
Dubbo was originally an RPC framework used internally by Alibaba.
Provided externally in 2011.
It stopped updating in 2012.
It will be updated from 2017.
Donated to Apache in 2019, maintained by Apache version 2.7 and above.
Second, architecture explanation
1. The architecture diagram
Register: registration;
Subscribe B.
Notify: notice;
Invoke: call;
The container: the container
2. Architecture description
2.1 the dotted
Dashed lines indicate asynchrony and solid lines indicate synchronization. Asynchronous non-blocking threads have high performance, while synchronous blocking threads must wait for the response result to continue, which has low performance.
2.2 the Provider
Expose the provider of the service. Write the persistence layer, business layer, and transaction code
2.3 the Container
Run the service container (Spring container) and Dubbo is implemented entirely on Spring.
2.4 the Registry
Registration and discovery center for services. Place all the information provided by the Provider. The information includes the IP address of the Provider, access port, access protocol, external interface, and methods on the interface.
2.5 Consumer
Invoke the consumer of the remote service. There is also a project in consumer (RPC caller, SOA project that invokes services) development, writing services and controllers (which can also include pages and so on). Call the method in the Remote Service implementation (XXXXServiceImpl).
2.6 the Monitor
Monitoring center. Monitor Provider pressure. Every two minutes, the Consumer and Provider send the number of calls to Monitor, which counts them.
3. Execute the process
0. Start: The Provider is started when the Spring container is started.
1. Register: Registers the Provider information to the Registry
2. Subscribe: The Consumer subscribes to the Provider information from Registry
3. Please notify the Consumer
Invoke: The Consumer invokes the Provider method based on the information in the Registry notification.
5. Count: The Consumer and Provider asynchronously send the number of calls to the Monitor for statistics.
4.Dubbo architecture features
The Dubbo architecture is characterized by connectivity, robustness, scalability, and scalability to future architectures.
4.1 connectivity
- The registry is responsible for the registration and lookup of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registry at startup, and the registry does not forward requests, which is less stressful
- The monitoring center is responsible for counting The Times and time of service invocation. The statistics are first summarized in memory and then sent to the monitoring center server every minute for presentation in reports
- The service provider registers its services with the registry and reports the invocation time to the monitoring center, which does not include network overhead
- The service consumer obtains the list of service provider addresses from the registry and invokes the provider directly according to the load algorithm, reporting the invocation time to the monitoring center, which includes the network overhead
- The registry, service provider, and service consumer are all long connected, except for the monitoring center
- The registry senses the presence of a service provider through a long connection. If the service provider is down, the registry will immediately push an event to notify consumers
- Both the registry and monitoring center went down without affecting the running providers and consumers, who cached the list of providers locally
- Registries and monitoring centers are optional, and service consumers can connect directly to service providers
4.2 robustness
- The breakdown of the monitoring center does not affect the use of the system, but only the loss of some sample data
- After the database goes down, the registry can still provide a list of services query through the cache, but it cannot register new services
- If one of the registry peer clusters fails, it will automatically switch to the other one
- After all registries go down, service providers and service consumers can still communicate through local caches
- The service provider is stateless. If any service provider breaks down, the service is not affected
- When all service providers go down, the service consumer application becomes unavailable and reconnects indefinitely waiting for the service provider to recover
4.3 scalability
- Registries are peer-to-peer clusters. Machine deployment instances can be dynamically added. All clients automatically discover new registries
- Service providers are stateless and machine deployment instances can be added dynamically, and the registry will push new service provider information to consumers
4.4 upgrade sex
When the scale of service cluster is further expanded and IT governance structure is further upgraded, dynamic deployment and mobile computing need to be realized, and the existing distributed service architecture will not bring resistance. Here is a possible future architecture:
Iii. Agreements supported by Dubbo
1.Dubbo Protocol (official recommendation Protocol)
- Advantages:
NIO is used to reuse a single long connection and use a thread pool to process requests concurrently, reducing handshakes and increasing concurrency efficiency, with good performance (recommended). The default port is 20880
- Disadvantages:
Problems may occur when large files are uploaded (file transfer without Dubbo)
2.RMI(Remote Method Invocation) protocol
- Advantages:
JDK built-in capabilities.
- Disadvantages:
Occasional connection failure
3. The Hessian protocol
- Advantages:
Interoperable with native Hessian, based on HTTP protocol
- Disadvantages:
Hessian. jar is required. HTTP short connections are expensive