Cómo construir un sistema distribuido usando Java
La evolución de la arquitectura distribuida
La evolución de la arquitectura del sistema: arquitectura de la etapa inicial
En la etapa inicial, todos los recursos, como pequeñas aplicaciones del sistema, bases de datos, y los archivos se conocen comúnmente como LAMP en un servidor
Características:
Todos los recursos como aplicaciones, bases de datos, archivos, etc. están en un servidor.
Descripción:
Por lo general, el sistema operativo del servidor usa Linux, la aplicación se desarrolla usando PHP y luego se implementa en Apache, y la base de datos usa MySQL, que reúne varios códigos abiertos gratuitos. software y un servidor barato Puede comenzar el desarrollo del sistema.
La evolución de la arquitectura del sistema: separación de servicios de aplicaciones y servicios de datos
Los buenos tiempos no duraron mucho. Se descubrió que a medida que el número de visitas al sistema aumentaba nuevamente, la presión. en la máquina del servidor web aumentaría a un nivel relativamente alto durante los períodos pico Alto, en este momento, comencé a considerar agregar un servidor web
Características:
Aplicaciones, bases de datos y archivos. se implementan en recursos independientes.
Descripción:
La cantidad de datos aumenta, el rendimiento y el espacio de almacenamiento de un solo servidor son insuficientes y las aplicaciones y los datos deben separarse de las capacidades de procesamiento simultáneo y del espacio de almacenamiento de datos. han mejorado mucho.
La evolución de la arquitectura del sistema: uso de caché para mejorar el rendimiento
Características:
Una pequeña parte de los datos a los que se accede de forma más intensiva se almacena en la base de datos. en el servidor de caché, reduciendo la base de datos El número de accesos reduce la presión de acceso a la base de datos.
Descripción:
Las características de acceso al sistema siguen la regla 80/20, es decir, el 80% del acceso empresarial se concentra en el 20% de los datos.
La caché se divide en caché local y caché distribuida remota. La caché local tiene una velocidad de acceso más rápida pero la cantidad de datos almacenados en caché es limitada. Al mismo tiempo, puede competir con la aplicación por la memoria.
La evolución de la arquitectura del sistema: uso de clústeres de servidores de aplicaciones
Después de completar las tareas de subbase de datos y subbase de datos de tablas, la presión sobre la base de datos ha caído a un nivel relativamente bajo. Y comencé a vivir mi vida diaria nuevamente. Estaba viviendo una vida feliz con el número de visitas aumentando. De repente, un día, descubrí que el acceso al sistema comenzó a disminuir nuevamente. En ese momento, lo comprobé por primera vez. Luego revisé el servidor web y descubrí que Apache estaba bloqueando muchas solicitudes. El servidor de aplicaciones también es relativamente rápido para cada solicitud. Parece que la cantidad de solicitudes es demasiado alta. esperar en la fila y la velocidad de respuesta se vuelve lenta
Características:
Múltiples servidores tienen carga equilibrada Al mismo tiempo, proporciona servicios al mundo exterior para resolver el problema del procesamiento Límite de energía y espacio de almacenamiento de un solo servidor.
Descripción:
El uso de clústeres es un método común para que los sistemas resuelvan problemas de alta concurrencia y datos masivos. Al agregar recursos al clúster, se mejoran las capacidades de procesamiento concurrente del sistema, de modo que la presión de carga del servidor ya no se convierte en el cuello de botella de todo el sistema.
La evolución de la arquitectura del sistema: separación de lectura y escritura de la base de datos
Después de disfrutar del rápido crecimiento de las visitas al sistema durante un período de tiempo, descubrí que el sistema comenzó a ralentizarse nuevamente. ¿Qué pasó esta vez? En cuanto a la situación, después de la búsqueda, se descubrió que la competencia de recursos por algunas conexiones de bases de datos en estas operaciones de escritura y actualización de bases de datos es muy feroz, lo que hace que el sistema se ralentice.
Características :
Paso de varios servidores El equilibrio de carga proporciona servicios al exterior al mismo tiempo, resolviendo el problema de la potencia de procesamiento y el límite de espacio de almacenamiento de un solo servidor.
Descripción:
El uso de clústeres es un método común para que los sistemas resuelvan problemas de alta concurrencia y datos masivos. Al agregar recursos al clúster, la presión de carga del servidor ya no se convierte en el cuello de botella de todo el sistema.
Evolución de la arquitectura del sistema: proxy inverso y aceleración de CDN
Características:
Utilice CDN y proxy inverso para acelerar el acceso al sistema.
Descripción:
Para hacer frente al complejo entorno de red y al acceso de usuarios en diferentes regiones, se utilizan CDN y proxy inverso para acelerar el acceso de los usuarios y al mismo tiempo reducir la presión de carga en el servidor de fondo.
Los principios básicos de CDN y proxy inverso son el almacenamiento en caché.
Evolución de la arquitectura del sistema: sistema de archivos distribuido y base de datos distribuida
A medida que el sistema continúa ejecutándose, la cantidad de datos comienza a aumentar significativamente. En este momento, se descubre que después del. La base de datos está dividida, la consulta aún fue un poco lenta, así que comencé a trabajar en la partición de tablas de acuerdo con la idea de particionar bases de datos
Características:
La base de datos utiliza una base de datos distribuida, y el sistema de archivos utiliza un sistema de archivos distribuido.
Descripción:
Ningún servidor único potente puede satisfacer las necesidades comerciales en continuo crecimiento de los sistemas a gran escala. Con el desarrollo de los negocios, la separación de la lectura y escritura de la base de datos eventualmente será imposible. Para satisfacer las necesidades, es necesario utilizar una base de datos distribuida y un sistema de archivos distribuido para respaldar.
La base de datos distribuida es el último método para dividir la base de datos del sistema. Solo se usa cuando la escala de datos de una sola tabla es muy grande. El método de división de la base de datos más comúnmente utilizado es la subbase de datos empresarial, que implementa diferentes negocios. bases de datos en un servidor físico diferente.
La evolución de la arquitectura del sistema: utilizando NoSQL y motores de búsqueda
Características:
El sistema introduce bases de datos NoSQL y motores de búsqueda.
Descripción:
A medida que las empresas se vuelven cada vez más complejas, los requisitos de almacenamiento y recuperación de datos se vuelven cada vez más complejos. El sistema necesita utilizar algunas bases de datos no relacionales como NoSQL. y subbases de datos. Tecnologías de consulta como motores de búsqueda. El servidor de aplicaciones accede a varios datos a través de un módulo de acceso a datos unificado, lo que reduce los problemas de las aplicaciones que administran muchas fuentes de datos.
La evolución de la arquitectura del sistema: división de negocios
Características:
El sistema se divide y transforma según el negocio, y los servidores de aplicaciones se implementan por separado según el negocio. diferenciación.
Descripción:
Para hacer frente a escenarios comerciales cada vez más complejos, generalmente se utilizan métodos de dividir y conquistar para dividir todo el negocio del sistema en diferentes líneas de productos, y las relaciones entre aplicaciones pueden ser La distribución de datos se establece a través de hipervínculos y, por supuesto, lo que es más importante, se forma un sistema relacionado y completo accediendo al mismo sistema de almacenamiento de datos.
División vertical:
Divida una aplicación grande en varias aplicaciones pequeñas. Si el nuevo negocio es relativamente independiente, diséñelo e impleméntelo directamente como un sistema de aplicación web independiente.
La división vertical es relativamente sencilla. Simplemente clasifique el negocio y deshaga los negocios menos relevantes.
División horizontal: divida los negocios reutilizados e impleméntelos de forma independiente como servicios distribuidos. Los nuevos negocios solo necesitan llamar a estos servicios distribuidos.
La división horizontal requiere la identificación de servicios reutilizables y servicios de diseño. interfaces y estandarizar las dependencias de servicios.
Evolución de la arquitectura del sistema: servicios distribuidos
Características:
Los módulos de aplicaciones públicas se extraen y se implementan en servidores distribuidos para la llamada al servidor de aplicaciones.
Descripción:
A medida que las empresas se vuelven cada vez más pequeñas, la complejidad general del sistema de aplicaciones aumenta exponencialmente. Dado que todas las aplicaciones deben estar conectadas a todos los sistemas de bases de datos, esto eventualmente resulta en una insuficiencia. recursos de conexión a bases de datos, Denegación de Servicio.
P: ¿A qué problemas se enfrentarán las aplicaciones de servicios distribuidos?
R:
(1) Cuando hay cada vez más servicios, la gestión de la configuración de la URL del servicio se vuelve muy difícil y la presión de un solo punto sobre el equilibrador de carga de hardware F5 también está aumentando. .
(2) A medida que se desarrolla, las dependencias entre servicios se vuelven tan complejas que ni siquiera está claro qué aplicación debe iniciarse antes de qué aplicación, y el arquitecto no puede describir completamente la relación arquitectónica de la aplicación.
(3) Luego, a medida que aumenta el número de llamadas al servicio, queda expuesto el problema de capacidad del servicio. ¿Cuántas máquinas necesita soportar este servicio? ¿Cuándo debo agregar una máquina?
(4) Con más servicios, los costos de comunicación han comenzado a aumentar. ¿A quién debo contactar si falla el ajuste de un determinado servicio? ¿Cuáles son las convenciones para los parámetros de servicio?
(5) Si un servicio tiene múltiples consumidores comerciales, ¿cómo garantizar la calidad del servicio?
(6) A medida que los servicios continúan actualizándose, siempre suceden cosas inesperadas, por ejemplo, el caché se escribe incorrectamente, lo que provoca un desbordamiento de la memoria. Cada vez que falla un servicio principal, esto afecta. Área grande. La gente está en pánico, ¿cómo controlar el impacto de la falla? ¿Se pueden degradar funcionalmente los servicios? ¿O la degradación de los recursos?
Conceptos básicos de la tecnología de aplicaciones distribuidas de Java
Tecnología clave en servicios distribuidos: arquitectura de cola de mensajes
La cola de mensajes descompone el acoplamiento del sistema a través de objetos de mensaje, diferentes subsistemas procesan lo mismo mensaje
Tecnología clave bajo servicio distribuido: principio de cola de mensajes
Tecnología clave bajo servicio distribuido: arquitectura del marco de servicio
Servicio El marco descompone el acoplamiento del sistema a través de interfaces y diferentes subsistemas habilitan servicios a través de la misma descripción de interfaz
El marco de servicio es un modelo punto a punto
El marco de servicio está orientado a sistemas isomórficos
Adecuado para: aplicaciones móviles, aplicaciones de Internet, sistemas externos
Tecnologías clave bajo servicios distribuidos: Principio del marco de servicio
Tecnologías clave bajo servicios distribuidos: Arquitectura de bus de servicio
p>El bus de servicios, al igual que el marco de servicios, descompone el acoplamiento del sistema a través de interfaces. Diferentes subsistemas habilitan servicios a través de la misma descripción de interfaz
El bus de servicios es un modelo de tipo bus
El bus de servicios está orientado a. sistemas homogéneos y heterogéneos
Adecuado para: sistemas internos
Tecnologías clave bajo servicios distribuidos: principio de bus de servicio
Distribución 5 modos de comunicación para la interacción entre sistemas bajo el sistema tradicional arquitectura
modo de solicitud/respuesta (modo sincrónico): el cliente inicia una solicitud y se bloquea hasta que el servidor devuelve la solicitud.
Devolución de llamada (modo asíncrono): el cliente envía una solicitud RPC al servidor, y el servidor la procesa y luego envía un mensaje al punto final de devolución de llamada proporcionado por el remitente del mensaje. Este tipo de situación es muy adecuada. para los siguientes escenarios: Un componente envía La solicitud RPC se envía a B. Una vez que B completa el procesamiento, debe notificar al componente A para el procesamiento posterior.
Modo futuro: después de que el cliente envía la solicitud, continúa haciendo lo suyo y devuelve un objeto futuro que contiene el resultado del mensaje. Cuando el cliente necesite usar el resultado devuelto, use .get() del objeto Future. Si no se devuelve ningún resultado en este momento, se bloqueará hasta que se devuelva un resultado.
Modo unidireccional: el cliente continúa la ejecución después de la llamada, independientemente de si el extremo receptor tiene éxito.
Modo confiable: para garantizar una comunicación confiable, se utilizará el centro de mensajes para lograr una entrega confiable de mensajes. La solicitud se almacenará de manera persistente y se entregará cuando el receptor esté en línea, y el centro de mensajes lo garantizará. excepciones. Inténtelo de nuevo.
La implementación de cinco modos de comunicación: modo de servicio punto a punto síncrono
La implementación de cinco modos de comunicación: modo de mensaje punto a punto asíncrono 1
Método de implementación de cinco modos de comunicación: modo de mensaje asincrónico punto a punto 2
Método de implementación de cinco modos de comunicación: modo de mensaje de transmisión asincrónico
Gobierno del servicio bajo arquitectura distribuida
La gobernanza del servicio es una función central del marco de servicio/bus de servicio. La llamada gobernanza de servicios se refiere al acuerdo alcanzado entre proveedores y consumidores de servicios para garantizar la alta calidad de los servicios. La función de gobernanza del servicio puede resolver el problema de introducir cierto tráfico específico en un determinado lote de máquinas, restringir el acceso malicioso por parte de ciertos consumidores ilegales y negarse a aceptar nuevos accesos cuando el volumen de procesamiento del proveedor alcanza un cierto nivel.
Gobierno de servicios-gestión de servicios basada en el marco de servicios Dubbo
Puede saber cuántos servicios proporciona su sistema al mundo exterior y puede actualizarlos, degradarlos, desactivarlos y ponderarlos. ajustar los servicios, etc. Operación
Puedes saber quién está utilizando el servicio que brindas. Debido a las necesidades del negocio, puedes bloquear, desactivar y otras operaciones en el consumidor.
Gobierno del servicio. basado en el marco de servicio Dubbo-El monitoreo del servicio
puede contar el número de solicitudes por segundo, el tiempo de respuesta promedio, el volumen de llamadas, el tiempo pico, etc. del servicio como indicador de referencia para la planificación y el rendimiento del clúster de servicios. sintonización.
Gobierno de servicios-enrutamiento de servicios basado en el marco de servicios Dubbo
Gobierno de servicios-protección de servicios basado en el marco de servicios Dubbo
Gobierno de servicios-función basada en OSB del bus de servicios Introducción
Gobierno de servicios basado en OSB de bus de servicio
P: ¿Cómo es Dubbo?
R:
Marco de servicio de llamadas remotas RPC transparente, de alto rendimiento y de código abierto de Taobao
Solución de gobernanza de servicios SOA
P: ¿Qué Cuál es el principio de Dubbo?
A:
-Fin-