¿Cuánto sabe sobre Dapr | Tiempo de ejecución distribuido?

Intro

El equipo oficial de Dapr ha lanzado oficialmente Dapr v1.0 (2021.1.17) recientemente . Dapr ha estado oficialmente disponible para producción y se puede implementar en un entorno autohospedado o en un clúster de Kubernetes. Para la gran mayoría de los desarrolladores, solo deben haber oído hablar de Dapr, pero no sé qué es (qué), qué tipo de problema (por qué y cómo) se puede resolver (por qué y cómo) y qué escenarios de aplicación (dónde). allí. Este artículo intentará aclarar brevemente Dapr y tratar de responder las preguntas anteriores.

¿Qué es Dapr?

Tiempo de ejecución de aplicaciones distribuidas: un tiempo de ejecución portátil controlado por eventos para crear microservicios en la nube y en el perímetro
. Se utiliza un tiempo de ejecución portátil impulsado por eventos para crear microservicios en la nube y la informática de borde.

Lo anterior es una introducción a Dapr en el repositorio oficial de GitHub de Dapr. El texto es breve, pero el tono es grande, porque no solo cubre todos los puntos de acceso tecnológico actuales: distribuidos, en la nube y microservicios, sino que también se anuncia a sí mismo como: tiempo de ejecución de aplicaciones distribuidas . Somos más o menos conscientes de las aplicaciones distribuidas y hemos escuchado muchos tiempos de ejecución, como tiempos de ejecución de lenguaje común: tiempo de ejecución de Java, tiempo de ejecución de .NET, tiempo de ejecución de Go, etc. ¿Qué es el tiempo de ejecución? En resumen: el tiempo de ejecución es el entorno de ejecución en el que se ejecuta el programa. Tome como ejemplo el programa .NET runtime CLR. Proporciona un entorno de ejecución de código administrado para aplicaciones .NET. Es responsable de la administración de memoria, administración de subprocesos, administración de seguridad, administración remota, incluso compilación, etc. de la aplicación durante el proceso. período de ejecución completo.

El tiempo de ejecución de la aplicación distribuida proporciona el entorno de ejecución en el que se ejecuta la aplicación distribuida. ¿Qué dependencias del entorno necesita para ejecutar aplicaciones distribuidas? Para responder a esta pregunta, primero debemos pensar en los desafíos de desarrollar aplicaciones distribuidas. Si el desafío es claro, se encontrará la respuesta.

De autónomo a distribuido, es la búsqueda de un rendimiento más rápido y superior, pero también trae más incertidumbre. Por ejemplo, no está seguro de cuándo la computadora es anormal, cuando el disco está dañado, no está seguro del retraso de la comunicación de red y no está seguro de si el mensaje se consume normalmente. Estas incertidumbres constituyen un desafío para las aplicaciones distribuidas, en resumen:

1. Máquinas y redes heterogéneas: problemas de estabilidad
2. Fallos habituales en los nodos: problemas de fiabilidad
3. Redes poco fiables: problemas de coherencia

Frente a estos desafíos, la industria ha propuesto muchas teorías y protocolos distribuidos, como el teorema CAP, la teoría BASE y el protocolo de consistencia 2PC / 3PC / ZAB para garantizar el funcionamiento normal del sistema. Aunque el problema parece tener solución, la complejidad de la aplicación ha aumentado. Además de cumplir con los requisitos comerciales, las aplicaciones también deben tener en cuenta los requisitos no comerciales. Integra las funciones básicas de los sistemas distribuidos, como el descubrimiento de servicios, el equilibrio de carga, la conmutación por error, la expansión dinámica, la división de datos y la supervisión de enlaces de llamadas, lo cual es muy importante. poderoso para aplicaciones Intrusividad , esta es una práctica común en el marco de microservicios representado por Spring Cloud.

¿Cómo solucionar problemas intrusivos? Este problema tiene una nueva solución a medida que madura la tecnología de orquestación de contenedores. Kubernetes puede resolver problemas en la capa de contenedor sin entrometerse en la capa de aplicación. Por ejemplo, K8S Service tiene las capacidades de descubrimiento de servicios y equilibrio de carga, y HPA tiene la capacidad de expandirse dinámicamente. Con el rápido desarrollo de K8S, el concepto de nube nativa se ha vuelto cada vez más popular. ¿Cómo hacer un buen uso de las capacidades básicas proporcionadas por K8S para absorber más capacidades distribuidas y devolver el desarrollo de aplicaciones a la empresa? Entre ellos, el modo Sidecar propuesto por Service Mesh resuelve el problema de la comunicación en red en la arquitectura de microservicios . Sidecar se utiliza principalmente para manejar una serie de requisitos no comerciales, como el descubrimiento de servicios, el equilibrio de carga, la fusión de solicitudes, etc. La aplicación inserta dinámicamente Sidecar durante la implementación y la comunicación entre los servicios se realiza mediante proxy a través de Sidecar para completar la toma de control de la comunicación de red. entre servicios.

En este punto, con la ayuda de Service Mesh, el desarrollo de microservicios ha regresado gradualmente al negocio mismo, lo que permite que más desarrolladores vean un rayo de luz. ¿Es suficiente? Echemos un vistazo a los cuatro requisitos principales de las aplicaciones distribuidas mencionados en el artículo Arquitectura de microservicios en tiempo de ejecución múltiple de Bilgin Ibryam :

 

Como se puede ver en la figura anterior, además de Networking, Lifecycle, State y Binding también son uno de los problemas que deben resolver las aplicaciones distribuidas. Los problemas de red se pueden resolver con Service Mesh como Istio. ¿Cómo resolver los otros tres? ¿Quieres volver a aplicar la integración desarrollada por ti mismo? Evidentemente no cumple con los requisitos de la aplicación para volver al negocio en sí. En este momento, entra en escena Dapr. El tiempo de ejecución de la aplicación distribuida propuesto por Dapr cumple los cuatro requisitos anteriores y lo convierte en el entorno operativo de las aplicaciones distribuidas.

En resumen: Dapr encapsula y absorbe las capacidades distribuidas como tiempo de ejecución para simplificar la complejidad técnica del desarrollo de aplicaciones distribuidas.

Cómo funciona Dapr

Entonces, ¿cómo simplifica Dapr el desarrollo de aplicaciones distribuidas? Echemos un vistazo a las características principales de Dapr.

 

Una imagen vale más que mil palabras: Dapr expone llamadas de aplicaciones de capacidad distribuida encapsuladas de una manera independiente del lenguaje, como la API HTTP / gRPC, lo que respalda el desarrollo y la integración en cualquier lenguaje o marco. Actualmente, los SDK para Go, Node, Python, .NET, Java, C ++, PHP, Rust y Javascript se han proporcionado oficialmente para simplificar la integración de Dapr.

Entre ellos, el bloque de construcción central de Dapr (Building Block) se utiliza para proporcionar una variedad de capacidades distribuidas diferentes, echémosle un vistazo por separado.

 1. La invocación de servicio a servicio (invocación de servicio) se
refiere a la invocación de métodos de servicios cruzados, que todos definitivamente pensarán, esto es simple, es solo que el servicio expone la API. Sí, pero no exactamente. Por ejemplo, nodeapp expone una API: http://10.0.0.2:8000/neworderen la forma tradicional, el acceso directo a la API HTTP POST es suficiente, pero en Dapr, proporciona una especificación de interfaz para llamadas a métodos entre servicios, a las que se debe
POST/GET/PUT/DELETE http://localhost:<daprPort>/v1.0/invoke/<appId>/method/<method-name>acceder de acuerdo con el formato. Suponiendo que pythonapp necesita acceder al método de nodeapp, necesita enviarle una solicitud http://localhost:3500/v1.0/invoke/nodeapp/method/neworder. Quizás se pregunte por qué esto es innecesario. ¿Cuál es el significado de este movimiento? El propósito es muy simple, es controlar la comunicación de red entre servicios para completar servicios tales como descubrimiento de servicios, control de flujo, reintento de fusión, acceso seguro, etc. Las funciones de control de red relacionadas están integradas en el Sidecar de Dapr para ser transparentes a las aplicaciones. en la forma. El proceso general de invocación de servicios se muestra en la siguiente figura:

 

PD: Si está familiarizado con Istio, debe prestar atención a que, aunque ambos están controlados por la red Sidecar, hay una diferencia entre los dos. Dapr está en modo API e Istio está en modo proxy (sin cambiar el URI de solicitud HTTP).

2. Gestión de estados (gestión de estados) en el
desarrollo de microservicios, el tema que no se puede evitar es el problema del intercambio de estados y la consistencia de concurrencia entre servicios. Para compartir estados, puede decir que está bien que cada servicio se conecte a la misma instancia de Redis. Sí, pero debemos considerar el problema de los posibles conflictos de actualización. Dapr utiliza una API HTTP más fácil de usar para almacenar y leer el estado. También admite el control de concurrencia a través de ETags y admite la configuración del comportamiento de concurrencia y coherencia a través de opciones.

• almacenamiento:POST http://localhost:<daprPort>/v1.0/state/<storename>
• Leer:GET http://localhost:<daprPort>/v1.0/state/<storename>/<key>
• Eliminar:DELETE http://localhost:<daprPort>/v1.0/state/<storename>/<key>

El siguiente es un ejemplo de estado de ahorro:

• concurrencySe utiliza para especificar opciones de concurrencia: first-write-wins / last-write-wins (sujeto a la primera escritura / última escritura), el valor predeterminado es la última escritura.
• consistencySe utiliza para especificar opciones de consistencia: fuerte / eventual (consistencia fuerte / consistencia eventual), el valor predeterminado es consistencia eventual.

curl -X POST http://localhost:3500/v1.0/state/starwars \
  -H "Content-Type: application/json" \
  -d '[
        {
          "key": "weapon",
          "value": "DeathStar",
          "etag": "xxxxx",
          "options": {
            "concurrency": "first-write",
            "consistency": "strong"
          }
        }
      ]'

Actualmente, Azure CosmosDB, Azure SQL Server, PostgreSQL, AWS DynamoDB, Redis son compatibles como medios de almacenamiento estatales.

3. Publicar y suscribirse (publicación de mensajes y suscripción)
modelo de publicación y suscripción, que es un cliché, utilizado principalmente para que los microservicios se comuniquen entre sí en base a mensajes. También puede decir que esto también debería mencionarse, solo construiré RabbitMQ / RocketMQ. Sí, pero aún quiero decir que Dapr proporciona una API de suscripción y publicación de mensajes consistente sin tener que prestar atención a qué Message Broker se utiliza, lo que lo disocia de la infraestructura subyacente.

• liberación:POST http://localhost:<daprPort>/v1.0/publish/<pubsubname>/<topic>[?<metadata>]
• Obtén temas suscribibles:GET http://localhost:<appPort>/dapr/subscribe
• suscripción:POST http://localhost:<appPort>/<path>

 

4. Enlaces y desencadenadores de recursos (enlaces de recursos y desencadenadores de eventos)
Los enlaces de Dapr son muy similares a las funciones de Azure, que se crean sobre la base de una arquitectura basada en eventos. Al establecer la vinculación de desencadenantes y recursos, los eventos se pueden recibir y enviar desde cualquier fuente externa (como bases de datos, colas, sistemas de archivos, etc.) sin recurrir a las colas de mensajes para lograr escenarios comerciales flexibles. Las ataduras de Dapr se dividen en dos tipos:

1. Enlaces de entrada: cuando se produce un evento de un recurso externo, con la ayuda del enlace de entrada, su aplicación puede POST http://localhost:<appPort>/<name>recibir un evento de un recurso externo a través de una API específica: se puede utilizar para procesar una lógica específica.
2. Enlaces de salida: los enlaces de salida le permiten llamar a recursos externos. Por ejemplo, en un escenario de procesamiento de pedidos, después de que el pedido se haya creado correctamente, la información del pedido se puede POST/PUT http://localhost:<daprPort>/v1.0/bindings/<name>enviar a una cola de Kafka específica a través de la API de enlace de Dapr .

 

5.
El modelo Actor en Actors Dapr se ha transmitido en la misma línea que el Actor virtual de Orleans. Escribí un artículo sobre el marco distribuido Orleans | .NET Core . En pocas palabras: modelo de actor = estado + comportamiento + mensaje. Una aplicación / servicio se compone de múltiples Actores. Cada Actor es una unidad operativa independiente con un espacio operativo aislado. En el espacio aislado, tiene estados y comportamientos independientes sin intervención externa. Los actores pasan por Intercambio de mensajes, y al mismo tiempo , cada actor solo puede ser ejecutado por un único hilo, lo que no solo evita eficazmente el intercambio de datos y los problemas de concurrencia, sino que también garantiza la escalabilidad de la aplicación.

El modelo Actor simplifica enormemente la complejidad de la programación concurrente. Dapr proporciona muchas funciones en el tiempo de ejecución del Actor, incluido el control de concurrencia, la gestión del estado, la gestión del ciclo de vida, como la activación / desactivación de Actores y el Temporizador para despertar Actores. Y Recordatorio. Estas funciones también se proporcionan a través de API .

• Llame al método Actor:POST/GET/PUT/DELETE http://localhost:3500/v1.0/actors/<actorType>/<actorId>/method/<method>
• Crear temporizador:POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/timers/<name>
• Crear recordatorio:POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/reminders/<name>

6. Observabilidad (telemetría)
Dapr registra indicadores, registros, enlaces para depurar y monitorear el estado de ejecución de Dapr y las aplicaciones de usuario. Dapr admite el rastreo distribuido. Utiliza estándares de contexto de rastreo W3C y tecnología de telemetría abierta para diagnosticar fácilmente las llamadas de red entre servicios en el entorno de producción y enviarlas a diferentes herramientas de monitoreo, como Prometheus.

7. Secretos (seguridad)
Dapr proporciona administración de secretos, pero a diferencia de Secret en K8S, admite la integración con la nube pública y el almacenamiento secreto local para la recuperación de aplicaciones.

¿Qué podemos hacer con Dapr?

Sabiendo qué es Dapr y las características que proporciona, los escenarios de aplicación de Dapr son claros de un vistazo. Es decir , eslogan en la página de inicio del sitio web oficial : Simplifique el desarrollo de aplicaciones nativas de la nube: concéntrese en la lógica central de su aplicación y mantenga su código simple y portátil.
Simplifique el desarrollo de aplicaciones nativas de la nube, asegúrese de que las aplicaciones se centren en los negocios y asegúrese de que el código sea simple y portátil.

Por lo tanto, al considerar la selección técnica del desarrollo de aplicaciones nativas de la nube, no dude en probarlo. Actualmente, Alibaba Cloud también lo ha adoptado en China.

Último

En el momento en que la nube nativa está en pleno apogeo, el lanzamiento oficial de Dapr V1.0 ha señalado la dirección de desarrollo de los microservicios en la era nativa de la nube para los desarrolladores. ¡Creo que Dapr seguramente ocupará un lugar en la futura selección de arquitectura de microservicios!

 

El artículo se reproduce: https://www.cnblogs.com/sheng-jie/p/how-much-you-know-about-dapr.html