De 0 a 10,000 palabras, explicaremos la evolución de la arquitectura única a la arquitectura distribuida íntimamente (Parte 1)

De hecho, la vida no se trata solo de ajetreo y bullicio, sino también de poesía y distancia. Por lo tanto, hoy revisaremos la historia y echaremos un vistazo a la evolución de la arquitectura del sistema; comprenderemos el presente, aprenderemos la arquitectura técnica más popular; miraremos hacia el futuro y nos esforzaremos por convertirnos en un excelente ingeniero de Java.

Hola a todos, permítanme presentarme primero.
Soy el código en el código. Pueden llamarme hermano código.
También soy el estudiante más común que se graduó de una licenciatura ordinaria. Creo que la mayoría de los programadores o aquellos que quieren trabajar en la industria de los programadores son familias comunes. Mi hijo, así que también confío en mis propios esfuerzos, desde graduarme en una empresa tradicional hasta cambiar de trabajo sin falta, y ahora trabajando en una empresa gigante en la industria de Internet, espero poder ayudar. usted a través de mi compartir.
Siga mi columna para aprender, lo que puede ahorrarle muchos costos de capacitación o tiempo para encontrar información en línea, ahorrar la mayor parte de sus costos de tiempo y hacerlo más rápido para convertirse en un cosechador de entrevistas y el mejor empleado del año.

He preparado 16 columnas técnicas para que todos los lleven a aprender juntos

"Combate de sistema distribuido de tráfico de mil millones de niveles"

"Serie de entrevistas imprescindibles sobre la fábrica de baterías"

"Charla Técnica"

"Zero Foundation te lleva a aprender la columna del tutorial de Java"

"Llevarte a aprender la columna springCloud"

"Llevarte a aprender la columna del código fuente de SpringCloud"

"Llevarte a aprender la columna del sistema distribuido"

"Llévate a aprender la columna nativa de la nube"

"Llevarte a aprender el código fuente de Springboot"

"Llévate a aprender los principios de netty y la columna práctica"

"Te llevará a conocer la columna de Elasticsearch"

"Llevarte a aprender la columna mysql"

"Llevarte a aprender la columna de principios de JVM"

"Llevarte a aprender la columna de principios de Redis"

"Llevarte a aprender la columna avanzada de Java"

"Llévate a aprender la columna de big data"

Si hay alguna tecnología que desea aprender, puede dejar un mensaje en el área de comentarios y progresar juntos

Muchos fanáticos respondieron que quieren aprender arquitectura de sistemas distribuidos.

A partir de este artículo, el hermano del código le enseñará a aprender los escenarios de aplicación y las soluciones en la arquitectura distribuida desde cero, y explicará desde los aspectos prácticos y teóricos.

Recuerda dar me gusta , marcar como favorito, seguir y progresar juntos

Si tiene alguna pregunta, puede enviarme un mensaje privado o dejar un mensaje en el área de comentarios.

0. Objetivos de aprendizaje

• Comprender la evolución de la arquitectura del sistema.
• Comprender la diferencia entre RPC y Http
• Domina el uso simple de HttpClient
• Conoce qué es SpringCloud
• Construir de forma independiente el centro de registro de Eureka
• Configuración independiente del equilibrio de carga de Robbin

1. Evolución de la arquitectura del sistema

Con el desarrollo de Internet, la escala de las aplicaciones de sitios web continúa expandiéndose. El aumento de la demanda ha traído presión técnica. La arquitectura del sistema también está en constante evolución, actualización e iteración. Desde una sola aplicación hasta la división vertical, los servicios distribuidos, SOA y la actual arquitectura de microservicios, así como el creciente Service Mesh liderado por Google. ¿Deberíamos llevar el barco de los microservicios a la distancia, o deberíamos conformarnos con una esquina?

1.1 Arquitectura centralizada

Cuando el tráfico del sitio web es 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 para afectar el desarrollo del proyecto.

Problemas existentes:

• Acoplamiento de código, difícil de desarrollar y mantener
• No se puede optimizar para diferentes módulos.
• No se puede escalar horizontalmente
• Baja tolerancia a fallas de un solo punto y baja concurrencia

1.2 División vertical

Cuando el número de visitas aumenta gradualmente, una sola aplicación no puede satisfacer la demanda. En este momento, para hacer frente a una mayor concurrencia y requisitos comerciales, dividimos el sistema de acuerdo con las funciones comerciales:

ventaja:

• La división del sistema permite compartir el tráfico y resuelve problemas de concurrencia
• Se puede optimizar para diferentes módulos.
• Conveniente expansión horizontal, equilibrio de carga y tolerancia a fallas mejorada

defecto:

• Los sistemas son independientes entre sí y habrá mucho trabajo de desarrollo repetitivo, lo que afecta la eficiencia del desarrollo.

1.3 Servicios Distribuidos

Cuando hay más y más aplicaciones verticales, la interacción entre aplicaciones es inevitable. El negocio central 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 demandas cambiantes del mercado. En este momento, la invocación distribuida para mejorar la reutilización y la integración comercial es la clave.

ventaja:

• Los servicios básicos se extraen y los sistemas se llaman entre sí, lo que mejora la reutilización del código y la eficiencia del desarrollo.

defecto:

• El grado de acoplamiento entre los sistemas se vuelve alto y la relación de llamada es complicada y difícil de mantener.

1.4 Gobernanza del servicio (SOA)

SOA: Arquitectura Orientada a Servicios

Cuando hay más y más servicios, surgen gradualmente problemas como la evaluación de la capacidad y el desperdicio de recursos de servicios pequeños, 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 y mejorar la tasa de utilización del clúster. En este punto, un Centro de Gobierno y Programación de Recursos (SOA) para mejorar la utilización de la máquina es clave

¿Qué salió mal antes?

• Cada vez más servicios, necesidad de gestionar la dirección de cada servicio
• La relación de llamadas es complicada y es difícil resolver las dependencias.
• Hay demasiados servicios, el estado del servicio es difícil de administrar y no se puede administrar dinámicamente de acuerdo con la situación del servicio.

¿Qué hace la gobernanza del servicio?

• Centro de registro de servicios, para realizar el registro automático y el descubrimiento de servicios, sin necesidad de registrar manualmente las direcciones de servicio
• Suscripción automática de servicios, envío automático de listas de servicios, llamadas de servicio transparentes, sin necesidad de preocuparse por las dependencias
• Informe de seguimiento del estado del servicio de monitoreo dinámico, control manual del estado del servicio

defecto:

• Habrá dependencias entre servicios, y una vez que un enlace falla, tendrá un mayor impacto
• La relación de servicio es compleja, la operación y el mantenimiento, las pruebas y la implementación son difíciles, lo que no está en línea con la idea de DevOps.

1.5 Microservicios

La SOA mencionada anteriormente, la traducción al inglés está orientada a servicios. Los microservicios, que parecen ser servicios, tienen que ver con dividir el sistema. Por lo tanto, es muy fácil confundir los dos, pero de hecho hay algunas diferencias:

Características de los Microservicios:

• Responsabilidad única: cada servicio en el microservicio corresponde a una capacidad comercial única, logrando una responsabilidad única
• Micro: la granularidad de división de servicios de los microservicios es muy pequeña, por ejemplo, una gestión de usuarios se puede utilizar como un servicio. Cada servicio es pequeño, pero "completo con todos los órganos internos".
• Orientado a servicios: Orientado a servicios significa que cada servicio debe exponer la API de interfaz de servicio de estilo Rest. No le importa la implementación técnica del servicio, no tiene nada que ver con la plataforma y el idioma, y ​​no limita qué tecnología se usa para la implementación, siempre que se proporcione la interfaz de Rest.
• Autonomía: Autonomía significa que los servicios son independientes entre sí y no interfieren entre sí.
  • Independencia del equipo: cada servicio es un equipo de desarrollo independiente y el número no puede ser demasiado grande.
  • Independencia de la tecnología: debido a que está orientada al servicio, proporciona una interfaz Rest y nadie interfiere con la tecnología que se debe usar
  • Separación de front-end y back-end: el front-end y el back-end están separados y desarrollados para proporcionar una interfaz Rest unificada, y el back-end ya no necesita desarrollar diferentes interfaces para los segmentos de PC y móviles.
  • Separación de bases de datos: cada servicio utiliza su propia fuente de datos
  • El despliegue es independiente, aunque hay llamadas entre servicios, el reinicio del servicio no afecta a otros servicios. Bueno para la integración continua y la entrega continua. Cada servicio es un componente independiente, reutilizable, reemplazable, de acoplamiento reductor y de fácil mantenimiento

Diagrama de estructura de microservicio:

2. Método de llamada remota

Tanto los microservicios como SOA se enfrentan a llamadas remotas entre servicios. Entonces, ¿cuáles son los métodos de llamada remota entre servicios?

Los métodos comunes de llamada remota son los siguientes:

• RPC: llamada de procedimiento remoto Remote Produce Call, similar a RMI. Formato de datos personalizado, basado en comunicación TCP nativa, rápido y eficiente. El primer servicio web y el ahora popular dubbo son típicos de RPC

• Http: http es en realidad un protocolo de transmisión de red, basado en TCP, que especifica el formato de transmisión de datos. En la actualidad, la comunicación entre el navegador del cliente y el servidor adopta básicamente el protocolo Http. También se puede utilizar para realizar llamadas de servicio remoto. La desventaja es que la encapsulación del mensaje está inflada.

  Ahora el popular estilo Rest se puede implementar a través del protocolo http.

2.1 Comprender RPC

RPC, o llamada de procedimiento remoto, es un protocolo de comunicación de computadora. El protocolo permite que un programa que se ejecuta en una computadora llame a una subrutina en otra computadora sin que el programador tenga que programar adicionalmente esta interacción. En pocas palabras, la computadora A proporciona un servicio y la computadora B puede llamar al servicio de la computadora A como si llamara a un servicio local.

A través de los conceptos anteriores, podemos saber que la implementación de RPC logra principalmente dos cosas:

• Implementar llamadas remotas a los servicios de otras computadoras
  • Para lograr una llamada remota, debe ser para transmitir datos a través de la red. El programa A proporciona servicios, el programa B pasa los parámetros de solicitud a A a través de la red y A obtiene el resultado después de la ejecución local y luego devuelve el resultado al programa B. Hay dos cosas a las que prestar atención aquí:
    • 1) ¿Qué tipo de protocolo de comunicación de red se utiliza?
      • Los marcos RPC más populares ahora usan TCP como protocolo de transporte subyacente
    • 2) ¿Cuál es el formato de transmisión de datos?
      • Para que dos programas se comuniquen, se debe acordar el formato de transmisión de datos. Al igual que dos personas que chatean, deben usar el mismo idioma, de lo contrario no podrán comunicarse. Por lo tanto, debemos definir el formato de la solicitud y la respuesta. Además, la transmisión de datos en la red debe serializarse, por lo que también es necesario acordar un método de serialización unificado.
• Invocar un servicio remoto como si fuera un servicio local
  • Si es solo una llamada remota, no se considera RPC, porque RPC enfatiza las llamadas de procedimiento y el proceso de llamada debe ser transparente para los usuarios. Los usuarios no deben preocuparse por los detalles de la llamada y pueden llamar a servicios remotos como si llamaran locales. servicios. Entonces RPC debe encapsular el proceso de llamada

Diagrama de flujo de llamadas RPC:

Si quieres conocer la implementación detallada de RPC, te recomiendo un artículo: Hágalo usted mismo RPC

2.2 Conocer Http

Protocolo Http: Protocolo de transferencia de hipertexto, es un protocolo de capa de aplicación. Especifica el formato de solicitud, el formato de respuesta, la ubicación de recursos y el modo de operación de la transmisión de red. Sin embargo, no existe una regulación sobre qué protocolo de transmisión de red se usa en la capa inferior, pero ahora el protocolo TCP se usa como protocolo de transmisión de la capa inferior. En este punto, usted puede pensar que las llamadas remotas de Http y RPC son muy similares, ambos realizan la comunicación de red de acuerdo con un cierto formato de datos prescrito, con solicitudes y respuestas. Sí, en este punto, los dos son muy similares, pero hay algunas diferencias sutiles.

• RPC no especifica un formato de transmisión de datos. Este formato se puede especificar arbitrariamente. Los diferentes protocolos RPC tienen diferentes formatos de datos.
• Http también define la ruta de ubicación de recursos, que no se requiere en RPC
• El punto más importante: RPC debe poder llamar a servicios remotos como llamar a servicios locales, es decir, encapsular el proceso de llamada en el nivel de API. El protocolo Http no tiene tales requisitos, por lo que los detalles de las solicitudes y respuestas deben ser implementados por nosotros mismos.
  • Ventajas: El método RPC es más transparente y más conveniente para los usuarios. El método Http es más flexible, no hay una API ni un idioma específicos, es multilenguaje y multiplataforma
  • Desventajas: el método RPC debe encapsularse en el nivel de la API, lo que limita el entorno del lenguaje para el desarrollo.

Por ejemplo, cuando accedemos a una web a través de un navegador, es a través del protocolo Http. Es solo que el navegador encapsula la solicitud, inicia la solicitud, recibe la respuesta y analiza la respuesta por nosotros. Si no es a través del navegador, estas cosas debe hacerlas usted mismo.

2.3 ¿Cómo elegir?

Dado que ambos métodos pueden implementar llamadas remotas, ¿cómo debemos elegir?

• En términos de velocidad, RPC es más rápido que http. Aunque la capa inferior es TCP, la información del protocolo http a menudo está inflada, pero se puede comprimir con gzip.
• En términos de dificultad, RPC es más complicado de implementar, mientras que http es relativamente simple.
• En términos de flexibilidad, http es mejor porque no se preocupa por los detalles de implementación, multiplataforma y multilenguaje.

Entonces ambos tienen diferentes escenarios de uso:

• Si los requisitos de eficiencia son más altos y el proceso de desarrollo utiliza una pila de tecnología unificada, el uso de RPC sigue siendo bueno.
• Si necesita ser más flexible, multilenguaje, multiplataforma, obviamente http es más adecuado

Entonces, ¿cómo elegimos?

Los microservicios enfatizan la independencia, la autonomía y la flexibilidad. El método RPC tiene muchas restricciones, por lo que en el marco de microservicios, generalmente se utilizan servicios de estilo Rest basados ​​en Http.