Este es un post invitado del equipo de Orleans. Orleans es un marco multiplataforma para crear aplicaciones distribuidas con .NET. Para obtener más información, consulte https://github.com/dotnet/orleans .Nos complace anunciar el lanzamiento de Orleans 3.0. Se introdujo una gran cantidad de mejoras y correcciones, así como varias características nuevas, desde Orleans 2.0. Estos cambios fueron impulsados por la experiencia de muchas personas que ejecutan aplicaciones basadas en Orleans en producción en una amplia gama de escenarios y entornos, y por el ingenio y la pasión de la comunidad global de Orleans que siempre se esfuerza por mejorar la base de código, más rápido y más flexible ¡Un GRAN agradecimiento a todos los que contribuyeron a este lanzamiento de varias maneras!
Cambios importantes desde Orleans 2.0
Orleans 2.0 se lanzó hace poco más de 18 meses y, desde entonces, Orleans ha logrado avances significativos. Algunos de los principales cambios desde 2.0 son:
- Transacciones de ACID distribuidas: varios granos pueden unirse a una transacción independientemente de dónde esté almacenado su estado
- Un nuevo programador, que solo aumentó el rendimiento en más del 30% en algunos casos
- Un nuevo generador de código basado en el análisis de código de Roslyn
- Membresía de clúster reescrita para mejorar la velocidad de recuperación
- Soporte de cohospedaje
Además de muchas, muchas otras mejoras y correcciones.
Desde los días de trabajo en Orleans 2.0, el equipo estableció un ciclo virtuoso de implementación o integración de ciertas características, como host genérico, opciones con nombre, en estrecha colaboración con el equipo .NET antes de que esas características estén listas para formar parte de .NET Lanzamientos principales, aportando comentarios y mejoras "upstream", y en lanzamientos posteriores cambiando a sus implementaciones finales enviadas con lanzamientos de .NET. Durante el desarrollo de Orleans 3.0, este ciclo continuó, con el código Bedrock utilizado por Orleans 3.0.0-beta1 antes de que finalmente se enviara como parte de .NET 3.0. Del mismo modo, el soporte para TLS en conexiones de socket TCP se implementó como parte de Orleans 3.0 y está destinado a convertirse en parte de una versión futura de .NET Core. Vemos esta colaboración continua como nuestra contribución al ecosistema .NET más grande, en el verdadero espíritu del Código Abierto.
Reemplazo de la capa de red con ASP.NET Bedrock
El apoyo para asegurar la comunicación con
TLS ha sido una solicitud importante durante algún tiempo, tanto de
la comunidad como de los socios internos. Con la versión 3.0 presentamos el soporte TLS, disponible a través del paquete
Microsoft.Orleans.Connections.Security . Para obtener más información, consulte la
muestra TransportLayerSecurity .
La implementación del soporte TLS fue una tarea importante debido a cómo se implementó la capa de red en versiones anteriores de Orleans: no podía adaptarse fácilmente para usar
SslStream , que es el método más común para implementar TLS. Con TLS como nuestra fuerza impulsora, nos embarcamos en un viaje para reescribir la capa de red de Orleans.
Orleans 3.0 reemplaza toda su capa de red con una construida sobre
Project Bedrock , una iniciativa del equipo ASP.NET. El objetivo de Bedrock es ayudar a los desarrolladores a construir clientes y servidores de red rápidos y robustos.
El equipo de ASP.NET y el equipo de Orleans trabajaron juntos para diseñar abstracciones que admitan tanto los clientes como los servidores de la red, sean independientes del transporte y se puedan personalizar con middleware. Estas abstracciones nos permiten cambiar el transporte de red a través de la configuración, sin modificar el código de red interno específico de Orleans. El soporte TLS de Orleans se implementa como un middleware Bedrock y nuestra intención es que esto se haga genérico para que pueda compartirse con otros en el ecosistema .NET.
Aunque el impulso para esta empresa fue habilitar el soporte TLS, vemos una mejora de aproximadamente el 30% en el rendimiento en promedio en nuestras pruebas de carga nocturna.
La reescritura de la capa de red también implicó reemplazar nuestra agrupación de búferes personalizada con la dependencia de
MemoryPool<byte> y al realizar este cambio, la serialización ahora aprovecha más
Span<T> . Algunas rutas de código que anteriormente dependían del bloqueo a través de hilos dedicados que llamaban a
BlockingCollection<T> ahora usan el
Channel<T> para pasar mensajes de forma asincrónica. Esto resulta en menos hilos dedicados, moviendo el trabajo al grupo de hilos .NET en su lugar.
El protocolo de cable central para Orleans se ha mantenido fijo desde su lanzamiento inicial. Con Orleans 3.0, hemos agregado soporte para actualizar progresivamente el protocolo de red a través de la negociación del protocolo. El soporte de negociación de protocolo agregado en Orleans 3.0 permite mejoras futuras, como la personalización del serializador central, al tiempo que mantiene la compatibilidad con versiones anteriores. Una de las ventajas del nuevo protocolo de red es el soporte para conexiones full-duplex de silo a silo en lugar de los pares de conexión simplex establecidos anteriormente entre silos. La versión del protocolo se puede configurar a través de
ConnectionOptions.ProtocolVersion .
Cohospedaje a través del host genérico
El cohospedaje de Orleans con otros marcos, como ASP.NET Core, en el mismo proceso ahora es más fácil que antes gracias a
.NET Generic Host .
Aquí hay un ejemplo de
UseOrleans agregar Orleans junto con ASP.NET Core a un host usando
UseOrleans :
var host = new HostBuilder() .ConfigureWebHostDefaults(webBuilder => {
Usando el generador de host genérico, Orleans compartirá un proveedor de servicios con otros servicios alojados. Esto otorga acceso a estos servicios a Orleans. Por ejemplo, un desarrollador puede inyectar
IClusterClient o
IGrainFactory en un controlador ASP.NET Core MVC y llamar granos directamente desde su aplicación MVC.
Esta funcionalidad se puede usar para simplificar su topología de implementación o para agregar funcionalidad adicional a una aplicación existente. Algunos equipos utilizan internamente el
cohospedaje para agregar
sondas de vida y preparación de Kubernetes a sus silos de Orleans utilizando los
controles de estado de ASP.NET Core .
Mejoras de confiabilidad
Los grupos ahora se recuperan más rápidamente de las fallas gracias a los chismes extendidos. En versiones anteriores de Orleans, los silos enviaban mensajes de chismes de membresía a otros silos, indicándoles que actualizaran la información de membresía. Los mensajes de chismes ahora incluyen instantáneas versionadas e inmutables de la pertenencia al clúster. Esto mejora el tiempo de convergencia después de que un silo se une o abandona el clúster (por ejemplo, durante la actualización, el escalado o después de una falla) y alivia la contención en el almacén de miembros compartidos, lo que permite transiciones de clúster más rápidas. La detección de fallas también se ha mejorado, con más mensajes de diagnóstico y mejoras para garantizar una detección más rápida y precisa. La detección de fallas involucra silos en un grupo que se monitorea en colaboración, y cada silo envía sondas de salud periódicas a un subconjunto de otros silos. Los silos y los clientes ahora también se desconectan de manera proactiva de los silos que han sido declarados difuntos y negarán las conexiones a dichos silos.
Los errores de mensajería ahora se manejan de manera más consistente, lo que da como resultado que los errores rápidos se propaguen de nuevo a la persona que llama. Esto ayuda a los desarrolladores a descubrir errores más rápidamente. Por ejemplo, cuando un mensaje no puede ser completamente serializado o deserializado, una excepción detallada se propagará de nuevo al llamante original.
Extensibilidad mejorada
Las transmisiones ahora pueden tener adaptadores de datos personalizados, lo que les permite ingerir datos en cualquier formato. Esto les da a los desarrolladores un mayor control sobre cómo se representan los elementos de flujo en el almacenamiento. También le da al proveedor de flujo control sobre cómo se escriben los datos, lo que permite que steams se integre con sistemas heredados y / o servicios que no son de Orleans.
Las extensiones de grano permiten agregar un comportamiento adicional a un grano en tiempo de ejecución al conectar un nuevo componente con su propia interfaz de comunicación. Por ejemplo, las transacciones de Orleans utilizan extensiones de grano para agregar métodos de ciclo de vida de la transacción, como
Preparar ,
Confirmar y
Anular , a un grano de forma transparente para el usuario. Las extensiones de grano ahora también están disponibles para los Servicios de grano y los Objetivos del sistema.
El estado transaccional personalizado ahora puede declarar qué roles puede cumplir en una transacción. Por ejemplo, una implementación de estado transaccional que escribe eventos del ciclo de vida de la transacción en una cola del Bus de servicio no puede cumplir con las obligaciones del administrador de transacciones ya que es de solo escritura.
Las estrategias de ubicación predefinidas son de acceso público ahora, por lo que cualquier director de ubicación puede ser reemplazado durante el tiempo de configuración.
Únete al esfuerzo
Ahora que Orleans 3.0 está fuera de la puerta, estamos dirigiendo nuestra atención a futuras versiones, ¡y tenemos algunos planes emocionantes! Ven y únete a nuestra comunidad cálida y acogedora en
GitHub y
Gitter y ayúdanos a hacer realidad estos planes.
Equipo de Orleans