Entrevista: preguntas de la entrevista sobre microservicios que debes conocer y conocer
¿Cuál es la diferencia entre SOA y microservicios?
SOA se propuso en el campo de la informática empresarial, que consiste en dividir los sistemas estrechamente acoplados en servicios orientados a los negocios, de grano grueso, débilmente acoplados y sin estado. Los servicios se publican para que otros servicios los llamen, y un grupo de servicios interdependientes constituye un sistema bajo la arquitectura SOA.
Con base en estos servicios básicos, los procesos comerciales se pueden organizar de manera similar a los procesos BPEL, y BPEL refleja el proceso de procesamiento comercial. Estos procesos son más intuitivos para el personal comercial y se pueden ajustar más fácilmente que el código rígido. El código es más fácil.
Por supuesto, las empresas también necesitan gestionar servicios, como la base de datos de registro de servicios, el seguimiento y la gestión, etc.
Sabemos que en el campo de la informática empresarial, si no es un sistema comercial, la cantidad de concurrencia no es muy grande, por lo que en la mayoría de los casos, un servidor puede acomodar muchos servicios, y estos servicios utilizan una infraestructura unificada puede ejecutarse en un proceso de servidor de aplicaciones. Aunque se dice que está orientado a servicios, sigue siendo un sistema único.
La arquitectura de microservicios generalmente surgió de las empresas de Internet. Debido a los usuarios a gran escala, los requisitos para los sistemas distribuidos son muy altos. Si el sistema es como la informática empresarial, la escala requiere múltiples adaptaciones. El servicio se utiliza para convertir varios sistemas en un clúster mediante el equilibrio de carga. Pero esto es muy inconveniente. Las empresas de Internet tienen un ciclo de iteración muy corto. Pueden lanzar una versión por semana, o incluso una versión cada día, y los ciclos de lanzamiento de diferentes subsistemas son diferentes. Además, los diferentes subsistemas no utilizan almacenamiento centralizado como la informática empresarial original, que utiliza el costoso Oracle para almacenar los datos de todo el sistema. En segundo lugar, se utilizan bases de datos NOSQL como MongoDB, HBase y Cassandra y cachés distribuidos como Redis y Memcache. . Luego tiende a dividirse en subsistemas. Los diferentes subsistemas adoptan su propia arquitectura. Luego, cada servicio se ejecuta en su propio contenedor web. Cuando necesita aumentar la potencia informática, solo necesita agregar una instancia de este subsistema o servicio. , no afecta a otros subsistemas. Este tipo de organización generalmente se denomina arquitectura de microservicios.
En comparación con SOA, los microservicios enfatizan las características de los sistemas distribuidos, como la escalabilidad horizontal, el descubrimiento de servicios, el equilibrio de carga, la conmutación por error y la alta disponibilidad. El desarrollo de Internet ha planteado más requisitos para la gobernanza de servicios, como versiones múltiples, actualizaciones en escala de grises, degradación del servicio y seguimiento distribuido. Todas estas son cosas a las que no se les presta suficiente atención en la práctica de SOA.
La aparición de la tecnología de contenedores Docker proporciona condiciones más convenientes para los microservicios, como unidades de implementación más pequeñas. Cada servicio puede ejecutarse en su propio proceso a través de tecnologías como Node.js o Spring Boot. Puede haber miles de contenedores Docker ejecutándose en docenas de computadoras, y cada contenedor ejecuta una instancia del servicio. Puede aumentar la cantidad de instancias de un servicio en cualquier momento o crear una nueva instancia del servicio en otra computadora después de que una instancia falla.
¿Cómo dividir un servicio?
Para dividir los módulos comerciales, la granularidad de división debe garantizar que los microservicios tengan independencia e integridad comercial, con la menor cantidad posible de dependencias de servicios y llamadas en cadena. Sin embargo, en el proceso de desarrollo real, a veces la arquitectura monolítica es más adecuada para el proyecto actual. De hecho, el diseño de microservicios no se logra de la noche a la mañana, es un proceso de diseño y retroalimentación. Por lo tanto, podemos diseñar la granularidad del servicio para que sea mayor al comienzo del diseño y considerar su escalabilidad a medida que se desarrolla el negocio, la división dinámica también es una buena opción.
En el nombre de REST "Transformación del estado de la capa de presentación", se omite el asunto. "Capa de presentación" en realidad se refiere a la "capa de presentación" de "Recursos".
El llamado "recurso" es una entidad en la red, o una información específica en la red. Puede ser un texto, una imagen, una canción, un servicio, en definitiva es una realidad concreta. Lo señala con un URI (Localizador uniforme de recursos) y cada recurso corresponde a un URI específico.
Para obtener este recurso basta con acceder a su URI, por lo que la URI se convierte en la dirección o identificador único de cada recurso.
El método utilizado por el cliente sólo puede ser el protocolo HTTP. Específicamente, hay cuatro verbos que indican métodos de operación en el protocolo HTTP: GET, POST, PUT y DELETE. Corresponden a cuatro operaciones básicas: GET se usa para obtener recursos, POST se usa para crear nuevos recursos (también se puede usar para actualizar recursos), PUT se usa para actualizar recursos y DELETE se usa para eliminar recursos.
De hecho, no todo es un "recurso", especialmente en los sistemas empresariales. Las desventajas son las siguientes:
Existe una interfaz para actualizar el estado del pedido. uno es GET POST PUT DELETE. Parece ser PUT, pero la ruta es PUT /tickets/12
A veces tengo varias interfaces para actualizar el estado de cobro del pedido, actualizar el estado de pago del pedido y actualizar el estado de liquidación;
La ruta de Restful es obviamente hostil e insuficiente
Otro ejemplo es la eliminación por lotes ¿DELETE /tickets/12 #Eliminar ticket 12 ¿Qué? ¿Qué debo hacer si quiero pasar una matriz? ¿La URL no es lo suficientemente amigable?
Para otro ejemplo, Resuful requiere GET /tickets # Obtener la lista de tickets.
Una vez tuvimos una demanda y la otra parte no nos pasó más de 1000 ID de pedido. Nuestro sistema filtró algunos de los pedidos especiales; este también es un servicio de consulta. Utilice GET /tickets # para obtener la lista de 1000 pedidos. son obviamente Cualquier cosa que exceda la longitud de la URL GET no es adecuada aquí; además, quiero desarrollar múltiples servicios de listas de consultas condicionales, y una ruta tan superficial es obviamente inapropiada.
En los negocios reales, la ruta; de nuestra webapi es así: systemAlias/controller/action
Resume las reglas:
Intenta usar GET para consultas simples. La ventaja es que puedes copiar directamente la ruta de la API. parámetros de consulta;
para consultas complejas y POST se utiliza para actualizaciones, que es el más utilizado
PUT y DELETE no se utilizan porque aumenta la complejidad y no aporta ningún beneficio;
Mire muchas de las openapi de BAT, también dicen restful, de hecho, no se siguen estrictamente, son tanto get como post, por lo que mucha gente no sabe poner y eliminar
Por ejemplo:
//Obtener el pedido según el ID del pedido
GET oms/order/queryOrderById?id=value1¶m2=value2
/ /Obtener pedidos según la lista de ID de pedido
POST oms/order/queryOrderByIdList
//Consultar pedidos según condiciones, con parámetros de paginación
POST oms/order /queryOrderByCondition
//Actualizar estado de pago del pedido
POST oms/order/ updateOrderCollectionStatus
//Actualizar estado de cobro del pedido en lotes
POST oms/order/updateOrderCollectionStatusInBatch
//Actualizar estado de recogida de pedidos en lotes
POST oms/order/updateOrderCollectionStatusInBatch
//Eliminar pedidos en lotes, con operación fuente
POST oms/order/deleteOrderInBatch
¿Cómo gestiona el microservicio la base de datos?
Teorema CAP (Teorema CAP)
En un partido de fútbol, cuando un jugador marca tres goles en un partido, se llama hat-trick. En los sistemas de datos distribuidos, también existe un principio de sombrero (teorema CAP), pero este sombrero no es el otro. Hay tres elementos en el principio de la PAC:
El principio de la PAC significa que estos tres elementos solo pueden lograr como máximo dos puntos al mismo tiempo, y es imposible tener en cuenta los tres.
Por lo tanto, al diseñar una arquitectura distribuida, se deben hacer concesiones. Para los sistemas de datos distribuidos, la tolerancia a la partición es un requisito básico; de lo contrario, perderá valor. Por lo tanto, diseñar un sistema de datos distribuido es lograr un equilibrio entre coherencia y disponibilidad.
Para la mayoría de las aplicaciones WEB, en realidad no se requiere una gran coherencia. Por lo tanto, sacrificar la coherencia a cambio de una alta disponibilidad es la dirección de la mayoría de los productos de bases de datos distribuidas actualmente.
Por supuesto, sacrificar la coherencia no significa ignorar por completo la coherencia de los datos. De lo contrario, los datos serán caóticos y no tendrán valor, sin importar cuán alta sea la disponibilidad del sistema y cuán bien distribuido. es.
Sacrificar la coherencia significa que ya no se requiere una fuerte coherencia en las bases de datos relacionales, pero siempre que el sistema pueda lograr la coherencia final, teniendo en cuenta la experiencia del cliente, esta ventana de tiempo de coherencia final debe ser lo más larga posible. ser transparente para los usuarios, es decir, es necesario garantizar "la coherencia percibida por los usuarios".
La alta disponibilidad del sistema y la eventual coherencia de los datos generalmente se logran mediante múltiples replicaciones asincrónicas de datos. La ventana de tiempo de "consistencia percibida por el usuario" depende de cuánto tiempo tardan los datos en llegar. replicarse a un estado constante.
Eventualmente consistente (eventualmente consistente)
En cuanto a la coherencia, se puede dividir en dos perspectivas diferentes: la del cliente y la del servidor.
Desde la perspectiva del cliente, la coherencia se refiere principalmente a la cuestión de cómo obtener datos actualizados durante múltiples accesos simultáneos.
Desde el lado del servidor, es cómo se copian y distribuyen las actualizaciones a todo el sistema para garantizar que los datos sean, en última instancia, coherentes.
La coherencia es un problema que ocurre solo debido a la lectura y escritura concurrentes. Por lo tanto, al comprender el problema de la coherencia, se debe prestar atención y considerar el escenario de lectura y escritura concurrentes.
Desde la perspectiva del cliente, cuando varios procesos acceden simultáneamente, diferentes estrategias para obtener datos actualizados en diferentes procesos determinan una consistencia diferente.
Para las bases de datos relacionales, se requiere que los datos actualizados puedan ser vistos por accesos posteriores, lo cual es una consistencia fuerte; si puede tolerar algunos o todos los accesos posteriores, es una consistencia débil; acceder a los datos actualizados después de un período de tiempo, es coherencia eventual.
Desde la perspectiva del servidor, cómo distribuir datos actualizados a todo el sistema lo más rápido posible y reducir la ventana de tiempo para lograr la coherencia final es un aspecto muy importante para mejorar la disponibilidad del sistema y la experiencia del usuario.
Entonces la pregunta es: ¿cómo lograr la máxima coherencia de los datos? La respuesta está en la arquitectura basada en eventos.
La mejor solución es adoptar una arquitectura basada en eventos. Uno de los desafíos encontrados es cómo actualizar el estado y publicar eventos de forma atómica. Hay varias formas de resolver este problema, incluido tratar la base de datos como una cola de mensajes y una fuente de eventos, etc.
A juzgar por el alcance y la madurez de la aplicación de la tecnología actual, se recomienda utilizar el primer método (publicación de eventos de transacciones locales) para lograr la entrega de eventos atómicos, es decir, una entrega de eventos confiable.
¿Cuáles son las diferencias entre SpringCloud y Dubbo?
En líneas generales, ambos tienen sus ventajas. Aunque la última función de llamada de servicio también evita los problemas causados por el RPC nativo mencionado anteriormente. Además, REST es más flexible que RPC. El proveedor de servicios y la persona que llama solo dependen de un contrato y no existe dependencia a nivel de código. Esto es más apropiado en un entorno de microservicios que enfatiza la rápida evolución.
La diferencia entre máquinas de marca y máquinas ensambladas: es obvio que SpringCloud es más potente y tiene una cobertura más amplia que dubbo, y puede integrarse perfectamente con otros proyectos Spring como SpringFramework, SpringBoot, SpringData, SpringBatch, etc., que son muy importantes para los microservicios Crucial. La arquitectura de microservicio construida con Dubbo es como ensamblar una computadora. Tenemos un alto grado de libertad para elegir cada enlace, pero la calidad general puede verse afectada por la calidad de la memoria, pero para los expertos esto no es un problema. SpringCloud es como una máquina de marca. Bajo la integración de Spring Source, ha realizado muchas pruebas de compatibilidad para garantizar que la máquina tenga una mayor estabilidad.
Al enfrentarse a la selección del marco de infraestructura de microservicios, Dubbo y SpringCloud solo pueden elegir uno de los dos.