Tabla de contenido
Configuración de Spring del servicio local
Configuración de Spring de servicio remoto
Dirección oficial: https://dubbo.apache.org/zh/
Dubbo admite la configuración SpringXML y la configuración del cliente. El registro es compatible con Zookeeper y Redis. El registro predeterminado es Zookeeper. La última versión es 2.7 y 3.0 está en desarrollo.
antecedentes
Este artículo presenta la evolución de las aplicaciones de sitios web.
Con el desarrollo de Internet, la escala de las aplicaciones de sitios web continúa expandiéndose y las arquitecturas de aplicaciones verticales convencionales ya no pueden hacer frente a ella. La arquitectura de servicios distribuidos y la arquitectura de computación móvil son imperativas, y se necesita con urgencia un sistema de gobernanza para garantizar una evolución ordenada de la arquitectura.
Arquitectura de aplicación única
Cuando el tráfico del sitio web es muy pequeño, solo se necesita una aplicación y todas las funciones se implementan juntas para reducir los nodos y los costos de implementación. En este momento, el marco de acceso a datos (ORM) utilizado para simplificar la carga de trabajo de agregar, eliminar, modificar y verificar es la clave.
Arquitectura de aplicación vertical
Cuando el número de visitas aumenta gradualmente, la aceleración causada por la adición de una sola aplicación a la máquina se vuelve cada vez más pequeña Una de las formas de mejorar la eficiencia es dividir la aplicación en varias aplicaciones no relacionadas para mejorar la eficiencia. En este momento, el marco web (MVC) que se utiliza para acelerar el desarrollo de las páginas frontales es la clave.
Arquitectura de servicios distribuidos
Cuando hay más y más aplicaciones verticales, la interacción entre aplicaciones es inevitable. El negocio principal se extrae como un servicio independiente y se forma gradualmente un centro de servicio estable, de modo que las aplicaciones front-end puedan responder más rápidamente a las cambiantes demandas del mercado. En este momento, el marco de servicio distribuido (RPC) para mejorar la integración y la reutilización empresarial es la clave.
Arquitectura informática móvil
Cuando hay más y más servicios, aparecen gradualmente problemas como la evaluación de la capacidad y el desperdicio de pequeños recursos del servicio. En este momento, es necesario agregar un centro de despacho para administrar la capacidad del clúster en tiempo real en función de la presión de acceso para mejorar la utilización del clúster. En este momento, el centro de programación y gobernanza de recursos (SOA) utilizado para mejorar la utilización de la máquina es la clave.
demanda
Este artículo presenta las necesidades que Dubbo quiere resolver
Antes del servicio a gran escala, las aplicaciones pueden simplemente exponer y hacer referencia a servicios remotos a través de herramientas como RMI o Hessian, llamarlos configurando la dirección URL del servicio y realizar el equilibrio de carga a través de hardware como F5.
Cuando hay más y más servicios, la administración de la configuración de la URL del servicio se vuelve muy difícil y la presión de un solo punto del equilibrador de carga de hardware F5 también está aumentando. En este momento, se necesita un centro de registro de servicios para registrar y descubrir servicios dinámicamente para hacer que la ubicación de los servicios sea transparente. Y al obtener una lista de direcciones de proveedores de servicios del lado del consumidor, puede lograr un equilibrio de carga suave y una conmutación por error, reducir la dependencia de los equilibradores de carga de hardware F5 y también reducir parte del costo.
Cuando se desarrolla más, la dependencia entre servicios se vuelve errónea y complicada, e incluso no está claro qué aplicación debe iniciarse antes de qué aplicación.Los arquitectos no pueden describir completamente la relación arquitectónica de la aplicación. En este momento, es necesario dibujar automáticamente un gráfico de dependencia entre aplicaciones para ayudar al arquitecto a aclarar la relación.
Entonces, el número de llamadas al servicio aumenta cada vez más, y se expone el problema de la capacidad del servicio ¿Cuánto soporte de máquina necesita este servicio? ¿Cuándo se debe agregar la máquina? Para solucionar estos problemas, el primer paso es contar el volumen de llamadas diarias y el tiempo de respuesta del servicio como indicador de referencia para la planificación de la capacidad. En segundo lugar, es necesario ajustar dinámicamente el peso. En línea, aumentar el peso de una determinada máquina y registrar el cambio en el tiempo de respuesta durante el proceso de aumento, hasta que el tiempo de respuesta alcance el umbral, registrar la cantidad de visitas en este momento, y luego use esto Multiplique el número de visitas por el número de máquinas para revertir la capacidad total.
Los anteriores son los requisitos más básicos de Dubbo.
Arquitectura
Arquitectura Dubbo
Descripción del rol de nodo
| nodo | Descripción del rol |
|---|---|
Provider |
Proveedor de servicios que expone el servicio |
Consumer |
Servicio al consumidor que llama al servicio remoto |
Registry |
Registro para registro y descubrimiento de servicios |
Monitor |
Centro de monitoreo que cuenta el número de llamadas de servicio y el tiempo de la llamada. |
Container |
Servicio de contenedor en ejecución |
Descripción de la relación de llamadas
- El contenedor de servicios es responsable de iniciar, cargar y ejecutar el proveedor de servicios.
- Cuando el proveedor de servicios se inicia, registra el servicio que brinda en el centro de registro.
- Cuando se inicia un consumidor de servicios, se suscribe al registro del servicio que necesita.
- El centro de registro devuelve la lista de direcciones de proveedores de servicios al consumidor. Si hay un cambio, el centro de registro enviará los datos del cambio al consumidor en función de la conexión larga.
- Los consumidores de servicios, de la lista de direcciones de proveedores, según el algoritmo de equilibrio de carga suave, seleccionan un proveedor para llamar y, si la llamada falla, seleccionan otro para llamar.
- Los consumidores y proveedores de servicios acumulan la cantidad de llamadas y el tiempo de llamadas en la memoria y envían datos estadísticos al centro de monitoreo cada minuto.
La arquitectura Dubbo tiene las siguientes características: conectividad, robustez, escalabilidad y capacidad de actualización a la arquitectura futura.
Conectividad
- El centro de registro es responsable del registro y la búsqueda de la dirección del servicio, que es equivalente a un servicio de directorio. Los proveedores de servicios y los consumidores solo interactúan con el centro de registro al inicio, y el centro de registro no reenvía solicitudes, por lo que la presión es menor.
- El centro de monitoreo es responsable de contar el número de veces que se llama a cada servicio, el tiempo de llamada, etc. Las estadísticas se recopilan primero en la memoria y se envían al servidor del centro de monitoreo cada minuto, y se muestran en informes.
- El proveedor de servicios registra los servicios que brinda con el centro de registro e informa el tiempo de la llamada al centro de monitoreo. Este tiempo no incluye la sobrecarga de la red.
- El consumidor del servicio obtiene la lista de direcciones del proveedor de servicios del centro de registro, y llama directamente al proveedor de acuerdo con el algoritmo de carga, y al mismo tiempo informa el tiempo de la llamada al centro de monitoreo. Este tiempo incluye la sobrecarga de la red.
- El centro de registro, el proveedor de servicios y el consumidor de servicios son conexiones de larga duración, excepto el centro de monitoreo.
- El registro percibe la existencia del proveedor de servicios a través de la conexión larga, y el proveedor de servicios está inactivo, el registro presionará inmediatamente el evento para notificar al consumidor
- El centro de registro y el centro de monitoreo están caídos, lo que no afecta a los proveedores y consumidores que ya están funcionando. Los consumidores almacenan en caché la lista de proveedores localmente
- Tanto el centro de registro como el centro de monitoreo son opcionales, y los consumidores de servicios pueden conectarse directamente con el proveedor de servicios.
Robustez
- El tiempo de inactividad del centro de monitoreo no afectará el uso, pero se perderán algunos datos de muestreo.
- Una vez que la base de datos deja de funcionar, el registro aún puede proporcionar consultas de la lista de servicios a través de la memoria caché, pero no puede registrar nuevos servicios.
- Clúster peer-to-peer del centro de registro, después de que uno se caiga, cambiará automáticamente al otro
- Una vez que el registro está completamente inactivo, los proveedores de servicios y los consumidores de servicios aún pueden comunicarse a través de la memoria caché local.
- El proveedor de servicios es apátrida, después de que alguno esté inactivo, no afectará el uso
- Después de que todos los proveedores de servicios estén inactivos, las aplicaciones del consumidor de servicios no estarán disponibles y se volverán a conectar indefinidamente y esperarán a que el proveedor de servicios se recupere.
Escalabilidad
- El registro es un clúster de igual a igual, que puede agregar dinámicamente instancias de implementación de máquinas, y todos los clientes descubrirán automáticamente el nuevo registro.
- El proveedor de servicios no tiene estado y puede agregar dinámicamente instancias de implementación de máquinas, y el registro enviará la nueva información del proveedor de servicios a los consumidores.
Capacidad de actualización
Cuando la escala de los clústeres de servicios se amplía aún más y la estructura de gobierno de TI se actualiza aún más, se requiere un despliegue dinámico y computación móvil. La arquitectura de servicios distribuidos existente no traerá resistencia. La siguiente figura es una posible arquitectura en el futuro:
Descripción del rol de nodo
| nodo | Descripción del rol |
|---|---|
Deployer |
Agente local para servicios de implementación automática |
Repository |
El almacén se utiliza para almacenar paquetes de lanzamiento de aplicaciones de servicio. |
Scheduler |
El centro de despacho aumenta o disminuye automáticamente los proveedores de servicios en función de la presión de acceso. |
Admin |
Consola de administración unificada |
Registry |
Registro para registro y descubrimiento de servicios |
Monitor |
Centro de monitoreo que cuenta el número de llamadas de servicio y el tiempo de la llamada. |
uso
Una introducción sencilla y práctica a Dubbo
Configuración de Spring del servicio local
local.xml:
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>
Configuración de Spring de servicio remoto
Sobre la base del servicio local, solo necesita hacer una configuración simple para completar el remoto:
local.xmlDivida la configuración anterior en dos partes, coloque la parte de definición del servicio en el proveedor de serviciosremote-provider.xmly coloque la parte de referencia del servicio en el consumidor del servicioremote-consumer.xml.- Y aumente la configuración del servicio expuesto en el lado del proveedor
<dubbo:service>y aumente la configuración del servicio de referencia en el lado del consumidor<dubbo:reference>.
remote-provider.xml:
<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />
remote-consumer.xml:
<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>