Red de servicios y ampIsdio
Las empresas de Internet suelen utilizar una arquitectura en capas de microservicios.
Voz en off:
¿Por qué servir? Para obtener más información, consulte Problemas resueltos del servicio.
A medida que la cantidad de datos y el rendimiento aumentan y el negocio se vuelve más complejo, la cantidad de servicios aumentará y los niveles serán cada vez más detallados. Además de la capa de servicio de datos, también se derivarán varias estructuras jerárquicas, como la capa de servicio empresarial y la separación de front-end.
Voz en off:
Para obtener más información sobre las capas, consulte La evolución de la arquitectura por capas de Internet.
Descubra continuamente las principales contradicciones, aísle las principales contradicciones y resuelva las principales contradicciones. La arquitectura ha evolucionado naturalmente con la arquitectura de microservicios, ¿cuáles son las posibles contradicciones principales?
Al introducir una arquitectura de microservicio, generalmente se introduce un marco RPC para completar todo el proceso de llamada RPC.
Como se muestra en la parte rosa de arriba, RPC se divide en:
Voz en off:
Arquitectura de microservicio inseparable, detalles de RPC inseparables.
No solo microservicios, MQ también tiene una arquitectura similar:
Como se muestra en la parte rosa de la imagen de arriba, MQ se divide en:
Voz en off:
MQ, un artefacto del desacoplamiento de la arquitectura de Internet.
El marco es solo el primer paso y se agregarán cada vez más funciones relacionadas con RPC y microservicios.
Ejemplo: equilibrio de carga
Si desea escalar múltiples escenarios de equilibrio de carga, por ejemplo:
El cliente RPC debe actualizarse.
Por ejemplo: recopilación de datos
Si desea recopilar el tiempo de procesamiento de la interfaz RPC para lograr un monitoreo y alarmas unificados, también necesita actualizar el cliente RPC.
Voz en off, el tiempo de procesamiento se divide en:
Tiempo de procesamiento de la perspectiva del cliente
Tiempo de procesamiento de la perspectiva del servidor
Si desea recopilar el último, el servidor RPC también debe modificarse e informarse.
Otro ejemplo: descubrimiento de servicios
El servicio agrega una instancia y notifica al centro de configuración. El centro de configuración notifica al cliente RPC registrado para que envíe tráfico a la instancia de servicio recién iniciada, por lo tanto. Complete rápidamente la extensión.
Otro ejemplo: seguimiento de la cadena de llamadas
Si desea realizar un seguimiento completo de la cadena de llamadas de enlace, es necesario actualizar tanto el cliente RPC como el servidor RPC. Las siguientes funciones: equilibrio de carga, servicio de recopilación de datos, descubrimiento, seguimiento de la cadena de llamadas... en realidad no son funciones comerciales, por lo que las empresas de Internet generalmente tienen un departamento técnico similar al "departamento de arquitectura" para desarrollar y actualizar funciones relacionadas, mientras que el departamento técnico del línea de negocio directamente Utilice marcos, herramientas y plataformas relevantes para disfrutar de la conveniencia que brindan varias "tecnologías negras".
¡Perfecto! ! ! El ideal es completo, pero la realidad es muy escasa, porque:
A menudo nos enfrentamos a los siguientes problemas:
Voz en off:
Hermano, tu empresa necesita promover un producto de nueva tecnología ¿cuánto tiempo?
¿Hay alguna forma de resolver estos acoplamientos y estos puntos débiles comunes?
Una idea es dividir el servicio en dos procesos y desacoplarlos.
Voz en off:
Muchas infraestructuras, como equilibrio de carga, monitoreo y alarmas, descubrimiento y gobernanza de servicios, encadenamiento de llamadas, etc. , están todos implementados en esta capa.
De esta forma, "los negocios pertenecen a los negocios y la tecnología pertenece a la tecnología" para lograr un desacoplamiento completo. Si todos los nodos se desacoplan, toda la arquitectura evolucionará hacia:
Todo el clúster de servicios se convierte en una red, que es el origen de la red de servicios Service Mesh.
Cuando hablamos de ServiceMesh, tenemos que mencionar Istio, que actualmente es el método más popular de ServiceMesh. Hoy, hablemos de lo que hace Istio.
Voz en off: No puedes quedarte atrás.
¿Qué es Istio?
Istio es la implementación del producto ServiceMesh. Algunas descripciones clave son:
Voz en off:
Istio le ayuda a conectar, proteger, controlar y observar microservicios <. /p>
Voz en off:
Lo admiro, es difícil sumar diez. De hecho, SM puede proporcionar funciones de servicio más básicas.
Voz en off:
Sigo hablando de desacoplamiento.
¿Cómo se jacta de sí mismo el sitio web oficial de Istio?
Voz en off:
Otra forma de hacer esta pregunta es "¿Por qué usar Istio?".
Istio es increíble. Si quieres implementar ServiceMesh, debes usar Istio porque:
Voz en off:
¿Lo crees?
¿Cuáles son las características principales de Istio?
Istio destaca las cinco características clave que ofrece:
Voz en off:
Disyuntor, tiempo de espera, reintento, alta disponibilidad, múltiples reglas de enrutamiento, pruebas AB, escala de grises lanzamiento, distribución del porcentaje de tráfico, etc.
Los alardes y características de Istio son muy atractivos para muchas empresas extranjeras que brindan servicios de intranet a través de RESTful, pero en comparación con la arquitectura de microservicios nacional, es posible que no pueda lograr un buen efecto beneficioso para todos:
(1) Los marcos RPC nacionales son básicamente TCP, y el soporte multiprotocolo no es necesariamente necesario.
(2) En 2) marco RPC, enrutamiento, reintento, conmutación por error, equilibrio de carga y alta disponibilidad; son los más básicos;
(3) El control de tráfico, el límite de velocidad y la gestión de cuotas son los contenidos de la gobernanza del servicio, que son la guinda del pastel en la etapa inicial de la arquitectura de microservicios;
(4) La medición automática, la recopilación de datos de entrada y salida del sistema, el seguimiento de llamadas y el backend observable y controlable son realmente los más atractivos;
(5) Certificación de servicio a servicio. Los microservicios son básicamente acceso a intranet, que es solo la guinda del pastel en la etapa inicial de la arquitectura;
Otra nota al margen, ¿por qué el agente se llama agente complementario?
Istio es increíble, ¿cuál es su arquitectura principal?
En cuanto al diseño arquitectónico de Istio, el sitio web oficial utiliza esta frase:
Lógicamente, Istio se divide en:
Estas dos palabras son arquitectura de Istio El núcleo , pero también el lugar más engañoso.
El plano de datos y el plano de control no fueron propuestos por primera vez por ServiceMesh e Istio. Son conceptos maduros en redes informáticas y enrutamiento y reenvío de mensajes:
Voz en off: las dos imágenes de arriba muestran enrutadores. arquitectura.
Los principios de diseño son:
Voz en off:
La arquitectura central de Istio es muy similar a la de un enrutador:
( 1) Reenvío eficiente;
(2) Recibir y ejecutar políticas desde el mezclador
(1) Administrar y configurar agentes secundarios
(2) Implementar; políticas y pases El mezclador recopila datos del proxy sidecar;
Voz en off:
(1) proxy sidecar, el texto original usa enviado y el siguiente enviado significa agente;
(2)Mixer, no estoy seguro de cómo traducirlo. Algunos artículos se llaman "mezcladores", y estos últimos simplemente se llaman mezcladores;
(3) piloto, galera, ciudadela no se traducen como piloto, cocinas y fuertes. Las siguientes palabras están directamente en inglés;
Como se muestra en el diagrama de arquitectura, hay cinco componentes principales en la arquitectura de dos niveles.
La responsabilidad principal del enviado especial es el envío eficiente. Más concretamente, tiene las siguientes funciones:
(1) Descubrimiento de servicios
(2) Equilibrio de carga
(3) Transmisión segura
(4) Compatibilidad con múltiples protocolos, como HTTP/2 y gRPC.
(5)Disyuntor
(6)Comprobación de estado
(7)Porcentaje de enrutamiento de derivación
(8)Inyección de fallas
(9) Medición del sistema
La mayoría de las funciones están disponibles en el marco RPC o son relativamente fáciles de entender. Aquí presentamos principalmente disyuntores e inyección de fallas.
Es una idea de diseño de autoprotección o degradación del servicio en el diseño de la arquitectura de software.
Por ejemplo, cuando el sistema detecta una gran cantidad de tiempos de espera en una interfaz, una política de disyuntor puede finalizar las llamadas a esa interfaz (el disyuntor se abre) y, después de un período de tiempo, intentar la llamada. de nuevo. Si la interfaz ya no se agota, reanudará la llamada lentamente (el disyuntor está cerrado).
Es un método para introducir deliberadamente fallos en el diseño de la arquitectura del software para ampliar la cobertura de las pruebas y garantizar la solidez del sistema. Se utiliza principalmente para pruebas.
La mayoría de las empresas nacionales de Internet no consideran la inyección de fallas en el diseño arquitectónico, pero a menudo la usan en el desarrollo y depuración de núcleos y enrutadores del sistema operativo. Puede usarse para simular algunos problemas muy difíciles, como la asignación de memoria. fallas y errores de E/S del disco para garantizar la cobertura de la prueba.
Algunas de las capacidades principales de Mixer son:
(1) Multiplataforma, que sirve como adaptador para que otros componentes realicen las capacidades multiplataforma de Istio;
(2) Comuníquese con los enviados y aprenda varias estrategias en tiempo real.
(3) Comunicarse con el enviado especial y recopilar diversos datos.
El núcleo del diseño de Mixer son los "complementos", que permiten a Istio adaptarse a diversos entornos de host complejos e infraestructura de back-end.
Como componente muy importante del plano de control, las capacidades principales de Pilot son:
(1) Proporcionar capacidades de descubrimiento de servicios para Envoy.
(2) Proporcionar; Envoy con Proporcionar diversas capacidades de gestión de enrutamiento inteligente, como pruebas A/B y publicación en escala de grises;
(3) Proporcionar diversas capacidades de gestión flexibles para los enviados, como estrategias de tiempo de espera, reintento y desconexión;
p>
El núcleo del diseño de Pilot es la "estandarización", que convierte varios comandos de control de tráfico en configuraciones que los enviados pueden reconocer y propaga estos comandos a todos los enviados en tiempo de ejecución. La ventaja de que Pilot abstraiga estas funciones en una configuración común es que todos los Envoys que cumplan con este estándar pueden conectarse a Pilot.
El subtexto es que cualquier tercero puede implementar su propio agente e integrarse con Pilot siempre que cumpla con los estándares API relevantes.
Componente Citadel que proporciona autenticación de usuario final y control de acceso de servicio a servicio. En resumen, este es un componente relacionado con la seguridad.
El componente Gary es un componente para la adquisición, verificación, procesamiento y distribución de configuración. Adopta un diseño de "desacoplamiento" para desacoplar "la obtención de la configuración del usuario de la plataforma subyacente (como K8S)" de Istio.
Istio utiliza una arquitectura de dos capas y cinco módulos para desacoplar el microservicio ServiceMesh:
El plano de datos es el principal responsable del reenvío eficiente
(1) Envoy módulo: Agente;;
(2) Módulo mezclador: Adaptador; admite API multiplataforma y estandarizada
(3) Módulo experimental: Controla y configura la mayoría de las políticas del enviado;
(4) módulo ciudadela: relacionado con la seguridad;
(5) módulo de cocina: desacoplado de la plataforma subyacente (como K8S);
Separación de implementación y control, Métodos clásicos de diseño arquitectónico, ¿entiendes?
Las ideas son más importantes que las conclusiones.