Autor | Xiaojian Ao, experto técnico sénior de Alibaba Cloud, mantenedor de Dapr

Dapr es el tiempo de ejecución distribuido de código abierto de Microsoft en octubre de 2019. La versión oficial de v1.0 se lanzó recientemente en febrero de este año. Aunque solo ha pasado un año y medio desde su lanzamiento, Dapr se ha desarrollado muy rápidamente y ya ha recibido 1.2w estrellas en GitHub. Alibaba es un participante en profundidad y uno de los primeros en adoptar el proyecto de código abierto Dapr. Tomó el liderazgo en la producción. Hay más de una docena de aplicaciones en el grupo que utilizan Dapr; actualmente hay 2 miembros de Dapr, que es el proyecto Dapr con la mayoría de las contribuciones de código que no sean la empresa Microsoft de.

Aunque Dapr tiene un alto grado de atención en el extranjero, su popularidad en China es muy baja, y la pequeña cantidad de información de Dapr disponible también es parcial a las noticias y las presentaciones simples, y carece de una interpretación profunda de Dapr. Cuando se publique Dapr v1.0, espero que este artículo pueda ayudarlo a formar una comprensión precisa de Dapr: comprender el contexto de desarrollo del proyecto Dapr, comprender sus valores centrales y su visión, y comprender el "Tao" detrás de Dapr proyecto "—— Nativo de la nube.

Revisión: Principio y dirección de Service Mesh

1. Definición de la malla de servicios

Primero, repasemos rápidamente la definición de "Service Mesh", que es el comienzo de la historia de Dapr.

El siguiente es un extracto de mi discurso "Service Mesh: Next Generation Microservices" en QCon Shanghai en octubre de 2017:

Service Mesh es una capa de infraestructura que maneja la comunicación entre servicios. Las aplicaciones nativas de la nube modernas tienen topologías de servicio complejas, y la red de servicios es responsable de la entrega confiable de solicitudes en estas topologías.
En la práctica, la red de servicios se implementa generalmente como un conjunto de agentes de red livianos, que se implementan junto con la aplicación y son transparentes para la aplicación.

En la definición de Service Mesh, se describen brevemente las características clave de Service Mesh:

Posicionamiento de la capa de infraestructura;
La función es la comunicación entre servicios;
Utilice la implementación de Sidecar;
Se pone especial énfasis en ser no intrusivo y transparente para las aplicaciones.

Aquellos que estén familiarizados con Service Mesh deben estar familiarizados con la siguiente imagen:

2. Modo sidecar

En comparación con el marco RPC tradicional, la innovación de Service Mesh radica en la introducción del modo Sidecar:

Después de la introducción de Sidecar, Sidecar se hace cargo de la comunicación entre servicios y el plano de control controla uniformemente Sidecar, lo que se da cuenta del hundimiento de las capacidades de comunicación entre los servicios y simplifica enormemente las aplicaciones.

Repasemos rápidamente las ideas básicas de Service Mesh:

Antes de la introducción de Sidecar: la lógica empresarial y la lógica no empresarial se combinan en un proceso, y la aplicación tiene lógica empresarial y varias funciones no empresariales (reflejadas en varios SDK de cliente).
Después de la introducción de Sidecar: la función del SDK del cliente se elimina, el proceso empresarial se centra en la lógica empresarial y la mayoría de las funciones del SDK se desmontan en procesos independientes y se ejecutan en el modo Sidecar.

Al introducir el modo Sidecar, Service Mesh implementa con éxito la separación de preocupaciones y mantiene de forma independiente dos objetivos principales.

3.Tendencia de desarrollo de Service Mesh

Tomando el proyecto Istio como ejemplo, resumí la tendencia de desarrollo de Service Mesh en los últimos uno o dos años (tenga en cuenta que estos contenidos no son el foco de este artículo, léalo rápidamente y simplemente entiéndalo):

1) Soporte de protocolo

El soporte del protocolo de comunicación en Istio es principalmente HTTP y gRPC, y varios proveedores brindan más soporte de protocolo, incluidos Dubbo, Thrift y Redis. También hay algunas fuerzas comunitarias que se están sumando, como el proyecto Aeraki de Zhao Huabing.

2) Soporte de máquina virtual

El soporte de máquinas virtuales se ha convertido recientemente en un enfoque importante de Istio:

Istio 0.2 ： Expansión de malla
Istio 1.1: ServiceEntry
Istio 1.6: WorkloadEntry
Istio 1.8: WorkloadGroup y proxy DNS inteligente
Istio 1.9: integración de máquina virtual

3) facilidad de uso

Istio 1.5: plano de control único, que combina varios componentes en istiod (este es uno de los ajustes arquitectónicos más importantes desde que Istio fue de código abierto).
Istio 1.7: promueve principalmente el método de instalación del operador, mejora la herramienta istioctl y admite el inicio del contenedor de la aplicación después de iniciar el Sidecar.
Istio 1.8: mejora la actualización y la instalación, presenta el informe de errores de istioctl

4) Observabilidad

Istio 1.8: elimine oficialmente Mixer, vuelva a implementar la función Mixer basada en wasm en Envoy (uno de los ajustes arquitectónicos más importantes de Istio) Istio 1.9: Obtenga y cargue módulos wasm de forma remota.

5) Integración externa

Acceso mutuo con sistemas de malla que no son de servicio para lograr una migración fluida de aplicaciones entre los dos sistemas.

Istio había planeado proporcionar una solución unificada a través del acuerdo MCP.
Istio 1.7: el protocolo MCP se abandonó y se cambió a mcp sobre xds.
Istio 1.9: Soporte de API de servicio de Kubernetes (alfa), que expone los servicios al mundo exterior.

A partir del contenido enumerado anteriormente, podemos ver que Istio ha estado trabajando muy duro para mejorar en los últimos uno o dos años, aunque el proceso es un poco tortuoso y de ida y vuelta (como insistir obstinadamente en Mixer y finalmente obedecer el llamado de toda la comunidad para abandonar por completo Mixer. Después de comenzar a admitir máquinas virtuales, me rendí sustancialmente y luego volví a enfatizarlo recientemente, presenté Galley y luego abandoné Galley, presenté MCP y luego abandoné MCP disfrazado), pero como un En conjunto, Istio todavía está trabajando hacia la dirección general de Product Ready.

Nota: Por supuesto, la comunidad todavía está muy insatisfecha con la velocidad de evolución de Istio y el estado real de Product Ready, por lo que apareció este eslogan: Make Istio Product Ready (Again, and Again ...).

4. Resumen de la revisión de Service Mesh

Revisamos rápidamente la definición de Service Mesh, el principio del modo Sidecar, y enumeramos aproximadamente la tendencia de desarrollo de Service Mesh en los últimos uno o dos años, principalmente para informarle de esta información:

Aunque Service Mesh ha prosperado, sus elementos centrales no han cambiado.

A partir de 2016, el CEO de Linkerd, William Morgon, dio la definición de Service Mesh, e Istio lanzó la versión 1.9 en 2021. Durante los seis años, Service Mesh ha experimentado muchos cambios, pero los siguientes tres elementos principales no han cambiado:

Posicionamiento: El posicionamiento de Service Mesh es siempre la capa de infraestructura que proporciona comunicación entre los servicios, incluidos HTTP y el protocolo HTTP1.1 / REST, HTTP2 / gRPC y TCP compatibles con RPC. También hay algunos pequeños intentos, como el soporte para Redis y Kafka.
Implementación: Service Mesh admite Kubernetes y máquinas virtuales, pero se implementan en el modo Sidecar en lugar de otros métodos, como la implementación de nodo y la implementación centralizada.
Principio: El principio de funcionamiento de Service Mesh es reenviar el protocolo original. En principio, el contenido del protocolo no se modifica (normalmente solo se modifica ligeramente el encabezado). Para lograr el objetivo de cero intrusiones, también se han introducido tecnologías de secuestro de tráfico como iptables.

Evolución: tiempo de ejecución de aplicaciones distribuidas nativas de la nube

Después de completar rápidamente la revisión de Service Mesh, comenzamos la segunda parte de este artículo: Cuando el modelo Sidecar se promueva aún más y los tres elementos centrales anteriores cambien, ¿cómo evolucionará el modelo Sidecar?

1. Práctica: Más formas de malla

Solía hacer contenido relacionado con Service Mesh en el equipo de middleware de Ant Financial. Quizás muchos amigos me conozcan de esa época. En ese momento, Ant no solo creó Service Mesh, sino que también extendió el modo Sidecar de Service Mesh a otros campos de middleware y exploró sucesivamente más formas de malla:

Esta imagen es un extracto de mi discurso de apertura "Poesía y distancia: práctica profunda de Ant Financial Service Mesh" en Shanghai QCon en octubre de 2019. En ese momento, compartimos una variedad de formas de malla, incluida la malla de mensajes, la malla de base de datos, etc.

2. Teoría de la sublimación: se presenta el concepto de Multi-Runtime

Recientemente, más y más proyectos han comenzado a introducir el modo Sidecar, y el modo Sidecar ha sido reconocido y aceptado gradualmente por todos. Recién en 2020, Bilgin Ibryam propuso el concepto de Multi-Runtime, y realizó un resumen práctico y sublimación teórica de varias formas de producto basadas en el modelo Sidecar.

Primero, presentemos al compañero Bilgin Ibryam, autor del libro "Kubernetes Patterns" y el autor del proyecto Apache Camel, que actualmente trabaja en Red Hat.

A principios de 2020, Bilgin Ibryam publicó un artículo "Arquitectura de microservicios de tiempo de ejecución múltiple", proponiendo formalmente una arquitectura de microservicio de tiempo de ejecución múltiple (alias Mecha / Mecha, un nombre muy atractivo). En este artículo, Bilgin Ibryam primero resumió los cuatro tipos de requisitos que existen en las aplicaciones distribuidas, como el punto de partida teórico de Multi-Runtime:

Entre los cuatro tipos de requisitos, los requisitos de gestión del ciclo de vida se cumplen principalmente mediante plataformas PaaS como kubernetes, mientras que Service Mesh proporciona principalmente comunicación punto a punto en la red. Para otros modos de comunicación, como la comunicación de mensajes pub-sub mode y No cubierto, además, la mayoría de los requisitos para las clases estatales y las clases vinculantes tienen poco que ver con Service Mesh.

La derivación teórica de Multi-Runtime es más o menos así: basada en las cuatro categorías de requisitos anteriores, si imita Service Mesh y comienza desde el modelo de middleware tradicional, generalmente habrá los siguientes dos pasos:

Paso 1: Mueva las capacidades distribuidas requeridas por la aplicación a varios tiempos de ejecución. En este momento, habrá una gran cantidad de varios sidecars o proxies, como Istio, Knative, Cloudstate, Camel, Dapr, etc. enumerados anteriormente.
Paso 2: Estos tiempos de ejecución se integrarán gradualmente, dejando solo una pequeña cantidad o incluso solo uno o dos tiempos de ejecución. Este tiempo de ejecución que proporciona múltiples capacidades distribuidas también se llama Mecha.

Una vez completado el paso dos, cada microservicio estará compuesto por al menos un Mecha Runtime y un Runtime de la aplicación, es decir, cada microservicio tendrá múltiples (al menos dos) tiempos de ejecución, que es el origen del nombre Multi-Runtime / Mecha.

3. Aplicaciones distribuidas nativas de la nube y en tiempo de ejecución múltiple

Formas de introducir el concepto de Multi-Runtime / Mecha a las aplicaciones distribuidas nativas de la nube:

Capacidades: Mecha es un componente universal, altamente configurable y reutilizable que proporciona primitivas distribuidas como una capacidad lista para usar.
Implementación: Mecha se puede implementar con un solo componente Micrologic (modo Sidecar) o como varios recursos compartidos (como el modo Node).
Acuerdo: Mecha no hace ninguna suposición sobre el tiempo de ejecución de Micrologic. Se utiliza con microservicios multilingües e incluso monolitos que utilizan protocolos y formatos abiertos (como HTTP / gRPC, JSON, Protobuf, CloudEvents).
Configuración: Mecha se configura de forma declarativa en un formato de texto simple (como YAML, JSON), que indica las funciones que se habilitarán y cómo vincularlo al punto final Micrologic.
Integración: en lugar de depender de múltiples agentes para lograr diferentes propósitos (como agentes de red, agentes de almacenamiento en caché, agentes de enlace), es mejor utilizar un Mecha para proporcionar todas estas capacidades.

4. Características y diferencias de Multi-Runtime

Aunque es igual que el modo Sidecar, en comparación con Service Mesh, Multi-Runtime tiene sus propias características:

Método y alcance de proporcionar capacidades: Multi-Runtime proporciona capacidades distribuidas, que están incorporadas en varias primitivas distribuidas requeridas por las aplicaciones, y no se limitan a simples agentes de red para la comunicación punto a punto entre servicios.
Método de implementación en tiempo de ejecución: el modelo de implementación de Multi-Runtime no se limita al modo Sidecar. El modo Node puede ser una mejor opción en algunos escenarios (como Edge / IoT, Serverless FaaS).
Interacción con la aplicación: La interacción entre Multi-Runtime y la aplicación es abierta y tiene estándares API. El "protocolo" entre Runtime y Micrologic está incorporado en la API en lugar del protocolo de comunicación TCP nativo. Además, Multi-Runtime no requiere no intrusiones, y también se proporcionan SDK en varios idiomas para simplificar el desarrollo.

La diferencia entre Multi-Runtime y Service Mesh se resume como se muestra en la siguiente figura:

5. La esencia de Multi-Runtime

Hasta ahora he presentado el origen de la arquitectura Multi-Runtime Creo que los lectores conocen las características de Multi-Runtime y la diferencia con Service Mesh. Para profundizar su comprensión, permítame compartir más mi percepción personal de Multi-Runtime:

La esencia de Multi-Runtime es una capa de abstracción de capacidades distribuidas para aplicaciones nativas de la nube.

¿Qué es la "capa de abstracción de capacidad distribuida"?

Como se muestra en la figura anterior, a la izquierda hay cuatro tipos de requisitos para aplicaciones distribuidas: ciclo de vida, red, estado y enlace. En términos de requisitos, Multi-Runtime debe proporcionar aplicaciones distribuidas con varias capacidades distribuidas específicas enumeradas en estas cuatro categorías de requisitos. Es fácil de entender proporcionar estas capacidades a las aplicaciones en el modo Sidecar, pero la clave está en la forma en que Multi-Runtime proporciona estas capacidades. A diferencia de Service Mesh que usa el protocolo original para el reenvío, el método Multi-Runtime es:

Capacidades abstractas como API: muchas capacidades distribuidas no tienen un protocolo para toda la industria similar a HTTP. Por lo tanto, la implementación de Multi-Runtime abstrae estas capacidades en API que no tienen nada que ver con el protocolo de comunicación, que solo se usa para describir el la capacidad de la aplicación para distribuir capacidades Requisitos e intenciones, trate de evitar la vinculación con una determinada implementación.
Proporcione múltiples implementaciones para cada capacidad: las capacidades en Multi-Runtime generalmente brindan múltiples implementaciones, incluidos productos de código abierto y productos comerciales de nube pública.
Durante el desarrollo: Aquí introducimos un concepto de "programación frente a la capacidad", que es similar a "programación sin enfrentar la implementación, pero programación orientada a la interfaz" en los lenguajes de programación. Multi-Runtime aboga por la programación de "capacidades", es decir, los desarrolladores de aplicaciones deben estar orientados a primitivas de capacidades distribuidas abstractas, en lugar de proporcionar implementaciones concretas de estas capacidades en la capa inferior.
Tiempo de ejecución: La selección de implementaciones específicas en tiempo de ejecución a través de la configuración no afecta la definición de la API de capa abstracta, ni afecta a las aplicaciones desarrolladas siguiendo el principio de "programación frente a la capacidad".

Observaciones: La API estándar universal para capacidades distribuidas será la clave para el éxito o el fracaso de Multi-Runtime. La API de Dapr también encuentra grandes desafíos en el diseño y la práctica. Sobre este tema, escribiré un artículo aparte para elaborarlo y analizarlo más adelante.

Introducción: Dapr para tiempo de ejecución de aplicaciones distribuidas

Después de una revisión rápida de Service Mesh y una introducción detallada a la arquitectura de tiempo de ejecución múltiple, hemos sentado una buena base para comprender Dapr. Ahora que finalmente podemos comenzar el Nie Rong oficial de este artículo, aprendamos juntos sobre el proyecto Dapr.

1. ¿Qué es Dapr?

Dapr es un proyecto de código abierto iniciado por Microsoft. La siguiente es una introducción autorizada del sitio web oficial de Dapr:

Dapr es un tiempo de ejecución portátil> impulsado por eventos que facilita a cualquier desarrollador la creación de aplicaciones resilientes, sin estado y con estado que se ejecutan en la nube y en el borde, y abarca la diversidad de lenguajes y marcos de desarrollo para desarrolladores. Dapr es un evento portátil Impulsado por el tiempo de ejecución, permite a cualquier desarrollador crear fácilmente aplicaciones elásticas, sin estado y con estado que se ejecutan en la nube y el borde, y adoptar la diversidad de lenguajes y marcos para desarrolladores.

Al hacer referencia y comparar la definición de Service Mesh, nuestro análisis de la definición anterior de Dapr es el siguiente:

Posicionamiento: Dapr se define a sí mismo como un tiempo de ejecución, no un proxy en Service Mesh.
Función: Dapr proporciona varias capacidades distribuidas para aplicaciones para simplificar el desarrollo de aplicaciones. Los puntos clave mencionados en la definición anterior son flexibles, admiten estado y apátridas, y controlados por eventos.
Multi-idioma: la compatibilidad con varios idiomas es la ventaja natural del modelo Sidecar. Dapr no es una excepción. Teniendo en cuenta la cantidad de capacidades distribuidas que Dapr envía para las aplicaciones, esto puede ser más valioso para las aplicaciones que Service Mesh que solo proporciona capacidades de comunicación. entre servicios. Y debido a la existencia del SDK del lenguaje Dapr, Dapr se puede integrar fácilmente con los marcos de desarrollo convencionales de varios lenguajes de programación, como Java y Spring.
Portabilidad: los escenarios aplicables de Dapr incluyen varias nubes (nube pública, nube privada, nube híbrida) y redes de borde, varias características clave de la arquitectura Multi-Runtime como "programación orientada a capacidades", API estándar, implementación de configuración de tiempo de ejecución Esto ha traído a Dapr excelente portabilidad entre nubes y plataformas.

Ampliaremos estas características de Dapr en detalle en la siguiente introducción. Antes de comenzar, aquí hay un pequeño detalle: el origen del nombre del proyecto "Dapr":

2. La función y la arquitectura de Dapr Sidecar

Al igual que Service Mesh, Dapr también se basa en el modelo Sidecar, pero las funciones y los escenarios de uso proporcionados son más complejos que los de Service Mesh, como se muestra en la siguiente figura:

Sidecar de Dapr, además de admitir la comunicación entre servicios como Service Mesh (actualmente admite el protocolo HTTP1.1 / REST y el protocolo gRPC, también puede admitir más funciones, como estado (gestión de estado), pub-sub (comunicación de mensajes)) , enlace de recursos (enlace de recursos, incluidas las entradas y salidas).

Cada función tiene múltiples implementaciones. En la figura anterior, extraje brevemente las implementaciones comunes de estas capacidades. Puede ver que hay tanto productos de código abierto como productos comerciales de nube pública en la implementación. Tenga en cuenta que esto es solo una pequeña parte de la implementación actual de Dapr. Actualmente hay más de 70 implementaciones (llamadas componentes en Dapr, que presentaremos a continuación), y aún están aumentando.

En la arquitectura de Dapr, hay tres componentes principales: API, Building Blocks y Componentes, como se muestra en la siguiente figura:

API de Dapr: Dapr proporciona dos API, HTTP1.1 / REST y HTTP2 / gRPC, que son funcionalmente equivalentes.
Bloques de construcción de Dapr: traducida en bloques de construcción, esta es la unidad básica para que Dapr proporcione capacidades externas, y cada componente de construcción proporciona una capacidad distribuida externamente.
Componentes Dapr: capa de componente, esta es la capa de realización de capacidad de Dapr, cada componente se dará cuenta de la capacidad de un bloque de construcción específico.

Para ayudarlo a comprender la arquitectura de Dapr, repasemos la esencia de Multi-Runtime destacada anteriormente:

La esencia de Multi-Runtime es una capa de abstracción de capacidades distribuidas para aplicaciones nativas de la nube.

Combinando el concepto Multi-Runtime, entendamos la arquitectura de Dapr Runtime:

Dapr Building Blocks proporciona "capacidades".
Dapr API proporciona una "abstracción" de capacidades distribuidas, exponiendo las capacidades de Building Blocks al exterior.
Los componentes Dapr son la "realización" concreta de las capacidades del Building Block.

3. Visión y capacidades actuales de Dapr

La siguiente imagen es de un funcionario de Dapr, que resume las capacidades y la estructura jerárquica de Dapr de manera más completa:

El azul centrado es Dapr Runtime: aquí están los bloques de construcción que Dapr proporciona actualmente.
Dapr Runtime proporciona capacidades a través de llamadas remotas al mundo exterior. Actualmente, existen API HTTP y API gRPC.
Debido a las ventajas naturales del modelo Sidecar, Dapr admite varios lenguajes de programación, y Dapr proporciona oficialmente SDK para los lenguajes principales (normalmente Java, golang, c ++, nodejs, .net, python). Estos SDK encapsulan la capacidad de interactuar con Dapr Runtime a través de la API HTTP o la API gRPC.
En la parte inferior está la plataforma en la nube o la red perimetral que puede admitir Dapr. Dado que cada capacidad se puede completar con diferentes componentes, en teoría, siempre que el soporte de Dapr sea lo suficientemente perfecto, se puede implementar en cualquier plataforma y siempre se puede encontrar. Componentes disponibles basados en productos de código abierto o productos comerciales de proveedores de nube.

Combinando los puntos anteriores, Dapr propuso tal visión:

Cualquier idioma, cualquier marco, en cualquier lugar

Es decir: se puede desarrollar en cualquier lenguaje de programación, se puede integrar con cualquier marco y se puede implementar en cualquier plataforma. La siguiente figura es una breve descripción de los componentes básicos existentes de Dapr y las capacidades que brindan:

4. Plano de control de Dapr

Similar a la arquitectura de Service Mesh, Dapr también tiene el concepto de plano de control:

Los componentes del plano de control de Dapr son:

Colocación de actor de Dapr
Inyector Sidecar Dapr
Dapr centinela
Operador Dapr

Lo que es más interesante es que para simplificar la operación y el mantenimiento, Istio ha fusionado el plano de control de la arquitectura de microservicios y el plano de control ha vuelto al modelo monolítico tradicional. El plano de control de Dapr sigue siendo una arquitectura de microservicio y no sé si imitará a Istio en el futuro.

Observaciones: En aras del control de la longitud, este artículo no amplía en detalle los bloques de construcción y el plano de control de Dapr. Se espera que haya un artículo separado para presentar en detalle más adelante, que los estudiantes interesados en Dapr pueden seguir.

5. Historia de desarrollo de Dapr y participación de Alibaba

Dapr es un proyecto de código abierto muy nuevo, solo se ha desarrollado durante aproximadamente un año y medio, pero la atención de la comunidad es bastante buena (principalmente en el extranjero), y actualmente tiene cerca de 12,000 estrellas en GitHub (análogo: Envoy 16000, Istio 26000, Linkerd 7000). Los principales hitos del proyecto Dapr son:

Octubre de 2019: Microsoft abrió Dapr en GitHub y lanzó la versión 0.1.0.
Febrero de 2021: Lanzamiento de la versión Dapr v1.0.

Alibaba está profundamente involucrada en el proyecto Dapr, no solo convirtiéndose en uno de los primeros en adoptar Dapr como usuario final, sino también convirtiéndose en una de las principales empresas que contribuyen al proyecto Dapr al participar plenamente en el desarrollo de código abierto y la contribución de código de Dapr, solo superada Microsoft:

Mediados de 2020: Alibaba comienza a participar en el proyecto Dapr, funciones de prueba internamente y desarrollo de código.
El final de 2020: Dapr piloto interno a pequeña escala de Alibaba, actualmente más de una docena de aplicaciones están usando Dapr.

Nota: Para conocer la práctica de Dapr en Alibaba, consulte nuestro artículo "Cómo Alibaba utiliza Dapr" recién publicado en el blog oficial de Dapr.

En la actualidad, ya tenemos dos Dapr Committers y un Dapr Maintainer. En 2021, se espera que tengamos más inversión en el proyecto Dapr, incluidas más contribuciones de código fuente abierto y prácticas de aterrizaje, y promocionemos personalmente el desarrollo del proyecto Dapr. . Dé la bienvenida a más contribuyentes y empresas nacionales a unirse a la comunidad de Dapr.

6. Experiencia rápida Dapr

La instalación de Dapr y el contenido del estudio rápido se proporcionan en los documentos oficiales de Dapr, que pueden ayudarlo a instalar y experimentar rápidamente las capacidades y el uso de Dapr.

Para experimentar Dapr de manera más rápida y conveniente, hemos proporcionado un tutorial introductorio súper simple a Dapr a través de Alibaba Cloud Knowledge Lab. Solo toma unos diez minutos experimentar rápidamente el proceso de desarrollo e implementación de Dapr:https://start.aliyun.com/course?id=gImrX5Aj。

Los estudiantes interesados realmente pueden experimentarlo.

Outlook: la forma futura de las aplicaciones y el middleware

En la última parte de este artículo, analizamos la forma futura de la aplicación y el medio.

1. Antecedentes de la era nativa de la nube

Lo primero que hay que decir es que todas estas cosas que hemos explicado se basan en una gran premisa: nativa de la nube.

La siguiente imagen es un extracto de mi discurso "Poesía y distancia: práctica profunda de Ant Financial Service Mesh" en la Conferencia QCon en octubre de 2019:

En ese momento (2019), acabábamos de completar la exploración y la implementación a gran escala de Kubernetes y Service Mesh, y comenzamos una nueva exploración de Serverless. En este artículo, hice un resumen de implementación nativa de la nube y sugerencias sobre si adoptar Service Malla, que se puede resumir a grandes rasgos como (Citar directamente el texto original):

Una cosa está muy clara para nosotros: el mallado es un paso clave para el aterrizaje nativo en la nube.
Si la nube nativa es su poesía y la distancia, entonces Service Mesh es la única forma.
Kubernetes / Service Mesh / Serverless es la troika de la práctica nativa de la nube, que se complementan y complementan entre sí.

Hoy, dos años después, mirando hacia atrás en el juicio sobre la dirección general de la estrategia de desarrollo nativo de la nube en ese momento, tengo muchos sentimientos. Ajusté ligeramente la imagen de arriba y agregué el contenido de Multi-Runtime / container / multi-cloud / hybrid cloud. Modifique la siguiente imagen:

En comparación con 2019, el concepto de nube nativa ha sido ampliamente reconocido y adoptado: la nube híbrida y la nube múltiple se han convertido en la dirección principal de las futuras plataformas en la nube; Service Mesh tiene más prácticas de aterrizaje y más empresas utilizan Service Mesh; Serverless también se ha desarrollado rápidamente en los últimos dos años.

La tendencia histórica de la nube nativa todavía está en progreso, pero ¿a dónde irán las aplicaciones y el middleware en el contexto de la nube nativa?

2. Las expectativas de las aplicaciones son la dirección del middleware

Imaginemos la aplicación empresarial en el estado más ideal bajo el telón de fondo de la nube nativa, es un dulce sueño:

Las aplicaciones se pueden escribir en cualquier idioma favorito y adecuado, y se pueden desarrollar e iterar rápidamente.
Todas las capacidades requeridas por la aplicación se pueden proporcionar a través de API estándar, sin la necesidad de preocuparse por la implementación subyacente.
La aplicación se puede implementar en cualquier nube, ya sea una nube pública, una nube privada o una nube híbrida, sin restricciones de plataforma y proveedor, y sin modificación de código.
La aplicación puede escalar elásticamente de acuerdo con el tráfico, soportar la presión de la cresta de la ola y también puede liberar recursos cuando está inactiva.
……

Mi opinión personal sobre la forma futura de las aplicaciones nativas de la nube es: sin servidor será la forma ideal y la dirección de desarrollo principal para las aplicaciones nativas de la nube; y el soporte en varios idiomas, la portabilidad entre nubes y las aplicaciones ligeras serán los tres aspectos principales de aplicaciones nativas de la nube. Principales demandas.

La expectativa de que la aplicación sea nativa de la nube es el camino a seguir para el middleware.

En los últimos años, el middleware ha estado avanzando a tientas y avanzando impulsado por el hermoso objetivo de la nube nativa, y seguirá siendo el mismo en los próximos años. Service Mesh exploró el modelo Sidecar, Dapr extendió el modelo Sidecar a áreas más grandes:

El soporte perfecto en varios idiomas y la necesidad de aplicaciones ligeras empujan al middleware a separar más capacidades de las aplicaciones.
El modelo Sidecar se extenderá a áreas más grandes, y más y más productos de middleware comenzarán a Mesh e integrarse en Runtime.
La aversión natural y la elusión del bloqueo de proveedores intensificará la búsqueda de la portabilidad, lo que promoverá aún más la provisión de API estándar y comunes en la industria para las capacidades de distribución media que se hunden en Runtime.
La estandarización de API y el reconocimiento de la comunidad se convertirán en el mayor desafío para la popularización en tiempo de ejecución, pero al mismo tiempo, también promoverá varios productos de middleware para mejorar su propia realización y realizar la integración y la perfección entre los productos de middleware y las API estándar de la comunidad.

Impulsado por la demanda nativa de la nube, se espera que el soporte multilingüe, la portabilidad entre nubes y las aplicaciones ligeras se conviertan en el punto de avance y la dirección de desarrollo clave de los productos de middleware en los próximos años, como se muestra en la siguiente figura:

En el campo actual de los nativos de la nube, el proyecto Dapr es una nueva fuerza muy llamativa. Dapr es un pionero, iniciando una nueva exploración del concepto Multi-Runtime, y este debe ser un proceso difícil. ¡Espero que más personas y empresas se unan a nosotros en la comunidad de Dapr, exploren juntos y crezcan juntos!

Nota: Con respecto al tema de la estandarización de la API de Dapr y los desafíos que encontró Dapr al definir e implementar la API, hubo una animada discusión en el lugar. Más adelante, resolveré un artículo separado, combinando la práctica en profundidad de la API estatal y otras nuevas. El proceso de diseño de la API de configuración es muy profundo, así que estad atentos.

final

Al final de este artículo, resumamos el texto completo con este párrafo:

Dapr amplía aún más los escenarios de uso del modo Sidecar sobre la base de Service Mesh. Por un lado, proporciona una solución multilingüe natural para satisfacer las necesidades de las aplicaciones nativas de la nube para capacidades distribuidas y ayuda a las aplicaciones a ser livianas y sin servidor. por otro lado, proporciona la capa de abstracción de capacidad distribuida de la aplicación y la API estándar que proporcionan una excelente portabilidad para la implementación de nubes múltiples e híbridas, evitando el bloqueo de proveedores.

Dapr liderará el futuro de las aplicaciones y el middleware en la era nativa de la nube .

Apéndice: Materiales de referencia

Las referencias relacionadas para este artículo son las siguientes:

Sitio web oficial de Dapr y documentos oficiales de Dapr: parte de la introducción y las imágenes de Dapr se extrajeron del sitio web oficial de Dapr.
El contenido y las imágenes de la arquitectura de microservicios en tiempo de ejecución múltiple: tiempo de ejecución múltiple se citan en este artículo de Bilgin Ibryam

Sobre el Autor

Xiaojian Ao, productor senior de código, experto en microservicios, evangelista de Service Mesh, mantenedor de Dapr. Concéntrese en la infraestructura, el partidario de Cloud Native, el profesional ágil y el arquitecto que se adhieren a la primera línea del desarrollo y la artesanía pulida. Actualmente trabaja en Alibaba Cloud, responsable del desarrollo de Dapr en la plataforma de aplicaciones nativas en la nube.

Con un aumento de 1.2w estrellas en un año, ¿puede Dapr liderar el futuro del middleware nativo de la nube?