What design patterns does Dubbo use?

Dubbo framework uses a variety of design patterns during initialization and communication, which can flexibly control functions such as class loading and permission control. The factory mode Provider invokes the Export method of ServiceConfig when exporting the service. There is a field in ServiceConfig: private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); There’s a lot of this code in Dubbo. This is also a factory pattern, except that the implementation class is retrieved using the JDK SPI mechanism. The advantage of this implementation is that it is extensible, and to extend the implementation, you can simply add a file to the classpath, with zero code intrusion. In addition, Adaptive implementation, like the one above, can dynamically decide which implementation to call when calling, but because this implementation uses dynamic proxy, it will cause trouble in code debugging, and the implementation class actually called needs to be analyzed.

Decorator pattern Dubbo makes heavy use of decorator pattern in both startup and invocation phases. In the case of a Provider, this is done in the ProtocolFilterWrapper buildInvokerChain, which implements a Filter that has group= Provider in its annotations. In order, the last call order is: EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter -> ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter -> ExceptionFilter