preface
Earlier this year, Dubbo, Alibaba’s open source high-performance service framework, started a new round of updates and joined the Apache incubator. Dubbo has been used less frequently since the original project used Spring Cloud. It is now pulling back to the original industry application and possibly using Dubbo for service invocation. I took the opportunity to study At Lebyte while I was writing the textbook. And at present Dubbo also out of the Springboot starter project, by springboot dongfeng, integration is very convenient, basically a dependency package introduced the problem. Without further ado, let’s begin
A little knowledge
For those of you who haven’t been exposed to Dubbo, take a look.
Introduction of Dubbo
Dubbo is an open source high-performance service framework of Alibaba, which is committed to providing high-performance and transparent RPC remote service invocation solutions and SOA service governance solutions, enabling applications to achieve seamless integration of service output, input functions and Spring framework through high-performance RPC. Dubbo consists of three core parts: remote communication, cluster fault tolerance and automatic discovery.
It provides transparent remote method invocation, enabling remote methods to be called as if they were local methods, requiring simple configuration and without any API intrusion. At the same time, it has soft load balancing and fault tolerance mechanism, can replace the hardware load balancer such as F5 on the Intranet, reduce the cost and reduce the single point. It can realize automatic service registration and discovery, no longer need to write the service provider address, registry based on the interface name query service provider IP address, and can smoothly add or delete service providers.
At the end of 2011, Alibaba opened the Java-based distributed service governance framework Dubbo on GitHub. Since then, it has become the leader of such open source projects in China, and many developers like it. At the same time, many companies have implemented distributed system architecture based on Dubbo in practice. It currently has more than 10,000 forks and stars on GitHub.
Dubbo core features:
Remote communication, which provides an abstract encapsulation of a variety of long-connection-based NIO frameworks, including multiple threading models, serialization, and request-response mode of information exchange.
Cluster fault tolerance, provides transparent remote procedure call based on interface method, including multi-protocol support, as well as soft load balancing, failure tolerance, address routing, dynamic configuration and other cluster support.
Automatic discovery, based on registry directory services, enables service consumers to dynamically find service providers, makes addresses transparent, and allows service providers to smoothly add or subtract machines.
Dubbo architecture
Service provider – Exposes the service on the specified port at startup and registers the service address and port with the registry
Service consumer – Subscribes to the registry at startup for services of interest to get a list of service providers’ addresses
Registry – Responsible for service registration and discovery, responsible for saving the address information reported by the service provider, and push to the service consumer
Monitoring center – Collects the health status of service providers and consumers, such as number of service calls, latency, and so on, for monitoring
Run container – Responsible for service provider initialization, loading, and run lifecycle management
Deployment phase
The service provider exposes the service at the specified port and registers the service information with the registry.
A service consumer initiates a subscription to the registry for a list of service addresses.
Operation phase
The registry pushes address list information to service consumers.
The service consumer receives a list of addresses and selects one of them to make a call to the target service.
The health status of the invocation process service consumer and service provider is reported to the monitoring center.
Call Relationship Description
The service container is responsible for starting, loading, and running the service provider.
At startup, service providers register their services with the registry.
At startup, service consumers subscribe to the registry for the services they need.
The registry returns a list of service provider addresses to the consumer, and if there are changes, the registry pushes the change data to the consumer based on the long connection.
The service consumer, from the provider address list, selects one provider to call based on the soft load balancing algorithm. If the call fails, selects another one to call.
Service consumers and providers accumulate calls and call times in memory and regularly send statistics to the monitoring center every minute.
Dubbo characteristics
The Dubbo architecture is characterized by connectivity, robustness, scalability, and scalability to future architectures.
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
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
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
scalability
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:
Node Role description
Node Role description
Deployer automatically deploys the local proxy for the service
A Repository is used to store service application distributions
The Scheduler automatically adds or removes service providers based on access pressure
Admin Unified management console
Registry a Registry where services are registered and discovered
Monitor A monitoring center that collects statistics on the number and duration of service invocation
You can visit the official website: dubbo.apache.org/zh-cn/docs/…
Dubbo integration and use
Based on the official incubation-Dubo-spring-boot-project, integration in SpringBoot is simple.
Note: Since this series continues to use version 1.5.x, use version 0.1.x. If you use SpringBoot2.x, you can use version 0.2.x.
Spring-boot-dubo-api is an interface project created for convenience.
IHelloService.java
Service provider
Create a spring-boot-Dubbo-Provider project. 0. Introduce POM dependencies.
Note: Redis is used directly as the registry. The default is ZooKeeper.
1. Write interface implementation classes. HelloServiceImpl.java
Description: @ the Service here is package path com. Alibaba. Dubbo. Config. The annotation. The annotation class under the Service, it specifies the interface version, protocol id and registry id and other basic information. Note that the version number is useful, because there may be multiple versions of an interface, so the version information is generally set. 2. Set the configuration file and add dubbo information, such as the registry type and address.
Note: Redis is used directly as the registry for convenience. For redis connection configuration parameters, related to dubbo. Registry. The parameters. The XXX in the form of a set, because of the parameters is a Map object, so add the key is not to convert the case, to fill in what is what. Specific registry configuration object, you can see the com. Alibaba. Dubbo. Config. RegistryConfig class. Related parameters for the redis configuration, you can view the com. Alibaba. Dubbo. Registry. Redis. RedisRegistry class.
Other registry, is also similar, you can be in the package. Com. Alibaba dubbo. The registry to find to registry configuration classes.
3. Start class writing.
DubboProviderApplication.java
4. Start the application and access the Redis service. You can see the service list.
Service consumer
Create the spring-boot-Dubo-consumer project. 0. Introduce POM dependencies
1. Add information about the registry and service version to the configuration file
2. Start class writing
DubboConsumerApplication.java
3. Write a RESTAPI service to invoke the service.
4. Start the application, visit: http://127.0.0.1:9696/hello? Name =oKong, you can see that the service invocation succeeded.
Monitoring the background
Official monitoring supports ZooKeeper by default. The official documentation also states that the redis bridge implementation is only available in the open source version, and its reliability depends on the reliability of Redis itself. Use ZooKeeper instead of Redis as a cache.
Address of monitoring console: github.com/apache/incu… You can install instructions to compile and run.
New monitoring interface:
After joining the Apache incubator, the interface is in English. Or the original look comfortable ah!
conclusion
This chapter mainly introduces the integration and simple use of Dubbo.
The article is from Lebyte