Descripción del código fuente de Kitex: detalles sobre cómo registrar el servicio en el registro

Kitex es el marco RPC de microservicio Golang interno de ByteDance. Tiene las características de alto rendimiento y gran escalabilidad, y se usa ampliamente en Byte. Si tiene necesidades de rendimiento de microservicios y desea personalizar las extensiones para que se ajusten a su sistema de gobierno, Kitex es una buena opción.

Esta vez, podemos comenzar analizando la demostración de easy_note en el ejemplo oficial, porque básicamente muestra el uso básico de Kitex.

La siguiente figura muestra la arquitectura de la demostración oficial. Un análisis simple muestra que la nota y el usuario están registrados a través de Etcd, y la API descubre la nota, el usuario y la API a través de Etcd. Nota: Los usuarios obtienen servicios rpc a través del registro y realizan procesamiento comercial.

Al analizar el ejemplo más simple en kitex-examples/hello, se puede ver claramente en el inicio rápido de cloudwego/kitex que aquí se utiliza el encadenamiento directo más simple para vincular el servidor y el cliente. strong> easy_note usa el registro como puente (middleware) entre servicios, entonces ¿por qué usar el registro en lugar del método anterior?

Busquemos la función del registro: la función principal del registro de servicios es "registro de servicios" y "descubrimiento de servicios"

Al entregar servicios al registro, evitamos allí Existen complejidades en la gestión manual del servicio, y es posible que también debamos considerar otras cuestiones, como por ejemplo:

Uno de los objetivos es resolver la solicitud de resolución del servicio, que también es uno de nuestros objetivos.

Uno de nuestros objetivos esta vez es analizar cómo se registra el servicio cuando se inicia. El primero es el servicio easy_note/cmd/user, que se registra en Etcd.

Comenzaremos con main.go, que es una versión simplificada del archivo que configura el servicio y lo inicia.

Como puedes ver en los comentarios, WithRegister() configura el función de información de registro. Entonces, ¿por qué verificar la función directamente?

En primer lugar, porque es la lógica principal del registro de configuración; en segundo lugar, porque la estructura de la función With... es la misma. La estructura de las funciones es muy similar.

Luego, ingresamos kitex/server/option.go y miramos la línea di.Push(fmt.Sprintf("WithRegistry(T)", r))

* util ¿Qué es .Slice? ¿Entrar y echar un vistazo?

Mirando kitex/pkg/utils/slice.go veo que es muy corto. Pero parece familiar y parece ser una estructura de datos muy común: ¡Stack!

Hay un archivo slice__test.go debajo de este archivo. Si ve este archivo, puede probar si este Slice es el mismo que mi idea. ¡Es mejor que lo hagas tú mismo!

Volvamos a la línea o.Registry = r, podemos ver que Opciones se usa para inicializar el servidor y Opción se usa para configurar Opciones (creo que esta convención de nomenclatura es una buena idea). (Creo que esta es una forma muy inteligente de nombrarlo, y creo que básicamente logra saber qué es y saber por qué es), y hay mucho más en él, así que hoy solo veremos la parte de registro. /p>

Podemos hacer una pausa aquí por un momento y pensar en el proceso para llegar a este punto.

Se ingresa a través del método main.go/user.NewServer().

¿Qué hace NewServer()? Se utiliza para configurar los parámetros opcionales utilizados para inicializar el servidor.

¿Cuándo entran en vigor los parámetros después de la configuración (cuándo ocurre el registro)? ¡La configuración en realidad se implementa en la siguiente oración de main.go NewServer() y Run()!

Al entrar en la implementación del método Ejecutar, puede ver que el registro se produce después de que el servidor se inicia correctamente, y al detenerlo también se cierra la sesión de Etcd (puede ver esto en Stop() en el mismo archivo)

p>