SOA se propuso en el campo de la informática empresarial, que divide 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 conjunto 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. BPEL encarna el proceso de procesamiento comercial y es más intuitivo y fácil de ajustar que los códigos codificados.
Por supuesto, las empresas también necesitan servicios de gestión, como registro, seguimiento y gestión de servicios.
Sabemos que en el campo de la informática empresarial, si no es un sistema comercial, la concurrencia no es muy grande, por lo que en la mayoría de los casos, un servidor acomodará muchos servicios. Estos servicios utilizan una infraestructura unificada y. Todos pueden ejecutarse en un proceso de servidor de aplicaciones. Aunque está orientado a servicios, sigue siendo un sistema único.
La arquitectura de microservicios surge generalmente en las empresas de Internet. Debido a la gran cantidad de usuarios, los requisitos para los sistemas distribuidos son muy altos. Para que un sistema como la informática empresarial sea escalable, se requieren múltiples instancias del sistema para dar cabida a una gran cantidad de servicios. Frente a él, varios sistemas se convierten en un clúster mediante el equilibrio de carga. Sin embargo, esto es muy inconveniente. El ciclo de iteración de las empresas de Internet es muy corto. Se puede lanzar una versión cada semana o incluso una versión cada día. 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, utilizan bases de datos NOSQL como MongoDB, HBase y Cassandra y cachés distribuidos como Redis y Memcache. Luego tiende a dividirse en subsistemas y los diferentes subsistemas adoptan su propia arquitectura. Luego, cuando cada servicio se ejecuta en su propio contenedor web y necesita aumentar la potencia informática, solo necesita agregar una instancia de este subsistema o servicio y la actualización 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, que no han recibido 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, que pueden 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 de servicio. Puede aumentar la cantidad de instancias de servicio en cualquier momento o crear nuevas instancias de servicio en otras máquinas después de que una instancia falla.
¿Cómo dividir el servicio?
Divida los módulos de negocio con una granularidad que garantice la independencia e integridad del negocio de microservicios, con la menor cantidad posible de dependencias de servicio y llamadas en cadena. Pero en el proceso de desarrollo real, a veces una única arquitectura 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, al comienzo del diseño, podemos diseñar el servicio para que sea más granular y considerar su escalabilidad. A medida que el negocio se desarrolla, la división dinámica también es una buena opción.
En nombre del descanso se omite el tema. "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. Puede señalarlo con un URI (localizador uniforme de recursos) y cada recurso corresponde a un URI específico. Para obtener este recurso, simplemente acceda a su URI, de modo que el URI se convierta 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, en el protocolo HTTP existen cuatro verbos que indican modos de operación: GET, POST, PUT y DELETE.
Corresponden a cuatro operaciones básicas: GET se usa para obtener recursos, POST se usa para crear nuevos recursos (o actualizar recursos), PUT se usa para actualizar recursos y DELETE se usa para eliminar recursos.
De hecho, no todo es “recurso”, especialmente en los sistemas empresariales. Las desventajas son las siguientes:
Existe una interfaz para actualizar el estado del pedido. ¿Cuál se usa arriba? Parece que debería ponerse, pero la ruta es PUT /tickets/12.
A veces tengo múltiples interfaces para actualizar el estado de cobro del pedido, el estado de pago del pedido y el estado de liquidación del pedido;
El camino de Restful es obviamente hostil e insuficiente;
Para Otro ejemplo, ¿qué sucede si desea pasar una matriz en forma de DELETE/tickets/12 # DELETE tice kt 12? ¿La dirección del sitio web no es lo suficientemente amigable?
Para otro ejemplo, Resuful requiere GET /tickets # para obtener boletos. Una vez tuvimos el requisito de que el ID del pedido que nos envió la otra parte no excediera 1000. Nuestro sistema filtró algunos pedidos especiales, este también es un servicio de consulta; Obtenga boletos en forma de GET /tickets #. El ID del pedido de 1000 obviamente excede la longitud de la URL GET, lo cual no es apropiado 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 la siguiente: systemAlias/controller/action.
Reglas resumidas:
Intente usar GET para consultas simples. La ventaja es que puede copiar directamente la ruta de la API con parámetros de consulta;
se usa POST. para consultas complejas y actualizaciones. Más utilizado;
No utilice PUT y DELETE ya que añade complejidad sin ningún beneficio.
Mirando muchas de las openapi de BAT, también dicen relajante, pero no se siguen estrictamente. Ambos son obtener y publicar, razón por la cual muchas personas no saben poner y eliminar.
Por ejemplo:
//Obtenga el pedido según la identificación del pedido.
¿Obtener oms/order/queryOrderById? id=valor1. param2 =valor 2
//Obtener pedidos según la lista de ID de pedido.
Publicar OMS/orders/queryOrderByIdList
//Consultar pedidos según condiciones, con parámetros de paginación.
Publicar OMS/pedido/consultar condiciones de pedido
//Actualizar estado de recopilación de pedidos
Publicar OMS/order/updateOrderCollectionStatus
// Estado de recopilación de pedidos de actualización por lotes
Publicar OMS/order/updateOrderCollectionStatusInBatch
//Estado de recopilación de pedidos de actualización por lotes
Publicar OMS/order/updateOrderCollectionStatusInBatch
//Eliminar pedidos con fuentes de proceso en lotes.
Publicar oms/order/deleteOrderInBatch
¿Cómo gestiona el microservicio la base de datos?
Principio del límite superior (Teorema del límite superior)
En 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 teorema del sombrero, pero este sombrero no es otro sombrero. El principio de la PAC tiene tres elementos:
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, se deben hacer concesiones al diseñar una arquitectura distribuida. Para los sistemas de datos distribuidos, la tolerancia a la partición es un requisito básico; de lo contrario, perderá valor, por lo que el diseño de los sistemas de datos distribuidos debe lograr un equilibrio entre coherencia y disponibilidad.
Para la mayoría de las aplicaciones WEB, la coherencia no es necesaria, por lo que sacrificar la coherencia por la 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 la disponibilidad del sistema será mayor y luego se distribuirá.
Sacrificar la coherencia significa que ya no se requiere una fuerte coherencia en las bases de datos relacionales, siempre que el sistema pueda lograr una coherencia eventual. Teniendo en cuenta la experiencia del cliente, esta ventana de tiempo final consistente debe ser lo más transparente posible para los usuarios, es decir, garantizar la "coherencia de la percepción del usuario".
Por lo general, la alta disponibilidad del sistema y la eventual consistencia de los datos se logran a través de múltiples copias asincrónicas de los datos, y la ventana de tiempo de "consistencia percibida por el usuario" depende de los datos que se copian. un tiempo de estado consistente.
Eventualmente consistente
La coherencia se puede dividir en dos perspectivas diferentes: cliente y 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 la perspectiva del servidor, es cómo se copian y distribuyen las actualizaciones a todo el sistema para garantizar la coherencia final de los datos.
La coherencia es un problema causado por la lectura y la escritura simultáneas, por lo que al comprender los problemas de coherencia, debe prestar atención y considerar el escenario de lectura y escritura simultáneas.
Desde la perspectiva del cliente, cuando varios procesos acceden simultáneamente, diferentes estrategias sobre cómo los diferentes procesos obtienen datos actualizados 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 que algunos o todos los accesos posteriores no estén disponibles, es una consistencia débil si es un período; de tiempo Es necesario acceder a los datos actualizados más tarde, lo que eventualmente es coherente.
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 utilizar una arquitectura basada en eventos. Uno de los desafíos es cómo actualizar automáticamente el estado y publicar eventos. Hay varias formas de resolver este problema, incluido tratar la base de datos como una cola de mensajes y una fuente de eventos.
Desde la perspectiva del alcance de la aplicación y la madurez de la tecnología actual, se recomienda utilizar el primer método (publicación de eventos de transacciones locales) para lograr la atomización de la entrega de eventos, es decir, una entrega confiable de eventos.
¿Cuál es la diferencia entre SpringCloud y Dubbo?
En general, ambos tienen sus ventajas. Aunque este último cumple la función de llamada, también evita los problemas causados por el RPC nativo mencionado anteriormente. Además, REST es más flexible que RPC. La dependencia entre el proveedor de servicios y la persona que llama solo se basa en un contrato en papel y no existe una dependencia a nivel de código. Es más adecuado en el contexto de enfatizar la rápida evolución de los microservicios.
La diferencia entre máquina de marca y máquina de ensamblaje: es obvio que SpringCloud es más potente y tiene una cobertura más amplia que dubbo. Puede integrarse perfectamente con otros proyectos Spring como SpringFramework, SpringBoot, SpringData y SpringBatch. Todos estos son adecuados para microservicios. La arquitectura de microservicio construida con Dubbo es como ensamblar una computadora. Tenemos un alto grado de libertad en cada enlace, pero la calidad general siempre puede verse afectada por la calidad de la memoria, pero no es un problema para los expertos. SpringCloud es como una máquina de marca. Con la integración de la fuente del resorte, se han realizado una gran cantidad de pruebas de compatibilidad para garantizar una mayor estabilidad de la máquina.
Ante la elección de la infraestructura de microservicios, Dubbo y SpringCloud solo pueden elegir una u otra.