Brevemente sobre los tipos de arquitecturas de software y cuál elegimos para el proveedor de IaaS

Existen muchos tipos de arquitecturas de software con sus ventajas y desventajas. A continuación, hablaremos sobre las características de los más populares y sobre nuestra transición a los microservicios.


/ libreshot / PD

Tipos de arquitecturas de software

Arquitectura en capas

Esta es una de las arquitecturas más comunes. Sobre esta base, se crean muchos marcos grandes: Java EE, Drupal, Express. Quizás el ejemplo más famoso de esta arquitectura es el modelo de red OSI .

El sistema está dividido en niveles, cada uno de los cuales interactúa con solo dos vecinos. Por lo tanto, las consultas a la base de datos, que generalmente se encuentra al final de la cadena de interacción, pasan secuencialmente a través de cada "capa".

La arquitectura no implica ningún número obligatorio de niveles: puede haber tres, cuatro, cinco o más. Con mayor frecuencia, se utilizan sistemas de tres niveles: con un nivel de presentación (cliente), un nivel lógico y un nivel de datos.


Se han escrito innumerables libros y artículos sobre arquitectura multinivel. Y hubo diferentes opiniones sobre sus ventajas y desventajas.

Pros:

Cada nivel de esta arquitectura realiza un conjunto estrictamente limitado de funciones (que no se repiten de capa a capa) y no sabe cómo se organizan los otros niveles. Por lo tanto, el "contenido" de los niveles se puede cambiar sin el riesgo de conflictos globales entre capas.

En general, las aplicaciones multinivel están tan extendidas que se crean generadores de plantillas especiales para su desarrollo. Por ejemplo, LASG para Visual Studio ofrece varios métodos de generación de código que automatizan las tareas de rutina y ayudan a construir niveles de aplicaciones.

Desventajas

En programación, hay un dicho que dice que cualquier problema puede resolverse agregando otro nivel de abstracción. Sin embargo, este enfoque puede conducir finalmente a una organización deficiente del código y confundir a los desarrolladores.

Otro problema surge de esto: baja velocidad. Una gran cantidad de información comienza a pasar inútilmente de una capa a otra, sin utilizar la lógica empresarial. Este problema a veces se denomina antipatrón de sumidero, un patrón de diseño cuando el número de operaciones inútiles comienza a prevalecer sobre las útiles.

Encontrar errores en sistemas de varios niveles también puede ser difícil . Antes de ingresar a la base de datos, la información pasa por todos los niveles (ya que la base de datos es el componente final). Si por alguna razón esta información está dañada (o se pierde en el camino), para encontrar un error, debe analizar cada nivel por separado.

Buen ajuste:

• Para crear nuevas aplicaciones que deben implementarse rápidamente. Este es un tipo de "plantilla de propósito general".
  
  

  Cuando comenzamos a trabajar en los sistemas internos de nuestro proveedor de infraestructura virtual en 1cloud , utilizamos este tipo particular de arquitectura. Al principio, no teníamos la tarea de crear un servicio IaaS capaz de procesar el tráfico de decenas o cientos de miles de usuarios. Decidimos lanzar rápidamente el producto en el mercado y comenzar a desarrollar una base de clientes y resolver los problemas de escalado a medida que estén disponibles (y ahora estamos transfiriendo todos los sistemas a una arquitectura de microservicio, que se discutirá más adelante).

  
  Entre los desarrolladores existe la opinión de que no es necesario desde los primeros días del proyecto prepararlo para cargas colosales (escriba software a prueba de futuro). Los requisitos reales para la aplicación o el servicio pueden diferir de las expectativas y los objetivos comerciales pueden cambiar . Por lo tanto, el código escrito teniendo en cuenta el futuro lejano corre el riesgo de convertirse en una deuda técnica.
• Según O'Reilly, la arquitectura en capas es una opción natural para muchas aplicaciones empresariales. Dado que las empresas (especialmente las grandes) a menudo comparten competencias: hay un equipo responsable del front-end, hay personas que son responsables del back-end, y así sucesivamente. Esto implica la división natural de las aplicaciones en niveles: algunos desarrolladores trabajan en el cliente, otros en la lógica.
  
  La ley de Conway , formulada en 1967, dicta una relación similar entre la estructura de la organización y los enfoques de desarrollo de aplicaciones. Se lee: "Al desarrollar un sistema, las organizaciones se ven obligadas a adherirse a un esquema que repite la estructura de las comunicaciones dentro de la empresa".

Arquitectura orientada a eventos

En este caso, el desarrollador prescribe el comportamiento (reacciones) para el programa cuando ocurre algún evento. Un evento en el sistema se considera un cambio significativo en su estado.

Puede hacer una analogía con la compra de un automóvil en la cabina. Cuando un automóvil encuentra un nuevo propietario, su condición cambia de "en venta" a "vendido". Este evento inicia el proceso de preparación previa a la venta: instalación de equipos adicionales, verificación del estado técnico, lavado, etc.

Un sistema controlado por eventos generalmente contiene dos componentes: orígenes de eventos (agentes) y sus consumidores (sumideros). Por lo general, también hay dos tipos de eventos: un evento de inicio y un evento al que responden los consumidores.

Un ejemplo de la implementación de dicha arquitectura es la biblioteca Java Swing. Si la clase necesita una alerta sobre un evento, el desarrollador implementa el llamado oyente - ActionListener ("atrapa" el evento correspondiente), y lo agrega al objeto que este evento puede generar.

El siguiente código de implementación para este mecanismo se proporciona en la Wiki:

public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } } 

Ventajas de la arquitectura:

Dado que las aplicaciones consisten en una gran cantidad de módulos asincrónicos (que no tienen información sobre la implementación de cada uno), son fáciles de escalar. Dichos sistemas se ensamblan como un constructor: no necesita registrar dependencias, solo implemente un nuevo módulo. Además, el modelo asincrónico permite un alto rendimiento de la aplicación.

Desventajas

La naturaleza asincrónica de tales aplicaciones complica la depuración. Un evento puede desencadenar varias cadenas de acciones a la vez. Si hay muchas de esas cadenas, puede ser difícil entender qué causó exactamente la falla. Para resolver el problema, tenemos que resolver las difíciles condiciones para el manejo de errores. A partir de aquí sigue el problema con el registro: los registros son difíciles de estructurar.

Apto para:

• Creación de sistemas asincrónicos. Esto es obvio porque la arquitectura en sí consiste en una gran cantidad de módulos asincrónicos.
• Se puede usar para crear una interfaz de usuario. Una página web actúa como un contenedor en el que cada uno de sus componentes está aislado y responde a ciertas acciones del usuario.
• Organizar mensajes entre varios sistemas de información.

Arquitectura de microkernel

Este tipo de arquitectura consta de dos componentes: el núcleo del sistema y los complementos. Los complementos son responsables de la lógica empresarial, y el núcleo gestiona su carga y descarga.


Como ejemplo de arquitectura de microkernel, el libro de O'Reilly proporciona un IDE de Eclipse. Este es un editor simple que abre archivos, les permite editarlos y ejecuta procesos en segundo plano. Pero con la adición de complementos (por ejemplo, el compilador de Java), su funcionalidad se expande.

La arquitectura de microkernel alguna vez utilizó el sistema operativo Symbian para dispositivos móviles (el desarrollo se detuvo en 2012). En su microkernel había un programador de tareas, sistemas de gestión de memoria y controladores, y el sistema de archivos y los componentes responsables de las comunicaciones telefónicas actuaban como complementos.

Ventajas de la arquitectura:

Es fácil portar una aplicación de un entorno a otro, ya que solo es necesario modificar el microkernel. La separación de las políticas de alto nivel y los mecanismos de bajo nivel simplifica el soporte del sistema y asegura su extensibilidad.

Desventajas

El rendimiento de la aplicación se reduce si conecta demasiados módulos. Sin embargo, puede ser problemático encontrar un equilibrio entre la cantidad de complementos y la cantidad de tareas de micronúcleos (por lo general, contiene solo código de uso frecuente).

También es difícil determinar de antemano (antes del desarrollo de la aplicación) el grado óptimo de fragmentación del código de micronúcleos. Y cambiar el enfoque más tarde es casi imposible.

Bueno para:

• Cree aplicaciones extensibles que sean utilizadas por una gran cantidad de personas. Por ejemplo, el iPhone OS tiene raíces de "microkernel": sus desarrolladores se inspiraron en Mach (este es uno de los primeros ejemplos de un microkernel).
• Creación de aplicaciones con una clara separación de métodos básicos y reglas de alto nivel.
• Desarrollo de sistemas con un conjunto de reglas dinámicamente cambiantes que deben actualizarse con frecuencia.

Microservicios

Similar a la arquitectura basada en eventos y al microkernel. Pero se utilizan cuando las tareas de aplicaciones individuales se pueden dividir fácilmente en pequeñas funciones: servicios independientes . Estos servicios se pueden escribir en diferentes lenguajes de programación porque se comunican entre sí mediante la API REST (por ejemplo, utilizando JSON o Thrift ).

En qué proporciones se divide el código, el desarrollador decide, pero Sam Newman, autor del libro " Creación de microservicios " , recomienda que asigne tantas líneas de código al microservicio como el equipo pueda reproducir en dos semanas. Según él, esto permitirá evitar la excesiva "hinchazón" de la arquitectura.

Muy a menudo, los microservicios se lanzan en los llamados contenedores. Estos contenedores son accesibles a través de la red para otros microservicios y aplicaciones, y el sistema de orquestación los administra a todos: los ejemplos incluyen Kubernetes, Docker Swarm, etc.

Ventajas:

La arquitectura de microservicios simplifica el escalado de la aplicación. Para implementar una nueva característica, simplemente escriba un nuevo servicio. Si la función ya no es necesaria, el microservicio se puede deshabilitar. Cada microservicio es un proyecto separado, por lo tanto, es fácil distribuir el trabajo en ellos entre los equipos de desarrollo.

Lea más sobre los mecanismos de escala de los sistemas de microservicios en el libro de Martin L. Abbott, The Art of Scalability.

Desventajas

Es difícil buscar errores. A diferencia de los sistemas monolíticos (cuando todas las funciones están en el mismo núcleo), puede ser difícil determinar por qué la solicitud "cayó". Para obtener detalles, debe ir a los registros del proceso de "culpabilidad" (si hay varios, el problema se agrava).

Esto crea una sobrecarga adicional para la transmisión de mensajes entre microservicios. Según nuestras estimaciones, el crecimiento de los costos de red puede alcanzar el 25%.

Otro inconveniente es la necesidad de soportar el concepto de consistencia eventual ( coherencia a largo plazo ). Los microservicios tienen sus propios almacenes de datos, a los que acceden otros microservicios. La información sobre los cambios a estos datos no se distribuye instantáneamente a través del sistema. Por lo tanto, surgen situaciones cuando algunos microservicios (aunque durante un período de tiempo extremadamente corto) tienen datos obsoletos.

Dónde usar

• En grandes proyectos con alta carga. Por ejemplo, los microservicios son utilizados por las plataformas de transmisión. Los sistemas de entrega de contenido y otros servicios de soporte se pueden escalar independientemente uno del otro, adaptándose a los cambios de carga.
• En sistemas que utilizan recursos "mixtos". Si una parte de la aplicación necesita más tiempo de procesador y la segunda, memoria, entonces tiene sentido dividirlos en microservicios. Luego se pueden alojar en diferentes máquinas, con una CPU potente o una gran cantidad de memoria, respectivamente.
• Cuando se necesita seguridad . Como los microservicios están aislados y se comunican por API, se puede garantizar que solo se transmitirá la información que un servicio en particular necesita. Esto es importante cuando se trabaja con contraseñas o datos de tarjetas de pago.

¿Por qué cambiamos a microservicios en 1cloud?

Como ya dijimos, la base de los servicios que brindamos ( nube privada , servidores virtuales , almacenamiento en la nube de objetos , etc.) se basa en una arquitectura de varios niveles. Ella se mostró del lado bueno, pero ahora su habilidad para escalar comenzó a agotarse.

Nos estamos convirtiendo en más y más socios que brindan sus soluciones basadas en nuestra plataforma de franquicias. Hay sitios y servicios remotos que se vuelven difíciles de administrar desde un solo punto (en particular, nuestro equipo está ubicado en varios centros de datos en Rusia, Kazajstán y Bielorrusia ).

Para facilitar la ampliación de las funciones existentes e introducir nuevas características, transferimos toda nuestra infraestructura a microservicios en 1cloud .



Queremos separarlos en módulos separados y, en lugar de una base de datos compleja, obtener N simples. Por lo tanto, en la nueva arquitectura, cada característica tendrá una base de datos separada. Es mucho más conveniente y eficiente en soporte y desarrollo.

Podremos dividir el trabajo en servicios entre varios desarrolladores (especializaciones destacadas en la empresa) y escalar de manera efectiva horizontalmente: cuando sea necesario, solo conectamos nuevos microservicios.

Nuestros clientes también recibirán una serie de ventajas. Dado que los microservicios no están conectados entre sí, cuando un servicio en particular falla, solo no estará disponible, el resto continuará funcionando normalmente. Además, incluso si ocurre una caída global en nuestro servicio, el panel de control continuará funcionando.

Los clientes de Kazajstán y Bielorrusia (y otros países donde abriremos oficinas de representación) notarán un aumento significativo en la velocidad y capacidad de respuesta de las interfaces, ya que los paneles de control se ubicarán localmente.

Lo que ya se ha hecho

Hasta ahora solo hemos implementado el primer piloto: "Servicio de Monitoreo". Los servicios restantes se transferirán a una nueva pista a fines de 2018, principios de 2019.

Al mismo tiempo, la nueva arquitectura sienta las bases tecnológicas para la siguiente etapa: la migración a contenedores. Ahora usamos la infraestructura de Windows, y para cambiar a contenedores, necesitamos reescribir todo el código acumulado en .NetCore y transferirlo a Linux.

Planeamos comenzar una nueva transición a principios de 2019 y terminarla a fines del próximo año.

¿Qué más estamos escribiendo en 1cloud Blog:

• 1cloud Cloud Architecture Evolution: desafíos de modulación
• Cómo IaaS ayuda a los franquiciados de 1C: experiencia 1cloud
• ¿Por qué es necesario el monitoreo?