I. Introducción
Esta serie es una nota de estudio personal de Dubbo, el contenido proviene de "Análisis en profundidad de información privilegiada sobre la tecnología central de Apache Dubbo", solo para la grabación de notas personales. El análisis de este artículo se basa en la versión Dubbo 2.7.0. Debido a las limitaciones de comprensión personal, si hay un error en el artículo, gracias por su corrección.
Este artículo es puramente teórico y el contenido proviene de "Análisis en profundidad de Apache Dubbo Core Technology Insider". El propósito de este artículo es ser el comienzo de una serie de artículos de seguimiento.
Dos, una descripción general de la arquitectura en capas.
- Capa de servicio y configuración : capa de interfaz API para permitir que los usuarios de Dubbo publiquen fácilmente servicios y servicios de referencia; para los proveedores de servicios, es necesario implementar interfaces de servicio y luego usar la API ServiceConfig para publicar el servicio; para los consumidores de servicios, es necesario usar ReferenceConfig para proxy la interfaz de servicio. Las partes de publicación y referencia del servicio Dubbo pueden inicializar directamente la clase de configuración o generar automáticamente la clase de configuración a través de la configuración Spring.
- Las otras capas son todas las capas SPI (Service Provider Interface). SPI significa que las siguientes capas están todas en componentes y pueden ser reemplazadas. Este es uno de los mejores diseños de Dubbo. Dubbo mejora las funciones estándar de SPI proporcionadas en el JDK. En Dubbo, excepto las capas de Servicio y Configuración, todas las demás capas brindan servicios mediante la implementación de interfaces de puntos de extensión; la SPI mejorada de Dubbo agrega soporte para puntos de extensión IoC y AOP. Un punto de extensión puede directamente use el método setter () para inyectar otros puntos de extensión, y no instanciará todas las clases de implementación del punto de extensión a la vez, lo que evita la inicialización de la clase de implementación del punto de extensión, que consume mucho tiempo, pero aún no se ha utilizado La función de carga y creación de instancias sigue siendo un desperdicio de recursos; el SPI mejorado es para instanciar una clase de implementación específica cuando se usa una clase de implementación específica. El principio de implementación del SPI mejorado de Dubbo se explicará en detalle más adelante.
-
Capa de proxy de servicio de proxy : esta capa es principalmente para proxy de la interfaz utilizada por el consumidor del servicio y convertir de forma transparente las llamadas locales en llamadas remotas; además, proxy de las clases de implementación del servicio del proveedor de servicios y convertir las clases de implementación del servicio en clases Wrapper. Esto es para reducir la llamada a la reflexión, que se explicará en detalle más adelante. La interfaz de extensión SPI de la capa Proxy es ProxyFactory. Las clases de implementación proporcionadas por Dubbo incluyen principalmente JavassistProxyFactory (usado por defecto) y JdkProxyFactory. Los usuarios pueden implementar la interfaz ProxyFactory SPI y personalizar la implementación de la capa de servicio proxy.
-
Nivel de registro del servicio de registro : cuando el proveedor de servicios se inicia, registrará el servicio en el registro de servicios, y cuando el consumidor inicie, irá al registro de servicios para obtener la lista de direcciones del proveedor de servicios. La función principal del Registro La capa es encapsular la lógica de registro y descubrimiento de la dirección del servicio, Las extensiones correspondientes a la interfaz de extensión Registry se implementan como ZookeeperRegistry, RedisRegistry, MulticastRegistry, DubboRegistry, etc. Interfaz extendida RegistryFactory La interfaz extendida correspondiente se implementa como DubboRegistryFactory, DubboRegistryFactory, RedisRegistryFactory, ZookeeperRegistryFactory. Además, las clases de implementación del directorio de interfaz extendida de esta capa incluyen RegistryDirectory y StaticDirectory, que se utilizan para convertir de forma transparente la lista de Invocador en un Invoker; los usuarios pueden implementar una serie de interfaces extendidas de esta capa y personalizar la implementación del servicio de esta capa.
-
Capa de enrutamiento de clúster : encapsula la implementación de reglas de enrutamiento, equilibrio de carga, tolerancia a fallas de clúster de múltiples proveedores de servicios y une el registro de servicios; las clases de implementación correspondientes al Clúster de interfaz extendida incluyen FailoverCluster (reintento de falla), FailbackCluster (recuperación automática de falla) , FailfastCluster (fallo rápido), FailsafeCluster (seguridad ante fallos), ForkingCluster (llamada paralela), etc.; Las clases de implementación correspondientes a la interfaz de extensión de equilibrio de carga LoadBalance son RandomLoadBalance (aleatorio), RoundRobinLoadBalance (polling), LeastActiveLoadBalance (número mínimo activo) , ConsistentHashLoadBalance (consistente) Sex Hash) y así sucesivamente. Los usuarios pueden implementar una serie de interfaces extendidas en esta capa y personalizar la tolerancia a fallas del clúster y las estrategias de equilibrio de carga.
-
Capa de monitoreo de monitoreo : se utiliza para contar el número de llamadas RPC y las llamadas que consumen mucho tiempo, la interfaz de extensión es MonitorFactory y la clase de implementación correspondiente es DubboMonitorFactroy. Los usuarios pueden implementar la interfaz de extensión MonitorFactory de esta capa e implementar estrategias de estadísticas de monitoreo personalizadas.
-
Capa de llamada remota de protocolo : encapsula la lógica de llamada RPC, la interfaz extendida es Protocolo y las implementaciones correspondientes incluyen RegistryProtocol, DubboProtocol, InjvmProtocol, etc.
-
Capa de intercambio de información de intercambio : encapsula el modo de respuesta de solicitud, síncrono a asíncrono, la interfaz de extensión es Exchanger y las implementaciones de extensión correspondientes incluyen HeaderExchanger, etc.
-
Capa de transporte de la red de transporte : Mina y Netty se abstraen como interfaces unificadas. La interfaz extendida es Channel, y las implementaciones correspondientes incluyen NettyChannel (predeterminado), MinaChannel, etc.; Las clases de implementación correspondientes a la interfaz extendida Transporter son GrizzlyTransporter, MinaTransporter, NettyTransporter (implementación predeterminada); las clases de implementación correspondientes a la interfaz extendida Codec2 incluyen DubboCodec, ThriftCodec, etc.
-
Serializar la capa de serialización de datos : Proporciona algunas herramientas que se pueden reutilizar. La interfaz extendida es Serialización. Las implementaciones extendidas correspondientes incluyen DubboSerialization, FastJsonSerialization, Hessian2Serialization, JavaSerialization, etc., y las implementaciones extendidas correspondientes de la interfaz extendida ThreadPool incluyen FixedThreadPool, CachedThreadPool, LimitedThreadPool, etc.
Tres, descripción general de llamadas remotas
1. Descripción general de la exposición del proveedor de servicios
- Ref -> Invoker: La clase ServiceConfig hace referencia a la clase de implementación ref (como GreetingServiceImpl) que proporciona servicios externos, y luego usa la ref para generar una instancia de AbstractProxyInvoker a través del método ProxyFactory # getInvoker. En este paso, la conversión del servicio específico al Invocador se completa. .
- Invoker -> Exportar: La conversión del protocolo Dubbo Invoker a Exporter ocurre en el método de exportación Protocol #. La clave para la exposición del servicio de manejo de Dubbo está en el proceso de convertir Invoker a Exporter. En este proceso, Netty Server se iniciará para monitorear el conexión de servicio y, a continuación, registre el servicio en el registro de servicios.
2. Panorama general de los servicios de consumo de los consumidores
- ReferenceConfig Primero, el método ReferenceConfig # init llama al método de referencia Protocol # para generar una instancia de Invoker, que es la clave para el consumo del servicio. A continuación, convierta el Invoker a la interfaz requerida por el cliente (como GreetingService).
- El Invoker del protocolo Dubbo se convierte a la interfaz requerida por el cliente, lo que ocurre en el método getProxy de la clase de implementación extendida de la interfaz ProxyFactory. Utiliza principalmente el proxy para convertir la llamada a la interfaz de servicio a la llamada a la Invocador.
Arriba: Para el contenido, consulte
"Análisis en profundidad de Apache Dubbo Core Technology Insider".
Si hay alguna intrusión, comuníquese con ella y elimínela. El contenido solo se utiliza para la autograbación y el aprendizaje. Si hay algún error, corrígeme