Aprende Arquitectura desde Cero - Patrones de Arquitectura Extensible

Ideas básicas y patrones de patrones de arquitectura escalable

La mayor diferencia entre un sistema de software y un sistema de hardware y construcción es que el software es escalable. Una pieza de hardware no se cambiará después de que se produzca, y su estructura general no se cambiará después de que se complete un edificio. Por ejemplo, un La CPU se instalará después de que se produzca
. Para una PC, no hay vuelta atrás a la fábrica para el mecanizado para agregar nuevas características; la pirámide se ha mantenido durante miles de años y se ha desgastado, pero su estructura es la misma ahora que cuando fue construido.
Por el contrario, los sistemas de software son todo lo contrario: un sistema de software verdaderamente viable está en constante iteración y desarrollo. Un sistema operativo típico como Windows, desde Windows 3.0 a Windows 95 a Windows XP, hasta ahora Windows 10, se ha desarrollado constantemente con el desarrollo de la tecnología. Si un sistema de software se desarrolla sin actualizaciones ni ajustes, significa que el sistema de software no tiene desarrollo ni vitalidad.
Esta extensibilidad natural e inherente de los sistemas de software es tanto un encanto como una dificultad.

• El encanto se refleja en el hecho de que continuamente podemos hacer que el sistema de software tenga más funciones y características a través de modificaciones y expansiones, para satisfacer nuevas necesidades o seguir la tendencia del desarrollo tecnológico.
• La dificultad está en cómo expandir el sistema con el menor costo, porque en muchos casos está involucrado todo el cuerpo, y al expandirse, puede ser necesario cambiar por todas partes, y derribar todo y empezar de nuevo. El riesgo de hacerlo es evidente: cuantos más cambios se hagan, mayor será la inversión y mayor la posibilidad de errores.

Por lo tanto, cómo evitar un rango demasiado grande de cambios durante la expansión es la principal consideración en el diseño de escalabilidad de la arquitectura de software.

La idea básica de la extensibilidad.

Hay muchas maneras de diseñar arquitecturas escalables, pero siguen siendo las mismas. La idea básica detrás de todos los diseños de arquitectura escalable se puede resumir en una palabra: ¡demolición!
La demolición consiste en dividir el sistema unificado original en múltiples partes a pequeña escala, y solo modificar una parte de él cuando se expande, sin cambiar todo el sistema en todas partes. De esta manera, se puede reducir el alcance de los cambios y el riesgo de cambios.
De cara a los sistemas de software, el desmantelamiento no es tan simple, porque no queremos destruir un sistema de software, sino hacer que el sistema de software sea más hermoso (con una mejor escalabilidad) a través del desmantelamiento. Para decirlo en sentido figurado, la "demolición" en un sistema de software es constructiva, por lo que la dificultad es mucho mayor.
Dividir el sistema de software según diferentes ideas dará como resultado diferentes arquitecturas. Hay tres ideas divididas comunes de la siguiente manera:

• División orientada al proceso: divida todo el proceso comercial en varias etapas, cada etapa como una parte
• División orientada a servicios: dividir los servicios proporcionados por el sistema, cada servicio como una parte
• División orientada a funciones: división de las funciones proporcionadas por el sistema, cada función como una parte

La clave para comprender estas tres ideas radica en cómo entender la conexión y la diferencia entre "proceso", "servicio" y "función".
Desde la perspectiva del alcance, el orden de mayor a menor es: proceso > servicio > función. Puede ser difícil de entender simplemente a partir de la explicación conceptual, pero de hecho es muy claro después de ver algunos casos. Tome el TCP
/ Pila de protocolo IP como ejemplo:

• Proceso
  Corresponde al modelo de cuatro capas TCP/IP, porque el proceso de comunicación de la red TCP/IP es: capa de aplicación → capa de transporte → capa de red → capa física + enlace de datos, no importa cuál sea la capa de aplicación superior, este proceso no cambiar.
• Servicios
  Correspondientes a HTTP, FTP, SMTP y otros servicios en la capa de aplicación, HTTP brinda servicios web, FTP brinda servicios de archivos, SMTP brinda servicios de correo, etc.
• Funcionalidad
  Cada servicio proporciona una función correspondiente. Por ejemplo, el servicio HTTP proporciona funciones GET y POST, FTP proporciona funciones de carga y descarga, y SMTP proporciona funciones de envío y recepción de correo.
  Tomando como ejemplo un sistema simple de administración de información de estudiantes, el método dividido es:

1. Capa de presentación dividida orientada al proceso
   → capa comercial → capa de datos → capa de almacenamiento, el significado de cada capa es:
   capa de presentación : responsable del diseño de la página del usuario, diferentes empresas tienen diferentes páginas.
   Por ejemplo, las capas comerciales , como la página de inicio de sesión, la página de registro, la página de administración de información y la página de configuración de seguridad : responsables del procesamiento de la lógica comercial específica.
   Por ejemplo, capas de datos comerciales como inicio de sesión, registro, gestión de información y modificación de contraseña : responsables de completar el acceso a los datos. Por ejemplo, agregar, eliminar, modificar y consultar datos en la base de datos, registrar eventos en archivos de registro, etc.
   Capa de almacenamiento : responsable del almacenamiento de datos. Por ejemplo, la arquitectura final de la base de datos relacional MySQL y el sistema de almacenamiento en caché Memcache
   es la siguiente:
   

2. División orientada a servicios
   Divida el sistema en servicios tales como registro, inicio de sesión, administración de información, configuración de seguridad, etc. El diagrama de arquitectura final es el siguiente:
   

3. División orientada a funciones
   Cada servicio se puede dividir en más servicios de registro: proporcione múltiples formas de registro, incluidas tres funciones: registro de número de teléfono móvil, registro de tarjeta de identificación y registro de buzón de correo de estudiante.
   Servicio de inicio de sesión : incluye inicio de sesión con número de teléfono móvil, inicio de sesión con tarjeta de identificación e inicio de sesión con correo electrónico.
   Servicio de gestión de la información : incluida la gestión de la información básica, la gestión de la información del curso, la gestión de la información de los logros y otras funciones.
   Servicio de configuración de seguridad : incluye funciones detalladas como cambiar contraseñas, asegurar teléfonos móviles, recuperar contraseñas, etc., por ejemplo:
   

A través del caso del sistema de gestión de información de los estudiantes, se puede encontrar que los diagramas de estructura son muy diferentes en diferentes métodos de división. Pero parece que de cualquier manera, es alcanzable al final. Siendo ese el caso, ¿por qué deberíamos molestarnos en elegir, simplemente elegir uno al azar?

Por supuesto, no puede elegirlo al azar, de lo contrario, el diseño de la arquitectura no tendrá sentido y el arquitecto perderá su trabajo. La razón es que los diferentes métodos de división determinan esencialmente cómo se expande el sistema.

manera escalable

Cuando hablamos de escalabilidad, muchos estudiantes tendrán una duda: aunque el sistema no esté dividido, mientras el diseño y el código estén bien hechos, ¿no habrá problema de cambiar en todas partes? Por ejemplo, en el caso de la división orientada a servicios, agregar "registro de número de estudiante" puede controlar el alcance de la modificación incluso si no se divide en servicios, entonces, ¿por qué tenemos que dedicar mucho tiempo para dividir el sistema?
En un entorno ideal, tu equipo está lleno de expertos, todos los programadores son muy buenos y están familiarizados con el negocio, y los nuevos compañeros conocerán rápidamente todos los detalles... Entonces no hay problema si no hay división. Pero la realidad es que hay programadores novatos en el equipo, cambiar A para realizar la función o cambiar B para realizar la función depende completamente de lo que él crea que es fácil de cambiar; algunos programadores son descuidados; Genial; los nuevos colegas no. No sé por qué cierta línea de código en la historia es tan "repugnante", por lo que fácilmente la cambian para que sea más hermosa... Todos estos problemas pueden aparecer, y descubrirá en este momento que una división razonable, puede ser se aplican para garantizar que incluso si el programador comete errores, el alcance de los errores no será demasiado amplio y el impacto no será demasiado grande.
Las siguientes son las ventajas de los diferentes métodos de división cuando se trata de expansión.

1. División orientada al proceso
   En la mayoría de los casos, solo se necesita modificar una capa al expandirse y, en algunos casos, se pueden modificar las dos capas asociadas. No parecerá que todas las capas se deban modificar al mismo tiempo, por
   ejemplo , el sistema de gestión de información de los estudiantes, si expandimos la capa de almacenamiento de MySQL Para admitir MySQL y Oracle al mismo tiempo, solo es necesario expandir la capa de almacenamiento y la capa de datos, y no es necesario expandir la capa de presentación y la capa comercial ser cambiado
2. División orientada a servicios
   Para expandir un determinado servicio, o para agregar un nuevo servicio, solo necesita expandir los servicios relacionados sin modificar todos los servicios.
   También tome el sistema de administración de estudiantes como ejemplo, si necesitamos agregar un " "Registro de número de estudiante " función, solo necesita modificar el "Servicio de registro" y el "Servicio de inicio de sesión", y los servicios "Servicio de administración de información" y "Configuración de seguridad" no necesitan ser modificados
3. División orientada a funciones
   Para expandir una determinada función, o para agregar nuevas funciones, solo necesita expandir las funciones relevantes sin modificar todos los servicios.
   También tome el sistema de gestión de estudiantes como ejemplo. Si agregamos la función "registro de número de estudiante", entonces solo necesita agregar un nuevo módulo funcional al sistema y modificar el módulo de "función de inicio de sesión" al mismo tiempo, y otras funciones no se verán afectadas. Los diferentes
   métodos de división darán como resultado diferentes arquitecturas del sistema. Las arquitecturas típicas del sistema escalable incluyen:

• División orientada a procesos: arquitectura en capas
• División orientada a servicios: SOA, microservicios
• División orientada a funciones: arquitectura de micronúcleo

Por supuesto, estas arquitecturas de sistemas no son una u otra, pero se pueden usar en combinación en el diseño de arquitecturas de sistemas. Tomando el sistema de gestión de estudiantes como ejemplo, finalmente podemos diseñar la arquitectura de esta manera:
el sistema general adopta la arquitectura de "microservicio" en la división orientada al servicio y la divide en "servicio de registro", "servicio de inicio de sesión", " "servicio de gestión de la información" y "servicio de seguridad". Cada servicio es un subsistema que se ejecuta de forma independiente.
El propio subsistema del "servicio de registro" adopta una arquitectura en capas para la división de procesos.
El subsistema "login service" adopta la arquitectura "microkernel" orientada a la división de funciones.

Patrones tradicionales de arquitectura escalable: arquitectura en capas y SOA

En comparación con el rápido desarrollo de patrones de arquitectura de alto rendimiento y alta disponibilidad en las últimas décadas, se puede decir que el desarrollo de patrones de arquitectura escalable está vacilando. En los últimos años, el modelo de microservicio ardiente es uno de los pocos en la historia de
la desarrollo de modelos escalables. Esto también ha llevado a
que cuando hablamos de escalabilidad, debemos hablar de microservicios, e incluso la arquitectura de microservicio se ha convertido en una bala de plata para el diseño de arquitectura. El alto rendimiento también usa microservicios, y la alta disponibilidad también usa microservicios
. Parece alto, pero en realidad viola el "principio adecuado" y el "principio simple" del diseño de la arquitectura.
En la práctica, es mejor diseñar una arquitectura escalable. A continuación, presentaremos varios patrones de arquitectura escalable y señalaremos las ventajas de cada patrón de arquitectura Puntos clave y pros y contras.

arquitectura en capas

La arquitectura en capas es un patrón arquitectónico muy común, también se denomina arquitectura de N niveles, por lo general, N tiene al menos 2 capas. Por ejemplo, arquitectura C/S, arquitectura B/S. Los más comunes son la arquitectura de 3 capas (por ejemplo, MVC, arquitectura MVP), la arquitectura de 4 capas y la arquitectura de 5 capas son relativamente raras. Generalmente, los sistemas más complejos pueden alcanzar o superar las 5 capas, como el kernel del sistema operativo. arquitectura.
Al diseñar de acuerdo con la arquitectura en capas, se puede obtener una variedad de arquitecturas en capas diferentes de acuerdo con las diferentes dimensiones y objetos de división.

• 
  El objeto de la arquitectura C/S y la arquitectura B/S es todo el sistema comercial, y la dimensión de la división es la interacción del usuario, es decir, la parte que interactúa con los usuarios se separa en una capa, y el fondo que admite la interacción del usuario es otra capa Por ejemplo, el siguiente es un diagrama de estructura de arquitectura C/S
  

• El objeto de la arquitectura MVC y la arquitectura MVP
  es un subsistema empresarial único, y la dimensión de la división es la responsabilidad. Las diferentes responsabilidades se dividen en capas independientes, pero las dependencias de cada capa son más flexibles. Por ejemplo, las capas en la arquitectura MVC interactúan en pares:
  

• Arquitectura lógica en capas
  El objeto de la división puede ser un solo subsistema comercial o todo el sistema comercial, y la dimensión de la división también es responsabilidad. Aunque todos se basan en la división de responsabilidades, la diferencia entre la arquitectura lógica en capas y la arquitectura MVC y la arquitectura MVP es que las capas en la arquitectura lógica en capas son dependientes de arriba a abajo. Arquitectura típica del núcleo del sistema operativo y arquitectura TCP/IP. Por ejemplo, el siguiente es el diagrama de arquitectura del sistema operativo Android:
  
  La arquitectura típica del sistema J2EE también es una arquitectura lógica en capas. El diagrama de arquitectura es el siguiente: El
  
  diagrama de arquitectura para la estratificación lógica de todo el sistema comercial es el siguiente:
  
  es garantizar que las diferencias entre las capas sean lo suficientemente claras y los límites lo suficientemente claros, para que las personas puedan comprender la arquitectura completa después de ver el diagrama de la arquitectura , razón por la cual las capas no se pueden dividir en demasiadas capas. De lo contrario, si la diferencia entre las dos capas no es obvia, el programador Xiao Ming piensa que cierta función debe colocarse en la capa A, pero el programador Lao Wang piensa que la misma función debe colocarse en la capa B, lo que conducir a la confusión de capas. Si dicha arquitectura se pone en desarrollo real, entonces la capa A y la capa B se convertirán en un desastre, y se perderá el significado de las capas.

La razón por la que la arquitectura en capas puede soportar mejor la expansión del sistema radica en el aislamiento de preocupaciones (separación de preocupaciones), es decir, los componentes en cada capa solo procesarán la lógica de esta capa.
Por ejemplo, la capa de presentación solo necesita procesar la lógica de presentación, y la capa de negocios solo necesita procesar la lógica de negocios, de modo que cuando expandimos una determinada capa, otras capas no se verán afectadas. De esta manera, el sistema se puede expandir rápidamente. en una determinada capa. Por ejemplo, si desea agregar un nuevo sistema de archivos al kernel de Linux, solo necesita modificar la capa de almacenamiento de archivos y no es necesario cambiar otras capas del kernel.

Por supuesto, la simple estratificación no es suficiente para aislar las preocupaciones y admitir una rápida expansión. Al estratificar, es necesario asegurarse de que las dependencias entre capas sean estables para admitir realmente una rápida expansión. Por ejemplo, para admitir diferentes formatos de sistemas de archivos, el kernel de Linux abstrae la interfaz del sistema de archivos VFS. El diagrama de arquitectura es el siguiente. Si no hay VFS, los sistemas de archivos como ext2, ext3

y reiser simplemente se dividen en " capas del sistema de archivos", entonces esta capa no logra el propósito de soportar la escalabilidad. Porque después de agregar un nuevo sistema de archivos, todas las funciones basadas en el sistema de archivos deben adaptarse a la nueva interfaz del sistema de archivos; con VFS, solo VFS necesita adaptarse a la nueva interfaz del sistema de archivos y otras funciones basadas en el sistema de archivos. no verse afectado.

Otra característica de la estructura en capas es la transferencia capa por capa, es decir, una vez que se determina la capa, todo el proceso comercial se transfiere en secuencia de acuerdo con la capa y no es posible saltar entre capas.

En la estructura C/S más simple, el usuario primero debe usar la capa C, y luego la capa C se pasa a la capa S, y el usuario no puede acceder directamente a la capa S. En la arquitectura tradicional J2EE de 4 niveles, después de recibir la solicitud, la solicitud debe entregarse de la siguiente manera:

La ventaja de esta restricción de la estructura jerárquica es que las dependencias jerárquicas se ven obligadas a limitarse a dependencias por pares, lo que reduce la complejidad general del sistema.

Por ejemplo,
la capa de persistencia es la siguiente,

public class AvatarDao {
    
    
    public static String getAvatarUrl(int userId){
    
    
        // 具体实现代码 略
        return "http://avatar.csdn.net/xxx.jpg";
    }
}

La capa empresarial es la siguiente,

public class AvatarBizz {
    
    
    public static String getAvatarUrl(int userId){
    
    
        return AvatarDao.getAvatarUrl(userId);
    }
}

La capa de presentación es la siguiente,

public class AvatarView {
    
    
    public void displayAvatar(int userId) {
    
    
        String url = AvatarBizz.getAvatarUrl(userId);
        // 渲染代码略
        return;
    }
}

Por ejemplo, la capa empresarial depende de la capa de presentación y solo depende de la capa de persistencia. Pero el precio de la estructura en capas es la redundancia, es decir, por muy simple que sea el negocio, cada capa debe participar en el procesamiento, e incluso se puede escribir una función contenedora simple para cada capa. La ventaja de la arquitectura en capas es que las dependencias por pares se imponen y restringen mediante capas. Una vez que las capas se eligen libremente, la arquitectura se volverá caótica con el tiempo.

Por ejemplo, la capa de presentación accede directamente a la capa de persistencia y la capa de negocios accede directamente a la capa de base de datos. Al hacerlo, se pierde el significado de la arquitectura en capas y también conduce a la incapacidad de controlar el alcance del impacto durante las operaciones posteriores. expansiones Afecta a todo el cuerpo y no puede soportar una expansión rápida.
Además, aunque la implementación de la arquitectura en capas parece un poco detallada y redundante en algunos escenarios, la complejidad es muy baja.Otra
desventaja típica de la arquitectura en capas es el rendimiento, ya que cada solicitud comercial debe pasar por todas las La arquitectura está en capas, algunas cosas son redundantes y habrá un desperdicio de rendimiento

La llamada desventaja de rendimiento aquí es solo un análisis teórico. De hecho, la pérdida de rendimiento causada por la estratificación puede ser obvia en la década de 1980, pero ahora, el rendimiento
del hardware y las redes ha dado un salto cualitativo. De hecho, la estratificación El rendimiento la pérdida en la teoría del modo es insignificante en la mayoría de los escenarios en aplicaciones prácticas

SOA

El nombre completo de SOA es Arquitectura Orientada a Servicios, y la traducción al chino es "Arquitectura Orientada a Servicios". El trasfondo del surgimiento de SOA es la construcción repetida y la baja eficiencia de los sistemas de TI dentro de la empresa, que se reflejan principalmente en:

• Cada departamento de la empresa tiene sistemas de TI independientes, como sistemas de recursos humanos, sistemas financieros y sistemas de ventas. Todos estos sistemas pueden implicar la gestión de personal, y cada sistema de TI debe repetir las funciones de gestión de desarrolladores. Por ejemplo, después de que un empleado deja la empresa, es necesario eliminar el permiso del empleado en los tres sistemas anteriores, respectivamente.
• Cada sistema de TI independiente se puede comprar de diferentes proveedores con diferentes tecnologías de implementación, y es poco probable que la propia empresa se reconstruya basándose en estos sistemas.
• Con el desarrollo del negocio, la complejidad es cada vez mayor, y más procesos y negocios requieren la cooperación de múltiples sistemas de TI. Dado que no existe un método de implementación estándar para cada sistema de TI independiente (por ejemplo, el sistema de recursos humanos se desarrolla en Java y proporciona RPC al exterior; mientras que el sistema financiero se desarrolla en C# y proporciona el protocolo SOAP al exterior), cada Cada vez que se desarrolla un nuevo proceso y negocio, se requiere coordinación. Una gran cantidad de sistemas de TI se personalizan y desarrollan al mismo tiempo, lo cual es muy ineficiente.

Como respuesta a los problemas de los sistemas informáticos tradicionales, SOA propone 3 conceptos clave

Atender

Todas las funciones comerciales son un servicio, y servicio significa proporcionar capacidades abiertas al mundo exterior. Cuando otros sistemas necesitan usar esta función, no hay necesidad de un desarrollo personalizado. Los servicios pueden ser grandes o pequeños, simples o complejos.
Por ejemplo, la gestión de recursos humanos puede ser un servicio, incluida la gestión de información básica del personal, la gestión de licencias, la gestión de la estructura organizativa y otras funciones.
La gestión básica de la información del personal también se puede utilizar como un servicio independiente.
La gestión de estructuras organizativas también está disponible como un servicio independiente.
Si se divide en servicios de grano grueso o servicios de grano fino, debe juzgarse de acuerdo con la situación real de la empresa.

ESB

El nombre completo de ESB es Enterprise Service Bus, y la traducción al chino es "Enterprise Service Bus".
Como se puede ver en el nombre, ESB se refiere al concepto de bus de computadora.
El bus en la computadora conecta los diversos dispositivos entre sí, y el ESB conecta los diversos servicios en la empresa.
Debido a que cada servicio independiente es heterogéneo, si no existe un estándar unificado, las interfaces proporcionadas por cada sistema heterogéneo son diversas.
SOA utiliza ESB para proteger los sistemas heterogéneos de proporcionar varios métodos de interfaz externa, a fin de lograr una interconexión e intercomunicación eficiente entre los servicios.

débilmente acoplado

El propósito del acoplamiento flexible es reducir la dependencia y la influencia mutua entre varios servicios.
Porque después de adoptar la arquitectura SOA, cada servicio se ejecuta de forma independiente, y ni siquiera está claro cuánto depende un determinado servicio de otros servicios.
Si no se logra un acoplamiento flexible, una vez que se actualiza un determinado servicio, todos los demás servicios que dependen de él fallarán, lo que definitivamente no satisfará las necesidades comerciales.
De hecho, no es tan fácil lograr un bajo acoplamiento, es una tarea complicada lograr una retrocompatibilidad completa.

La arquitectura SOA es un concepto de diseño de arquitectura de nivel relativamente alto. En general, podemos decir que una empresa adopta la arquitectura SOA para construir sistemas de TI, pero no podemos decir que un sistema independiente adopta la arquitectura SOA. SOA resuelve la duplicación de los sistemas de TI tradicionales
. problema de ineficiencia en la construcción y escalado, pero eso en sí introduce más complejidad. La SOA más criticada es la ESB, que necesita implementar funciones como conversión de protocolo, conversión de datos y enrutamiento dinámico transparente con varios sistemas. La figura a continuación es el diagrama de flujo de ESB convirtiendo JSON a Java.

En la figura a continuación, ESB convierte el protocolo REST en dos protocolos diferentes: RMI y AMQP:

aunque ESB es poderoso, hay muchos protocolos en realidad, como JMS, WS , HTTP, RPC, etc. También hay muchos formatos de datos, como XML, JSON, binario, HTML, etc.
ESB necesita completar la conversión mutua de tantos protocolos y formatos de datos, la carga de trabajo y la complejidad son muy grandes, y esta conversión requiere mucho esfuerzo rendimiento informático.
Cuando ESB transporta demasiados mensajes, el propio ESB se convierte en el cuello de botella de rendimiento de todo el sistema.