1.principio springmvc
1. El usuario envía una solicitud al controlador front-end DispatcherServlet (también llamado procesador central).
2. DispatcherServlet recibe la solicitud y llama al asignador de procesador HandlerMappering
. 3. El asignador de procesador encuentra el procesador específico (se puede buscar según configuración xml y anotaciones), genera el objeto del procesador y el interceptor del procesador (generado si lo hay) y los devuelve a DispatcherServlet
4. DispatcherServlet llama al adaptador de procesador HandlerAdapter.
5.HandlerAdapter llama al procesador específico (Controlador, también llamado controlador de fondo) mediante adaptación.
6. Una vez completada la ejecución del controlador, regresa a ModelAndView
7. HandlerAdapter devuelve el resultado de la ejecución del controlador ModelAndView al DispatcherServlet
8. DisPatcherServlet pasa ModelAndView al analizador de vistas ViewReslover.
9. ViewReslover devuelve la Vista específica después del análisis
10. DispatcherServlet representa la vista según la Vista (es decir, completa los datos del modelo en la vista).
11.DispatcherServlet responde al usuario.
3. ¿Cuáles son las anotaciones principales de Springboot y las anotaciones comúnmente utilizadas en proyectos? Como @controller, @service, etc.
-
Configuración de SpringBoot
-
Escaneo de componentes
-
Habilitar configuración automática
@Data: las clases de entidad no necesitan agregar manualmente métodos get set
@NoArgsConstructor: genera automáticamente un constructor sin parámetros
@AllArgsConstructor: genera automáticamente constructores de todos los parámetros
@Mapeador
Se utiliza en el archivo KoneLogsMapper para marcar el archivo como un archivo asignador.
La diferencia entre @Select y @SelectProvider
Escriba la declaración SQL directamente después de @Select
@Select("SELECT * FROM ***_logs DONDE cardtype=#{cardType} AND cardid=#{cardId} AND " +
"NO se elimina ORDEN POR fecha,desdehora ")
Archivo de referencia después de @SelectProvider
@SelectProvider(tipo = ******Provider.class, método = “selectParam”)
KoneLogsData findById(@Param(“id”) ID entero);
@Servicio
Marcar esta capa como un archivo de servicio
@autocableado
Importar automáticamente los archivos correspondientes
@ExceptionCatcher("¡Error al agregar el registro!")
Mensaje de excepción lanzado
@ApiIgnorar
El proyecto hereda la arrogancia para ver la interfaz de prueba. @ApiIgnore es para hacer que la anotación ignore esta API.
La diferencia entre @Controller y @RestController
La anotación @RestController es equivalente al efecto combinado de @ResponseBody + @Controller.
-
Si simplemente anota el Controlador con @RestController, el método en el Controlador no puede devolver la página jsp o HTML. El solucionador de vistas configurado InternalResourceViewResolver no funciona y el contenido devuelto es el contenido en Return.
-
Si necesita volver a la página especificada, debe usar @Controller con el solucionador de vistas InternalResourceViewResolver.
Si necesita devolver contenido JSON, XML o mediaType personalizado a la página, debe agregar la anotación @ResponseBody al método correspondiente.
La diferencia entre @RequestBody y @RequestParam
@RequestBody se usa principalmente para aceptar datos en la cadena json pasada desde el front-end al back-end (datos en el cuerpo de la solicitud); el método GET no tiene un cuerpo de solicitud, por lo que cuando se usa @RequestBody para recibir datos, el front-end El final no puede usar el método GET para enviar datos, pero debe enviarlos usando el método POST. En el mismo método de recepción en el backend, @RequestBody y @RequestParam() se pueden usar al mismo tiempo. Puede haber como máximo un @RequestBody, pero puede haber varios @RequestParam().
Nota: Si @RequestParam(xxx) se escribe antes del parámetro, entonces la interfaz debe tener el nombre xxx correspondiente (independientemente de si tiene un valor, por supuesto, puede ajustar si se debe pasar
estableciendo anotación), si no hay xxx Si es así, la solicitud saldrá mal y se informará 400.
@PostMapping(“añadirRegistro”)
El método de publicación acepta el cuerpo de la solicitud,
@GetMapping(“eliminarRegistro”)
El método Get acepta parámetros
@MapperScan (use esta anotación en el archivo de inicio de springBoot para escanear archivos de Mapper)
@MapperScan(basePackages = “com.****e.dao”)
@EnableScheduling
Función de tarea programada propia de Spring @EnableScheduling
La diferencia entre @Component y @ComponentScan
El propósito de usar @Component y @ComponentScan es diferente: usar la anotación @Component en una clase indica que la clase anotada es una clase candidata cuando es necesario crear una clase. Como una mano alzada.
@ComponentScan se utiliza para escanear clases bajo el paquete especificado. Es como ver quién ha levantado la mano.
@SpringBootAplicación
El código fuente contiene @ComponentScan, @EnableAutoConfiguration, @SpringBootConfiguration
@EnableAutoConfiguration, esta anotación tiene la misma función que @Configuration, ambas se usan para declarar que la clase actual es una clase de configuración.
@EnableAutoConfiguration es la anotación principal de Springboot para realizar la configuración automática. A través de esta anotación, los beans requeridos por la aplicación Spring se inyectan en el contenedor.
Cuatro componentes principales de SpringCloud
1.Eureka:
1. Servidor Eureka: ** También conocido como centro de registro de servicios, al igual que otros centros de registro de servicios, admite configuración de alta disponibilidad. Si Eureka se implementa en modo de clúster, cuando falla un fragmento en el clúster, Eureka entrará en modo de autoprotección. Permite que el descubrimiento y el registro de servicios continúen durante una falla del fragmento. Cuando el fragmento fallido vuelve a funcionar, otros fragmentos en el clúster sincronizarán su estado nuevamente.
2. Cliente Eureka: ** Se encarga principalmente del registro y descubrimiento de servicios. El servicio del cliente está incrustado en el código de la aplicación del cliente a través de anotaciones y configuración de parámetros. Cuando la aplicación se está ejecutando, el cliente Eureka registra los servicios que proporciona en el centro de registro y envía periódicamente latidos para actualizar su contrato de arrendamiento de servicios. Al mismo tiempo, también puede consultar la información del servicio registrado actualmente desde el servidor y almacenarla en caché localmente y actualizar el estado del servicio periódicamente.
3. La alta disponibilidad de Eureka Server ** en realidad significa registrarse como un servicio para otros centros de registro, de modo que se pueda formar un grupo de centros de registro de servicios registrados mutuamente para lograr la sincronización mutua de las listas de servicios y lograr una alta disponibilidad.
2.cinta
Ribbon es un equilibrador de carga de cliente basado en HTTP y TCP, que puede sondear la lista de servidores a través de RibbonServerList configurado en el cliente para lograr el equilibrio de servicios. Cuando Ribbon y Eureka se usan juntos, DiscoveryEnabledNIWSServerList reescribirá la lista de instancias de servicio de Ribbon RibbonServerList y la expandirá para obtener la lista de servidores del centro de registro de Eureka. Al mismo tiempo, también utilizará NIWSDiscoveryPing para reemplazar IPing, lo que delega a Eureka la responsabilidad de determinar si el servidor se ha iniciado.
En el equilibrio de carga del cliente, todos los nodos del cliente mantienen una lista de servidores a los que desean acceder, y las listas de estos servidores provienen del centro de registro de servicios (como Eureka). En el equilibrio de carga del cliente, los latidos también son necesarios para mantener el estado de la lista de servidores, pero este paso debe completarse en cooperación con el centro de registro de servicios.
A través de la encapsulación de Spring Cloud Ribbon, solo necesitamos los dos pasos siguientes para utilizar llamadas de equilibrio de carga del cliente en la arquitectura de microservicio:
1. El proveedor de servicios solo necesita iniciar varias instancias de servicios y registrarlas en un centro de registro o en varios centros de registro de servicios asociados.
2. El consumidor del servicio implementa directamente llamadas a la interfaz orientada al servicio llamando al RestTemplate modificado por la anotación @LoadBalanced.
3.fingir
El mecanismo clave de Feign es el uso de agentes dinámicos.
1. Primero, si la anotación @FeignClient está definida para una interfaz, Feign creará un proxy dinámico para esta interfaz.
2. Al llamar a la interfaz, la esencia es llamar al proxy dinámico creado por Feign.
3. El proxy dinámico de Feign construirá dinámicamente la dirección del servicio que se solicitará en función de @RequestMapping y otras anotaciones en la interfaz.
4. Para esta dirección, inicie una solicitud y analice la respuesta.
Feign trabaja en estrecha colaboración con Ribbon y Eureka
1. Primero, Ribbon obtendrá el registro de servicios correspondiente de Eureka Client y luego sabrá en qué máquinas están implementados todos los servicios y en qué puertos están escuchando.
2. Luego, Ribbon puede usar el algoritmo Round Robin predeterminado para seleccionar una máquina.
3. Feign construirá e iniciará una solicitud para esta máquina.
4.Hystrix
En la arquitectura de microservicio, hay tantas unidades de servicio. Si una unidad falla, es fácil que la falla se propague debido a las dependencias, lo que eventualmente conducirá a la parálisis de todo el sistema. Este tipo de arquitectura es más inestable que la tradicional. arquitectura. Para solucionar estos problemas, se han desarrollado una serie de mecanismos de protección del servicio, como los disyuntores.
En una arquitectura distribuida, cuando falla una unidad de servicio, se devuelve una respuesta de error a la persona que llama a través del monitoreo de fallas del disyuntor en lugar de esperar mucho tiempo. Esto evitará que los subprocesos estén ocupados durante mucho tiempo debido a llamadas a servicios defectuosos y evitará la propagación de fallas en el sistema distribuido.
Hystrix tiene funciones poderosas como degradación de servicios, disyuntor de servicios, aislamiento de subprocesos y señales, almacenamiento en caché de solicitudes, fusión de solicitudes y monitoreo de servicios.
Hystrix utiliza el modo de mamparo para implementar el aislamiento del grupo de subprocesos. Crea un grupo de subprocesos independiente para cada servicio dependiente. De esta manera, incluso si el retraso de un servicio dependiente es demasiado alto, solo afectará la llamada del servicio dependiente. no ralentizar otros servicios dependientes
5. Zuul
Spring Cloud Zuul se integra con Spring Cloud Eureka, se registra como una aplicación bajo la gobernanza de servicios de Eureka y obtiene información de instancia de todos los demás microservicios de Eureka.
Para mantener las reglas de enrutamiento, Zuul creará un mapa de enrutamiento utilizando el nombre del servicio como ContextPath de forma predeterminada.
Zuul proporciona un conjunto de mecanismos de filtrado que pueden admitir llamadas unificadas sin conexión a la puerta de enlace API para realizar un filtrado previo de interfaces de microservicios y ha implementado la interceptación y verificación de interfaces de microservicios.
Resumir:
Eureka: cuando se inicia cada servicio, Eureka Client registrará el servicio en Eureka Server, y EurekaClient también puede extraer el registro de Eureka Server para saber dónde están otros servicios.
Cinta: cuando se inicia una solicitud entre servicios, el equilibrio de carga se realiza en función de la cinta y se selecciona una máquina entre varias máquinas de un servicio.
Fingir: mecanismo de proxy dinámico basado en simulación, basado en la anotación y la máquina seleccionada, empalma la dirección URL de la solicitud e inicia la solicitud.
Hystrix: las solicitudes se inician a través del grupo de subprocesos de Hystrix. Diferentes servicios utilizan diferentes grupos de subprocesos, lo que logra el aislamiento de diferentes llamadas de servicio y evita el problema de avalancha de servicios.
Zuul: si el front-end o el terminal móvil quiere llamar al sistema back-end, se ingresará a través de la puerta de enlace Zuul, y la puerta de enlace Zuul reenviará la solicitud al servicio correspondiente.
5. Modo singleton
Singleton de estilo perezoso, singleton de estilo hambriento y singleton registrado. El
patrón singleton tiene las siguientes características:
1. Una clase singleton solo puede tener una instancia.
2. Una clase singleton debe crear su propia instancia única.
3. La clase singleton debe proporcionar esta instancia a todos los demás objetos.