Habilidades avanzadas en diseño de arquitectura de sistemas · Teoría y práctica del diseño de arquitectura orientada a servicios

Haga clic para ingresar al directorio de series de artículos.

1. Conceptos relacionados de SOA

1.1Definición de SOA

A partir de la definición de los principios básicos del software, se puede considerar que SOA es un modelo de componente que conecta diferentes unidades funcionales de una aplicación (llamadas servicios) a través de interfaces y contratos bien definidos entre estos servicios. La interfaz se define de forma neutral y debe ser independiente de la plataforma de hardware, sistema operativo y lenguaje de programación en el que se implementa el servicio. Esto permite que los servicios integrados en una variedad de dichos sistemas interactúen de una manera unificada y común.

1.2 Proceso de negocio y lenguaje de ejecución de procesos de negocio

Procesos de negocio y lenguaje de ejecución de procesos de negocio (Business Process Execution Language, BPEL) . El proceso de negocio se refiere a un proceso o una serie de acciones realizadas para lograr un determinado propósito comercial. Con BPEL, los usuarios pueden implementar una arquitectura orientada a servicios de arriba a abajo componiendo, orquestando y coordinando servicios web. Actualmente, BPEL se utiliza para integrar los servicios web existentes y organizar los servicios web existentes en un nuevo servicio web de acuerdo con los procesos comerciales requeridos, sobre esta base se forma un servicio que es igual a un solo servicio del mundo exterior.

2. Historia del desarrollo de SOA

(1) Etapa embrionaria : este uso generalizado de XML permite a las organizaciones definir los metadatos de los documentos, permitir el intercambio electrónico de datos dentro y entre empresas y especificar el formato y la estructura del intercambio de datos entre servicios y dentro de los servicios.

(2) Etapa de estandarización : Estándares y especificaciones internacionales: Protocolo simple de acceso a objetos (SOAP), Lenguaje de descripción de servicios web (Descripción de servicios web, UDDI).

(3) Etapa madura : 3 especificaciones de peso pesado: SCA, SDO, WS-Policy. SCA y SDO forman la base del modelo de programación SOA y WS-Policy establece las especificaciones para interacciones seguras entre componentes SOA.

3. La diferencia entre SOA y microservicios

(1) Los microservicios son más sofisticados que SOA: existen más como procesos independientes y no se influyen entre sí.

(2) El método de interfaz proporcionado por los microservicios es más universal, como el método HTTP RESTful, que puede ser llamado por varios terminales independientemente de las restricciones de idioma y plataforma.

(3) Los microservicios se inclinan más por métodos de implementación distribuidos y descentralizados, que son más adecuados en escenarios comerciales de Internet.

A continuación se muestra un cuadro comparativo entre la arquitectura SOA y la arquitectura de microservicios:

3. Arquitectura de referencia SOA

La arquitectura de referencia de integración empresarial Websphere de IBM es una arquitectura típica de integración empresarial centrada en servicios, que se puede dividir en seis categorías :

(1) Servicio de Lógica de Negocios.
(2) Servicio de Control.
(3) Servicio de Conectividad.
(4) Servicio de Innovación y Optimización Empresarial.
(5) Servicio de Desarrollo.
(6) Gestión de Servicios TI.

4. Especificaciones del protocolo principal de SOA

Como sigue, basado en el protocolo de servicio web:

(1) Protocolo UDDI : protocolo unificado de descripción, descubrimiento e integración. Contiene una especificación estándar para la descripción y el descubrimiento de servicios, que permite a las entidades comerciales descubrirse entre sí; define cómo interactúan en Internet y comparten información en una arquitectura de registro global.

(2) Lenguaje de descripción de servicios web (WSDL) : WSDL es un lenguaje XML que se utiliza para describir servicios web y explicar cómo comunicarse con servicios web. Describe 3 atributos básicos de los servicios web:

• Qué hace el servicio: las operaciones (métodos) proporcionadas por el servicio.
• Cómo acceder al servicio: el formato de datos y los protocolos necesarios para interactuar con el servicio.
• Dónde se encuentra el servicio: una dirección relacionada con el protocolo, como una URL.
  El siguiente es el marco estructural básico del documento:
  

(3) Protocolo SOAP : SOAP es un protocolo simple para el intercambio de información en un entorno descentralizado o distribuido, es un protocolo basado en XML.
(4) Especificación REST : para permitir que diferentes software o aplicaciones transfieran información entre sí en cualquier entorno de red. Los microservicios están expuestos a las personas que llaman en forma de API REST. RESTful es la forma de REST. Es un término general para un tipo de diseño arquitectónico o aplicación que sigue las ideas de diseño REST mientras satisface las restricciones de diseño. Este tipo puede denominarse RESTful, que puede entenderse como una transferencia de estado expresiva de recursos:

• Recursos : todas las transacciones expuestas a los clientes en Internet pueden considerarse un recurso.
• Representación : La representación se utiliza en REST para describir el estado de los recursos en un momento determinado en la Web.
• Transferencia de estado : dividida en dos tipos,
  estado de la aplicación : una instantánea de la información relacionada con la sesión solicitada por el usuario dentro de un cierto período de tiempo, guardada en el cliente.
  Estado del recurso : guardado en el servidor, es una instantánea de la representación de la solicitud de recurso en un momento determinado.
• Hipervínculos : establezca conexiones con otros recursos incorporando enlaces en sus páginas.

5. Requisitos del estándar de diseño SOA

(1) Estandarización de documentos .
Los servicios SOA tienen documentos XML autodescriptivos independientes de la plataforma. El lenguaje de descripción de servicios web es un lenguaje estándar para describir servicios.

(2) Estándares de protocolo de comunicación .
Los servicios SOA se comunican mediante mensajes, que normalmente se definen mediante un esquema XML (también conocido como definición de esquema XML, XSD).
(3) Registro unificado e integración de aplicaciones .
Dentro de una empresa, los servicios SOA se mantienen a través de un registro que desempeña el papel de Listado de Directores. La aplicación busca y llama a un servicio en el Registro. La descripción, definición e integración unificadas son los estándares para el registro de servicios.
(4) Calidad de servicio (Qos) . incluyen principalmente:

• Fiabilidad : características de transmisión al transmitir documentos entre consumidores de servicios y proveedores de servicios (y solo transmitir una vez, transmitir como máximo una vez, repetir filtrado de mensajes, entrega garantizada de mensajes)
• Seguridad : las especificaciones de seguridad del servicio web se utilizan para garantizar la seguridad de los mensajes.
• Políticas : los proveedores de servicios a veces requieren que los consumidores de servicios se comuniquen con una determinada política. Por ejemplo, un proveedor de servicios puede exigir a los consumidores que proporcionen un token de seguridad Kerberos para obtener un determinado servicio.
• Control : En SOA, los procesos se crean utilizando un conjunto discreto de servicios. BPEL4WS o WSBPEL (Web Service Business Process Execution Language) es el lenguaje utilizado para controlar estos servicios.
• Gestión : debe haber un sistema de gestión unificado para todos los servicios que se ejecutan en múltiples entornos para que los administradores del sistema puedan gestionarlos de forma eficaz. Cualquier servicio implementado basado en WSDM se puede gestionar mediante una solución de gestión compatible con WSDM.

6. El papel y los principios de diseño de SOA.

(1) La función principal de SOA: romper islas de información y convertir aplicaciones y recursos en servicios. Y convierta estos servicios en servicios estándar para compartir recursos.
(2) Los principios de diseño de SOA incluyen principalmente:

• Apátrida .
  Evitar que el solicitante del servicio dependa del estado del proveedor del servicio.
• Instancia única .
  Utilice un método de implementación altamente cohesivo para evitar la redundancia funcional.
• Interfaz bien definida .
  La interfaz de un servicio está definida por WSDL, que se utiliza para indicar el límite entre la interfaz pública del servicio y su implementación privada interna.
• Autónomo y modular .
  Los servicios encapsulan aquellas actividades y componentes que son estables y recurrentes en los negocios. Las entidades funcionales que implementan los servicios son completamente independientes y pueden implementarse, versionarse, autogestionarse y restaurarse de forma independiente.
• De grano grueso .
  La cantidad de servicios no debe ser demasiado grande y depender de la interacción de mensajes en lugar de la llamada a procedimiento remoto (RPC). Por lo general, el volumen de mensajes es grande, pero la frecuencia de interacción entre servicios es baja.
• Acoplamiento flojo entre servicios .
  Lo que ven los usuarios del servicio es la interfaz del servicio. Su ubicación, tecnología de implementación y estado actual no son visibles para los usuarios. Los datos privados del servicio no son visibles para los usuarios del servicio.
• Interoperabilidad, compatibilidad y declaraciones de políticas .
  Para garantizar que la especificación del servicio sea completa y clara, se utilizan políticas para definir una semántica de interoperabilidad configurable para describir las expectativas de servicios específicos y controlar su comportamiento. Aproveche las declaraciones de políticas para garantizar la integridad y claridad con respecto a las expectativas de servicio y la compatibilidad semántica.

7. Patrones de diseño SOA

7.1 Modo de registro de servicios

El registro de servicios respalda el desarrollo, la publicación y la gestión de contratos de servicios, políticas y metadatos que impulsan la gobernanza SOA.
(1) Registro de servicios : los desarrolladores de aplicaciones, también llamados proveedores de servicios, publican sus funciones en el registro.
(2) Ubicación del servicio : es decir, los desarrolladores de aplicaciones de servicios les ayudan a consultar los servicios de registro y encontrar servicios que cumplan con sus propios requisitos.
(3) Vinculación del servicio : el consumidor del servicio utiliza el contrato de servicio recuperado para desarrollar código. El código desarrollado está vinculado al servicio registrado, llama al servicio registrado e interactúa con él.

7.2 Modelo de bus de servicios empresariales (EBS)

El modelo de bus de servicios empresariales proporciona una arquitectura subyacente de software estándar. Varios componentes del programa se pueden "insertar" en la plataforma como unidades de servicio y pueden interactuar entre sí en un método de comunicación de mensajes estándar . Sus funciones principales son las siguientes:

(1) Servicios de enrutamiento y direccionamiento de mensajes que brinden transparencia de ubicación. Los componentes del programa no necesitan prestar atención al enrutamiento y direccionamiento de los demás.
(2) Proporcionar funciones de gestión para el registro y denominación de servicios.
(3) Admite múltiples especificaciones de mensajería (como solicitud/respuesta, publicación y suscripción).
(4) Admite una variedad de protocolos de transmisión ampliamente utilizados.
(5) Admite múltiples formatos de datos y su conversión mutua.
(6) Proporcionar funciones de registro y monitoreo.

Como se muestra a continuación, diagrama EBS :

7.3 Modelo de microservicio

Arquitectura de microservicios Dividir una gran aplicación o servicio único en múltiples microservicios le permite escalar componentes individuales en lugar de toda la pila de aplicaciones para cumplir con los acuerdos de nivel de servicio. La arquitectura de microservicio divide los servicios en áreas de negocio. Cada servicio puede desarrollarse, gestionarse e iterarse de forma independiente. Se comunican entre sí mediante una interfaz unificada, realizando funciones de implementación, gestión y servicio en componentes dispersos, lo que facilita la entrega del producto. Se vuelve más sencillo divida eficazmente las aplicaciones y logre un desarrollo e implementación ágiles. Las características del modelo de microservicio son las siguientes:
(1) Desacoplamiento de aplicaciones complejas : la arquitectura de microservicio descompone una aplicación de un solo módulo en múltiples microservicios manteniendo la funcionalidad general sin cambios.
(2) Independiente : los microservicios se desarrollan, prueban e implementan de forma independiente en el ciclo de vida del software del sistema.
(3) Selección de tecnología flexible : la selección de tecnología de las aplicaciones del sistema bajo la arquitectura de microservicio está descentralizada. Cada equipo de desarrollo puede elegir la arquitectura y la tecnología del sistema adecuadas en función de las necesidades comerciales de su propia aplicación.
(4) Tolerancia a fallas : cada microservicio es independiente entre sí, las fallas se aislarán en un solo servicio y otros microservicios en el sistema pueden lograr la tolerancia a fallas de la capa de aplicación a través de mecanismos como el reintento y la degradación suave, mejorando así la tolerancia a fallas de aplicaciones del sistema.
(5) Acoplamiento flexible y fácil expansión : Cada servicio en la arquitectura de microservicios está débilmente acoplado y se puede expandir de forma independiente según las necesidades reales, lo que refleja la flexibilidad de la arquitectura de microservicios. El diagrama esquemático de la arquitectura de aplicaciones monolíticas y la arquitectura de microservicios es el siguiente:

7.4 Solución de modelo de arquitectura de microservicio

La solución del modelo de arquitectura de microservicios incluye principalmente:
(1) Microservicio agregador : el agregador actúa como un comandante de procesos y llama a múltiples microservicios para implementar las funciones requeridas por las aplicaciones del sistema.
(2) Microservicios encadenados : después de que el cliente o servidor recibe una solicitud, se producirán llamadas recursivas anidadas entre múltiples servicios y se devolverá una respuesta procesada.
(3) Microservicios de intercambio de datos : este modelo es adecuado para la etapa de transición de la arquitectura monolítica a la arquitectura de microservicios. Se permiten fuertes relaciones de acoplamiento entre servicios, como múltiples microservicios que comparten caché y almacenamiento de bases de datos.
(4) Microservicios de mensajería asincrónica : para algunas lógicas comerciales que no necesitan ejecutarse de manera sincrónica, se pueden usar colas de mensajes en lugar de REST para implementar solicitudes y respuestas para acelerar la velocidad de respuesta de las llamadas de servicio.

A continuación, arquitectura monolítica y arquitectura de microservicios:

7.5 Problemas y desafíos que enfrenta la arquitectura de microservicios

(1) El descubrimiento de servicios y el seguimiento de la cadena de llamadas de servicios se vuelven difíciles.
(2) Es difícil lograr una gran coherencia en las bases de datos tradicionales y, en cambio, se busca una coherencia eventual.

8. Cuestiones a las que se debe prestar atención al construir una arquitectura SOA

(1) Los requisitos de integración en la arquitectura del sistema original incluyen: requisitos de integración de aplicaciones, requisitos de integración de interfaz de usuario del terminal, requisitos de integración de procesos y requisitos de integración de información del sistema existente.

(2) El control de la granularidad del servicio y el diseño de servicios sin estado se expresan de la siguiente manera:

• Control de granularidad del servicio : se recomienda utilizar interfaces de grano grueso para servicios que estarán expuestos fuera de todo el sistema, mientras que las interfaces de servicio relativamente finas generalmente se usan dentro de la arquitectura del sistema empresarial.
• Diseño de servicios sin estado : Los servicios específicos en la arquitectura del sistema SOA deben ser solicitudes independientes y autónomas. Al implementar estos servicios, no se requiere el estado de la solicitud anterior, lo que significa que los servicios no deben depender del contexto de otros servicios. Y estado, es decir, los servicios en la arquitectura SOA deberían ser servicios sin estado.

9. Proceso de implementación de SOA

(1) Seleccione soluciones SOA principalmente de los siguientes tres aspectos:

• Intente elegir un plan que permita una planificación general.
• A la hora de elegir, tenga plenamente en cuenta las necesidades de la propia empresa.
• Realizar inspecciones desde aspectos técnicos como plataforma e implementación.

(2) El análisis de procesos de negocio se centra principalmente en:

• Establecer modelo de servicio :
  método de descomposición de arriba hacia abajo, método de análisis de objetivos comerciales, método de análisis ascendente.
• Establecer procesos de negocio :
  establecer objetos de negocio (objetos de negocio como entidades, procesos, eventos, etc.), establecer interfaces de servicio y establecer procesos de servicio.

Haga clic para ingresar al directorio de series de artículos.