En el introducción a esta serieEn el post anterior, discutí algunas de las motivaciones para reescribir el SDK .NET, las metas, los objetivos y las principales características de la próxima versión 2.0, y examinamos la arquitectura de alto nivel (10000 pies de vista) de un SDK de cliente de servidor Couchbase. En este post repasaremos el diseño y desarrollo de uno de los componentes centrales de configuración de un SDK de Couchbase: Configuración del Servidor.

Introducción

Un cliente del SDK de Couchbase requiere configuración de dos fuentes: la Configuración del Cliente, que define la IP del cluster al que conectarse, el número de conexiones a utilizar y otra información importante relativa a cómo el cliente interactuará con el cluster y la Configuración del Servidor, que define el estado actual del cluster (por ejemplo, número de nodos, buckets que están disponibles, etc.), conduciendo así el estado interno de un cliente (Mapa de conglomerados)

Este post sólo tratará los aspectos de Configuración del Servidor y girará en gran medida en torno a la implementación de varias interfaces o contratos bien definidos.

Configuración de Streaming HTTP

Actualmente, la mayoría de los clientes utilizan una técnica de "bootstrapping" a través de la configuración del cliente y una "Streaming Configuration" expuesta por el API REST de Couchbase. Esto es soportado por las versiones de Couchbase desde la 2.2 en adelante. El enfoque habitual es el siguiente:

Este planteamiento plantea, entre otros, algunos problemas:

• La creación y el mantenimiento de la "URL de streaming" requiere muchos recursos (principalmente memoria) en el servidor.
• Durante una situación de reequilibrio o conmutación por error, la configuración del clúster puede cambiar muchas, muchas veces. Cada vez que esto ocurre, el cliente debe desmontar todos sus recursos (conexiones de socket, asignaciones de VBucket) y reconstruir su estado una y otra vez, lo que puede reducir el rendimiento, la latencia, un uso de memoria y CPU mayor de lo esperado, etcétera, etcétera...
• Las operaciones en curso pueden finalizar y volver a intentarse en un nuevo estado de configuración - es como si el "han arrancado la alfombra de debajo de ellos".
• Las respuestas NOT_MY_VBUCKET se gestionan de forma ineficaz simplemente probando con el siguiente nodo de la lista - no hay información que ayude al cliente en a qué nodo redirigir la operación.

Un nuevo modelo de gestión de la configuración: CCCP Gestión optimizada de las conexiones

Mientras que el enfoque de "bootstrapping" HTTP ha funcionado razonablemente bien para la mayoría de los clientes, las desventajas han comenzado a superar a las ventajas, por lo que un nuevo modelo para la actualización de la configuración del cliente se ha definido está disponible a partir de la versión 2.5 del servidor Couchbase: Publicación de configuración de clústeres de clientes o "CCCP" Gestión optimizada de las conexiones. CCCP  La gestión optimizada de conexiones introduce una nueva operación que se puede utilizar antes o después de la autenticación para solicitar la configuración, así como un mecanismo para devolver la información de configuración cuando se devuelve una respuesta NOT_MY_VBUCKET por una operación fallida.

En este caso CCCP Gestión de conexión optimizada compatible con SDK, el cliente reaccionará utilizando la configuración para actualizarse a sí mismo antes de reenviar la operación. Tenga en cuenta que NOT_MY_VBUCKET es la respuesta estándar que devuelve el clúster cuando el propio clúster ha cambiado (durante un reequilibrio o un escenario de conmutación por error, por ejemplo) y el cliente aún no se ha "sincronizado" y está utilizando una configuración obsoleta, lo que resulta en una asignación de claves no válida. Mientras que el enfoque "bootstrapping" es en cierto modo una operación de tipo "pull", CCCP La gestión optimizada de conexiones es "push" o "pull" dependiendo de si la petición fue iniciada por el cliente (mediante una operación explícita CMD_GET_CLUSTER_CONFIG) o por el propio servidor (mediante una respuesta NOT_MY_VBUCKET a una operación). Repasaremos CCCP Gestión optimizada de las conexiones en más detalle en un post posterior.

*Edición: CCCP se denomina ahora "Gestión optimizada de conexiones".

Configuración basada en archivos

Existe otra opción de configuración semi-soportada: la configuración basada en ficheros. La configuración basada en archivos es útil principalmente para pruebas y desarrollo, y proporcionaremos una implementación en los proyectos de prueba para eliminar algunas de las dependencias que son difíciles de replicar y o causan falsos positivos al ejecutar el conjunto de pruebas.

Vista de la arquitectura estructural

Internamente, el componente de Configuración del Servidor del cliente es un modelo basado en proveedores, en el que se pueden configurar múltiples implementaciones de un proveedor de configuración en el cliente y, a continuación, se puede elegir una estrategia para determinar qué proveedor se debe utilizar. Por defecto se utiliza un enfoque lineal simple, en el que se utiliza el primer proveedor configurado y, si falla, el siguiente proveedor en la secuencia ocupará su lugar.

Este es un diagrama que muestra los principales objetos actores y las relaciones con algunos de los otros objetos clave dentro del cliente que se discutirán en posts posteriores:

A continuación se ofrece una descripción de cada uno de ellos:

• ConfigurationProvider: una fuente que producirá un nuevo ConfigInfo. Es responsabilidad del proveedor proporcionar el mecanismo para obtener la configuración de su fuente.
• Información de configuración: la información de configuración contiene una lista de posibles nodos y el mapa VBucket que informa a los clientes sobre a qué servidores dentro de dichos nodos debe reenviarse una clave determinada.
• ConfigurationManager: puente entre el cliente y los proveedores y la estrategia adoptada para determinar qué proveedor utilizar y qué lógica de reintento aplicar.

Encontrará un documento más detallado sobre esta arquitectura en aquí. Tenga en cuenta que esto, como todo desarrollo, es un proceso evolutivo, así que espere algunos cambios y revisiones con el tiempo.

Conclusión y próximos pasos

En este post se analizaba la historia (HTTP Streaming) y el futuro (CCCP Gestión de conexión optimizada) de la gestión de configuración del servidor Couchbase SDK. En el próximo post entraremos en detalle en la implementación del proveedor de configuración HTTP Streaming que es necesario para los clientes que apuntan a versiones pre-2.5 de Couchbase Server.