The little squares represent future plans completed
Chung hwa-hyun is not considering writing
1.2 Dubbo User Guide
In this section, we will “fine Dubbo source code analysis” and “Dubbo user guide” to do a mapping, convenient for you to directly find the specific source code implementation of the function of interest. Of course, if there is not in place, welcome to give me a message as if corrected.
γ<2> Quick start γ
Dubbo uses a full Spring configuration mode to transparently access applications without any API intrusion. You only need to load Dubbo’s configuration with Spring. Dubbo is loaded based on Spring’s Schema extension.
If you don’t want to use Spring configuration, you can call it through the API.
Corresponding source code analysis article:
Dubbo source code Analysis – Debugging environment construction
[<5.1> XML Configuration]
For details on XML configuration items, see Configuration Reference manual. If you do not want to use The Spring configuration and want to invoke it through the API, see: API Configuration. To learn how to use the configuration, see quick Start.
Corresponding source code analysis article:
Dubbo source Code Parsing — XML Configuration
[<5.2> Attribute Configuration]
If the common configuration is simple without multiple registries, protocols, etc., or if you want multiple Spring containers to share the configuration, you can use dubo.properties as the default configuration.
Dubbo will automatically load Dubbo. Properties in the root directory of the classpath, which can be changed by JVM startup parameter -ddubbo.properties.file=xxx.properties. 1
API properties and configuration items one to one, the meaning, please see: configuration reference manual, such as: ApplicationConfig. Elegantly-named setName (” XXX “) corresponding to the < dubbo: application name = “XXX” / > 1
Corresponding source code analysis article:
Dubbo source Code Parsing — APPLICATION of API Configuration (1)
Dubbo Source Code Parsing — API Configuration part 2: Service Providers
Dubbo Source Code Parsing — API Configuration part 3: Service Consumers
Dubbo checks whether dependent services are available at startup. If not, an exception will be thrown to prevent Spring initialization from being completed so that problems can be detected early when it goes online. By default, check=”true”.
Check =”false” can be used to turn off checks, for example, if some services do not care during testing, or if cyclic dependencies occur and one party must be started first.
In addition, if your Spring container is lazy to load, or if your API is programmed to delay referencing services, turn check off. Otherwise, if the service is temporarily unavailable, an exception will be thrown and a null reference will be obtained. If check=”false”, the reference will always be returned, and when the service is restored, it will be connected automatically.
Note that the service provider failed to register and the checking function was not enabled. This point, the author has been misunderstood.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Registry 1 Abstract API
[<6.2> Cluster fault tolerance]
When a cluster invocation fails, Dubbo provides multiple fault tolerance schemes. By default, failover retry is used.
If the logic for event processing is done quickly and no new I/O requests are made, such as just marking an id in memory, it is faster to process directly on the I/O thread because of reduced thread pool scheduling.
However, if the event processing logic is slow or new I/O requests, such as database queries, need to be sent to the thread pool. Otherwise, the I/O thread blocks and cannot receive other requests.
If an I/O thread processes an event and a new I/O request is initiated during the event processing, for example, a login request is initiated during a connection event, a deadlock may be raised exception is reported, but the deadlock is not true.
Corresponding source code analysis article:
Dubbo source Code Analysis — Thread Pool
[<6.5> Directly connected provider]
In the development and testing environment, often need to bypass the registry, testing only designated service provider, this time may need A point-to-point direct, point-to-point straight mode, will be in the service interface, ignore the registry provider list, A point-to-point interface configuration, does not affect the B interface list was obtained from the registry.
For development testing purposes, it is common to share a registry of all services available offline, where a registered service provider under development may affect consumer performance.
You can have service provider developers test services under development by direct connection, only subscribing to services that may depend on other services, without registering services under development.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Local Exposure of Service References (I) (Injvm)
[<6.7> Registration only]
If you have two mirrored environments, two registries, one service is deployed in only one of them, the other is not yet deployed, and other applications in both registries need to rely on this service. At this point, the service provider can only register the service to another registry, rather than subscribing to the service from another registry.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Local Exposure of Service References (I) (Injvm)
[<6.8> Static Service]
In cases where you want to manually manage the online and offline management of service providers, you need to mark the registry as non-dynamically managed.
Dubbo allows you to configure multiple protocols, support different protocols on different services or support multiple protocols simultaneously on the same service.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Service Exposure (1) Local Exposure (Injvm)
Dubbo supports simultaneous registration of the same service in multiple registries, registration of different services in different registries, and even simultaneous reference of the same service registered in different registries. In addition, the registry supports custom extensions.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Service Exposure (1) Local Exposure (Injvm)
When an interface is implemented and an incompatible upgrade occurs, the version number can be used for transition. Services with different version numbers do not reference each other.
You can follow these steps to perform version migration:
During low-stress periods, upgrade half of the providers to the new version first
Then upgrade all customers to the new version
Then upgrade the remaining half of the providers to the new version
Group and return result 1, such as menu service, the same interface, but there are multiple implementations, distinguished by group, now the consumer needs to call from each group return result, merge result return, so that the implementation of aggregation menu items.
Corresponding source code analysis article:
Dubbo source Code Analysis — Cluster Fault Tolerance (5) : The Implementation of a Merger
[<6.14> Parameter verification]
Parameter validation function 1 is implemented based on JSR303. Users only need to identify validation annotations of the JSR303 standard and implement validation 2 by declaring filters.
Result cache 1, used to speed up access to hot data, and Dubbo provides declarative cache to reduce user caching effort 2.
Corresponding source code analysis article:
Dubbo Source Code Analysis – CacheFilter (10)
[<6.16> Generalized citation]
The generalized interface invocation method is mainly used when the client does not have API interfaces and model class elements. All POJOs in parameters and return values are represented by Map. It is usually used for framework integration, for example, to achieve a universal service testing framework that can invoke all service implementations through GenericService.
Corresponding source code analysis article:
“Complete Dubbo source parsing — Generalization References to Call Features (II)”
[<6.17> Generalization implementation]
The generic interface approach is mainly used when there is no API interface and model class element on the server side. All POJOs in parameters and return values are represented by Map. It is commonly used for framework integration, such as implementing a generic remote service Mock framework that can handle all service requests by implementing the GenericService interface.
Echo test is used to check whether the service is available. Echo test is performed according to the normal request flow to test whether the whole call is smooth and can be used for monitoring.
All services automatically implement the EchoService interface. You only need to force any service reference to be converted to EchoService.
The context holds the environment information required during the current invocation. All configuration information is converted to URL parameters. For details, see the corresponding URL parameters column in the Schema Configuration Reference.
The RpcContext is a temporary state logger of a ThreadLocal. The state of the RpcContext changes when an RPC request is received or initiated. For example, if A calls B and B calls C, RpcContext records the information of B dialed by A before B dialed C, and RpcContext records the information of C dialed by B after B dialed C.
Corresponding source code analysis article:
Dubbo: ContextFilter (ContextFilter)
[<6.20> Implicit parameter]
Parameters can be passed implicitly between the service consumer and provider via setAttachment and getAttachment on the RpcContext. 1
Corresponding source code analysis article:
Dubbo: ContextFilter (ContextFilter)
γ<6.21> Asynchronous call γ
NIO based on non-blocking implementation of parallel invocation, the client does not need to start multithreading to complete the parallel invocation of multiple remote services, relatively less overhead multithreading. 1
The local call uses injVM, a pseudo-protocol that does not open ports, does not initiate remote calls, and is only directly associated within the JVM, but performs Dubbo’s Filter chain.
Corresponding source code analysis article:
Dubbo source Code Analysis — Service Invocation (1) Local Invocation (Injvm)
[<6.23> Parameter callback]
A parameter callback works the same way as a call to a local callback or listener; you simply declare in Spring’s configuration file which parameter is of type callback. Dubbo will generate a reverse proxy based on long connections so that client logic 1 can be invoked from the server side. Refer to the sample code in the Dubbo project.
Corresponding source code analysis article:
Dubbo [4] Parameter Callback (Dubbo)
[<6.24> Event Notification]
Oninvoke, onReturn, and onThrow are triggered before, after, and when an exception occurs. You can configure which method of which class to be notified when an event occurs.
After remote service, the client is usually left with the interface and the implementation is all on the server side, but the provider sometimes wants to perform part of the logic on the client side as well, for example: The client generates a Proxy instance, passes the Proxy to Stub 1 through its constructor, and then exposes the Stub to the user. The Stub can decide whether to invoke the Proxy or not.
Local masquerade 1 is commonly used for service degradation, such as a validation service, where the client does not throw an exception when all service providers fail, but returns authorization failure through Mock data.
Corresponding source code analysis article:
Mock Implementation for Cluster Fault Tolerance (8)
[<6.27> Delayed exposure]
If your service needs time to warm up, such as initializing the cache, waiting for relevant resources to be in place, etc., use delay for delay exposure.
Corresponding source code analysis article:
Dubbo Source Code Parsing — API Configuration part 2: Service Providers
[<6.28> Concurrency control]
Limit each method of com.foo.BarService to no more than 10 concurrent server executions (or threads in the pool)
Limit the sayHello method of com.foo.BarService to no more than 10 concurrent server executions (or threads in the pool)
Limit each method of com.foo.BarService to no more than 10 concurrent (or connection hogging) requests per client
Limit the sayHello method of com.foo.BarService to no more than 10 concurrent execution (or connection hogging requests) per client
Delayed connections are used to reduce the number of long connections. When a call is made, the long connection is created. 1
Corresponding source code analysis article:
Dubbo source code parsing — Service Call (2) Remote Call (Dubbo) [1] Communication Implementation
[<6.31> Sticky connection]
Sticky connections are used for stateful services so that clients always make calls to the same provider as possible, unless that provider dies and then connects to another.
Sticky connections automatically enable delayed connections to reduce the number of long connections.
Controlling permissions in the registry to decide whether to issue a token to a consumer through token authentication prevents consumers from bypassing the registry to access providers, and the registry provides flexibility to change authorization without modifying or upgrading the provider
Routing rule 1 determines the target server for a dubbo service invocation. It is divided into conditional routing rules and scripted routing rules, and supports extensible 2.
Write dynamic configuration override rule 1 to the registry. This function is typically performed by a page in the monitoring center or governance center.
Corresponding source code analysis article:
Dubbo: A Configuration for Dubbo
[<6.35> Service degradation]
You can use service degradation function 1 to temporarily mask an error non-critical service and define the return policy after degradation.
Corresponding source code analysis article:
Mock Implementation for Cluster Fault Tolerance (8)
[<6.36> Graceful stop]
Dubbo uses JDK ShutdownHook to implement graceful shutdown, so if the user uses kill -9 PID or other forced shutdown commands, graceful shutdown will not be performed, only if the user passes kill PID.
Corresponding source code analysis article:
Dubbo source code parsing — Elegant downtime
γ<6.37> Host Binding γ
Default host IP address search order:
throughLocalHost.getLocalHost()Gets the local address.
If it is127. *And the loopback IP address, scan for each nic and obtain the NIC IP address.
Corresponding source code analysis article:
Dubbo Source Code Parsing — API Configuration part 2: Service Providers
<6.38> Log Adaptation
Since 2.2.1, Dubbo has built in log4j, SLF4J, JCL, JDK and other logging frameworks. You can also display and configure log output policies in the following ways:
The command line
indubbo.propertiesSpecified in the
indubbo.xmlIn the configuration
Corresponding source code analysis article:
Dubbo source code parsing – Log adaptation
[<6.39> Access log]
If you want to log every request, you can enable access logging, similar to Apache’s access logging. Note: The amount of logs is large. Please pay attention to the disk capacity.
Corresponding source code analysis article:
Dubbo source code parsing — AccessLogFilter (3)
[<6.40> Service Container]
The service container is a standalone startup, because the background service does not need the functions of a Web container such as Tomcat or JBoss. If you use the Web container to load the service provider, it will add complexity and waste resources.
The service container is just a simple Main method that loads a simple Spring container to expose the service.
The load content of the service container can be extended, with built-in spring, Jetty, Log4j, etc., and can be extended through container extension points. The configuration is set in the -d parameter of the Java command or in dubo.properties.
Corresponding source code analysis article:
Dubbo: Service Container
<6.41> ReferenceConfig cache
The ReferenceConfig instance is heavy, encapsulates connections to the registry as well as to the provider, and requires caching. Otherwise, repeated generation of ReferenceConfig can cause performance problems and memory and connection leaks. It’s easy to ignore this problem when programming in API mode.
Therefore, since version 2.4.0, Dubbo provides a simple utility class called ReferenceConfigCache for caching ReferenceConfig instances.
Corresponding source code analysis article:
Dubbo Source Code Parsing — API Configuration part 3: Service Consumers
γ<6.42> Distributed transactions γ
Distributed transactions are implemented based on JTA/XA specification 1.
Two-phase commit:
At present, this function is not implemented, the following is recommended reading:
Sharding-jdbc Source Code Analysis — Distributed Transactions (PART 1) best Effort Type
MyCAT Source Code Analysis — XA Distributed Transaction
Tcc-transaction Source code Analysis — Collection
Happylifeplat-TCC source code parsing — Fine collection
Myth Source Code Parsing — A Collection of fine Works
<6.43> Thread stack automatic dump
When the business thread pool is full, we need to know what resources, conditions, threads are waiting for to find bottlenecks or outliers in the system. Dubbo uses Jstack to automatically export the thread stack to preserve the scene for troubleshooting
Default policy:
The export path, the user home directory identified by user.home
Export interval. The minimum export interval is allowed every 10 minutes
Corresponding source code analysis article:
Dubbo source Code Analysis — Thread Pool
γ < 6.44 > Netty4 γ
Dubbo 2.5.6 adds support for the Netty4 communication module
Corresponding source code analysis article:
Dubbo source code Analysis – NIO Server (6) Netty4 Implementation
γ<8> Schema Configuration Reference Manual γ
This section uses XML Config 1 to list all configuration items 2. For details about other configuration methods, see attribute Configuration, Annotation Configuration, AND API Configuration.
Corresponding source code analysis article:
Dubbo source Code Parsing — XML Configuration
γ < 9.1 > dubbo: / /]
The default Dubbo protocol uses a single long connection and NIO asynchronous communication, which is suitable for small data volume and large concurrent service invocation, and the number of service consumer machines is much larger than the number of service provider machines.
Conversely, the default Dubbo protocol is not suitable for services that transmit large amounts of data, such as files and videos, unless the request volume is very low.
Corresponding source code analysis article:
Dubbo source code parsing — Service Call (2) Remote Call (Dubbo) [1] Communication Implementation
RMI protocol uses JDK standard java.rmi.* implementation, using blocking short connection and JDK standard serialization.
Note: There is a deserialization security risk 3 if you are using RMI to provide services to external access 1 and your application relies on the old Common-Collections package 2.
Corresponding source code analysis article:
Dubbo Source Code Parsing — Remote Invocation (RMI) for Service Invocation (7)
γ < 9.3 > hessian: / /]
Hessian 1 protocol is used to integrate Hessian services. Hessian uses Http communication and Servlet to expose the service. Dubbo province embedded Jetty is implemented as a server.
Dubbo’s Hessian protocol interoperates with the native Hessian service, that is:
The provider exposes the service using Dubbo’s Hessian protocol, and the consumer invokes it directly using the standard Hessian interface
Or the provider exposes the service using the standard Hessian and the consumer invokes it using Dubbo’s Hessian protocol.
The thrift protocol dubbo currently supports 1 is an extension of thrift’s native protocol 2, adding some additional headers, such as Service name, Magic Number, etc.
Using the Dubbo Thrift protocol also requires the compiler of thrift’s IDL compiler to generate Java code, which will be enhanced in future releases.
Dubbo Source Code Parsing — Remote Invocation (REST) for Service Invocation (PART 6)
γ<10.1> Multicast Registry γ
Multicast registries do not need to start any central node, as long as the broadcast address is the same, they can discover each other.
The provider broadcasts its own address at startup
The consumer broadcasts the subscription request when it starts
When the provider receives a subscription request, unicast its own address to the subscriber, if setunicast=false, broadcast to subscribers
When the consumer receives the provider’s address, it connects to the address for an RPC call.
Multicast is limited by the network structure and is only suitable for small-scale applications or development. Multicast address range: 224.0.0.0 to 239.255.255.255
Corresponding source code analysis article:
Source Code Analysis of Dubbo – For Multicast (5)
[<10.2> ZooKeeper Registry]
Zookeeper is a subproject of Apacahe Hadoop. It is a tree directory service that supports change push and is suitable for Dubbo service registry. It has high industrial intensity and can be used in production environment.
Corresponding source code analysis article:
Dubbo source code analysis – Zookeeper client
Dubbo Source Code Analysis — Registry 1 Abstract API
The Simple registry itself is a generic Dubbo service that reduces third-party dependencies and makes overall communication consistent.
Corresponding source code analysis article:
Complete Dubbo Source Code Analysis — Simple for Registry 4
γ<11> Telnet Command Reference Manual γ
Starting with version 2.0.5, Dubbo supports mirroring service governance through Telnet commands.
Corresponding source code analysis article:
Dubbo source Code Analysis – NIO Server (3) Telnet Layer
[<12> Online O&M command -QOS]
Dubbo 2.5.8 refactored the Telnet module with new Telnet command support.
Corresponding source code analysis article:
TODO
dubbo-ops
1.3 Dubbo Development Guide
In this section, we will “fine Dubbo source code analysis” and “Dubbo development guide” to do a mapping, convenient for you to directly find the specific source code implementation of the function of interest. Of course, if there is not in place, welcome to give me a message as if corrected.
γ<1> source code construction γ
Code check out branch build build source code JAR package IDE support
Corresponding source code analysis article:
Dubbo source code Analysis – Debugging environment construction
Dubbo source code Analysis — Core Process Overview
[<3> Extension point loading]
Dubbo’s extension point loading is enhanced from the JDK standard Service Provider Interface (SPI) extension point discovery mechanism.
Dubbo improves on the following issues with the JDK standard SPI:
The JDK’s standard SPI instantiates all implementations of extension points at once, which is time-consuming to initialize if there is an extension implementation, but wasteful of resources to load without it.
If the extension point fails to load, you will not even get the name of the extension point. For example: The JDK standard ScriptEngine, passedgetName()Get the name of the script type, but if RubyScriptEngine fails to load the RubyScriptEngine class because the jruby.jar on which it depends does not exist, this failure is eaten and does not match Ruby. When the user executes the Ruby script, The fact that the club does not support Ruby is not the real reason for the failure.
Added support for extension points IoC and AOP, where one extension point can directly setter for injection of other extension points.
RPC protocol extension to encapsulate remote call details.
Contract:
When the user callsrefer()The returnedInvokerThe object’sinvoke()Method, the protocol needs to be executed accordingly with the URL remoteexport()The incomingInvokerThe object’sinvoke()Methods.
Among them,refer()The returnedInvokerImplemented by protocol, which is usually required hereInvokerTo send a remote request,export()The incomingInvokerImplemented by the framework and passed in, the protocol doesn’t need to care.
Note:
The protocol does not care about transparent proxy of the business interface toInvokerIs centered by the outer layerInvokerConvert to a business interface.
The protocol does not have to be TCP network communication, such as file sharing, IPC interprocess communication, etc.
Corresponding source code analysis article:
Dubbo Source Code Analysis — Service Exposure (1) Local Exposure (Injvm)
The service provider and service consumer invoke procedural interception. Most of the functionality of Dubbo itself is implemented based on this extension point. This interception is executed each time a remote method is executed.
Convention:
User-defined filter comes after built-in filter by default.
Special valuesdefaultRepresents the position where the default extension point is inserted. Such as:filter="xxx,default,yyy"Said,xxxBefore the default filter,yyyAfter the default filter.
Special symbols-, indicating deletion. Such as:filter="-foo1", delete add default extension pointfoo1. Such as:filter="-default"To add all default extension points.
When both the Provider and service filter are configured at the same time, all filters are accumulated instead of overwriting. Such as:<dubbo:provider filter="xxx,yyy"/> ε <dubbo:service filter="aaa,bbb" />,xxx.yyy.aaa.bbbWill take effect. To override, configure:<dubbo:service filter="-xxx,-yyy,aaa,bbb" />
Dubbo source Code analysis – Dynamic Compilation (ii) JDK
[<5.14> Message distribution extension]
Channel information dispatcher that specifies the thread pool model.
Corresponding source code analysis article:
Dubbo Source Code Analysis – NIO Server (1) Abstract API
[<5.15> Thread pool expansion]
The service provider threading implements the policy of creating a thread in the thread pool to execute the service provider business logic when the server receives a request.
Corresponding source code analysis article:
Dubbo source Code Analysis — Thread Pool
γ<5.16> Serialized extension γ
Converting an object into a byte stream for network transmission, and converting a byte stream into an object for restoration upon receipt of byte stream data.
Corresponding source code analysis article:
Dubbo Source Code Analysis – Serialization (I) of the Overall implementation
Dubbo source code analysis – Serialization (ii) Dubbo implementation
