Si un desarrollador de software no comprende la evolución de la arquitectura del software, restringirá la selección de tecnología y el espacio de supervivencia y promoción del desarrollador. Aquí he enumerado las cuatro arquitecturas de software principales y sus ventajas y desventajas, con la esperanza de ayudar a los desarrolladores de software a ampliar sus conocimientos.
1. Arquitectura monolítica La arquitectura
monolítica es relativamente rudimentaria, una arquitectura típica de tres niveles, front-end (Web / terminal móvil) + capa de lógica empresarial intermedia + capa de base de datos. Esta es una aplicación de marco Java Spring mvc o Python Drango típica. El diagrama de arquitectura es el siguiente:
Arquitectura monolítica
Las aplicaciones monolíticas son más fáciles de implementar y probar En las primeras etapas del proyecto, las aplicaciones monolíticas pueden funcionar bien. Sin embargo, a medida que la demanda sigue aumentando, cada vez más personas se unen al equipo de desarrollo y la base de código se expande rápidamente. Lentamente, las aplicaciones individuales se vuelven cada vez más infladas, la capacidad de mantenimiento y la flexibilidad se reducen gradualmente y los costos de mantenimiento son cada vez más altos. Estas son algunas de las desventajas de las aplicaciones monolíticas:
Alta complejidad: tome una aplicación de un millón de líneas como ejemplo. Todo el proyecto contiene muchos módulos, los límites de los módulos están borrosos, las dependencias no son claras, la calidad del código es desigual y se amontonan caóticamente. Es concebible que todo el proyecto sea muy complicado. Cada vez que modificas el código, te asustas, incluso agregar una función simple o modificar un error traerá defectos ocultos.
Deuda técnica: con el tiempo, los cambios en la demanda y la rotación de personal formarán gradualmente una deuda técnica de la aplicación, que se acumulará. "Sin daño, sin reparación", esto es muy común en el desarrollo de software, y esta idea es aún peor en aplicaciones monolíticas. El diseño o código del sistema utilizado es difícil de modificar porque otros módulos de la aplicación pueden utilizarlo de formas inesperadas.
Baja frecuencia de implementación: a medida que aumenta el código, también aumentará el tiempo de compilación e implementación. En una aplicación monolítica, cada cambio de función o reparación de defectos dará lugar a la necesidad de volver a implementar toda la aplicación. El método de implementación completa lleva mucho tiempo, tiene un amplio rango de impacto y presenta altos riesgos, lo que reduce la frecuencia de implementación en línea de un solo proyecto de aplicación. La baja frecuencia de implementación ha dado lugar a una gran cantidad de cambios de funciones y reparaciones de defectos entre las dos versiones, y la tasa de error es relativamente alta.
Baja confiabilidad: un error en una aplicación, como un bucle infinito, desbordamiento de memoria, etc., puede hacer que toda la aplicación se bloquee.
Escalabilidad restringida: una sola aplicación solo se puede extender como un todo y no se puede escalar de acuerdo con las necesidades de los módulos comerciales. Por ejemplo, algunos módulos de la aplicación son computacionalmente intensivos y requieren una CPU potente; algunos módulos son intensivos en E / S y requieren más memoria. Dado que estos módulos se implementan juntos, se deben hacer concesiones en la elección del hardware.
Obstruir la innovación tecnológica: las aplicaciones monolíticas a menudo utilizan una plataforma o solución tecnológica unificada para resolver todos los problemas. Cada miembro del equipo debe utilizar el mismo lenguaje y marco de desarrollo. Será muy difícil introducir nuevos marcos o nuevas plataformas tecnológicas.
2.
Arquitectura intermedia para aplicaciones distribuidas, aplicaciones distribuidas, distribución de nivel medio + base de datos distribuida, es una expansión simultánea de una sola arquitectura, un sistema grande se divide en múltiples módulos de negocios y los módulos de negocios se implementan en diferentes servidores. varios módulos comerciales intercambian datos a través de interfaces.
La base de datos también utiliza bases de datos distribuidas, como redis, ES y solor. A través de la aplicación de proxy LVS / Nginx, la carga de solicitudes de los usuarios se equilibra en diferentes servidores. El diagrama de arquitectura es el siguiente:
Arquitectura distribuida
En comparación con la arquitectura monolítica, esta arquitectura proporciona capacidades de equilibrio de carga, mejora en gran medida la capacidad de carga del sistema y resuelve los requisitos de alta concurrencia del sitio web.
También existen las siguientes características:
Acoplamiento reducido: divida los módulos y utilice la comunicación de interfaz para reducir el acoplamiento entre módulos.
Responsabilidades claras: dividir el proyecto en varios subproyectos, y diferentes equipos son responsables de diferentes subproyectos.
Extensión conveniente: al agregar funciones, solo necesita agregar otro subelemento y llamar a las interfaces de otros sistemas.
Fácil de implementar: la implementación distribuida se puede realizar de manera flexible.
Mejorar la reutilización del código: por ejemplo, la capa de servicio, si no se adopta la arquitectura de servicio de descanso distribuido, se escribirá una lógica de capa de servicio en cada extremo del centro comercial wap del teléfono móvil, centro comercial WeChat, pc, android e ios, y el La cantidad de desarrollo es grande. Es difícil de mantener y actualizar juntos. En este momento, el método de servicio de descanso distribuido se puede utilizar para compartir una capa de servicio.
Desventajas: La interacción entre sistemas requiere comunicación remota. El desarrollo de interfaces aumenta la carga de trabajo, pero las ventajas superan a las desventajas.
Además, preste atención a la pila de tecnología Java de la cuenta oficial y responda en segundo plano: Entrevista, puede obtener las preguntas y respuestas de la entrevista distribuida en Java que he compilado, que es muy completa.
3. Arquitectura de
microservicios La arquitectura de microservicios es principalmente la descomposición de la capa intermedia, que divide el sistema en muchas aplicaciones pequeñas (microservicios) Los microservicios se pueden implementar en diferentes servidores o en diferentes contenedores en el mismo servidor. Cuando la falla de la aplicación no afectará a otras aplicaciones, la carga de una sola aplicación no afectará a otras aplicaciones, sus frameworks representativos son Spring cloud, Dubbo, etc.
El diagrama de arquitectura es el siguiente: 
arquitectura de microservicio
Fácil de desarrollar y mantener: un microservicio solo se enfocará en una función comercial específica, por lo que tiene negocios claros y menos código. Es relativamente sencillo desarrollar y mantener un solo microservicio. La aplicación completa está construida por varios microservicios, por lo que toda la aplicación también se mantendrá en un estado controlable.
Un solo microservicio comienza más rápido: un solo microservicio tiene una pequeña cantidad de código, por lo que comienza más rápido.
La modificación parcial es fácil de implementar: siempre que se modifique una sola aplicación, la aplicación completa debe volver a implementarse. Los microservicios resuelven este problema. En términos generales, para modificar un microservicio, solo necesita volver a implementar el servicio.
Pila de tecnología sin restricciones: en la arquitectura de microservicios, la pila de tecnología se puede seleccionar razonablemente de acuerdo con las características del negocio y el equipo del proyecto. Por ejemplo, algunos servicios pueden usar la base de datos relacional MySQL; algunos microservicios tienen requisitos de computación gráfica y se puede usar Neo4j; incluso cuando sea necesario, algunos microservicios se pueden desarrollar usando Java, y algunos microservicios se pueden desarrollar usando Node.js.
Aunque los microservicios tienen muchos lugares atractivos, no son un almuerzo gratis y su uso tiene un precio. Desafíos en el uso de la arquitectura de microservicios.
Mayores requisitos de operación y mantenimiento: más servicios significan más inversión en operación y mantenimiento. En una arquitectura monolítica, solo se debe garantizar el funcionamiento normal de una aplicación. En microservicios, es necesario asegurar el funcionamiento normal y la colaboración de decenas o incluso cientos de servicios, lo que conlleva grandes retos de operación y mantenimiento.
La complejidad inherente de distribuido: el uso de microservicios para construir un sistema distribuido. Para un sistema distribuido, la tolerancia a fallas del sistema, el retraso de la red, las transacciones distribuidas, etc. traerán grandes desafíos.
Los costos de ajuste de la interfaz son altos: los microservicios se comunican a través de interfaces. Si modifica la API de un determinado microservicio, es posible que sea necesario ajustar todos los microservicios que utilizan la interfaz.
Trabajo duplicado: muchos servicios pueden usar la misma función, pero esta función no alcanza el nivel de descomposición en un microservicio. En este momento, cada servicio puede desarrollar esta función, lo que conduce a la duplicación de código. Aunque puede usar bibliotecas compartidas para resolver este problema (por ejemplo, puede encapsular esta función en un componente común y los microservicios que necesitan esta función se refieren al componente), es posible que la biblioteca compartida no funcione en un entorno multilingüe.
Además, preste atención a la pila de tecnología Java de la cuenta oficial y responda en segundo plano: Entrevista, puedo distribuir la serie Java de microservicios de preguntas y respuestas de entrevistas que he compilado, lo cual es muy completo.
4. Arquitectura sin servidor
Si bien todavía estamos avanzando en la ola de contenedores, algunos pioneros revolucionarios han establecido silenciosamente otro campo de batalla de la computación en la nube: la arquitectura sin servidor.
Arquitectura sin servidor
El 14 de noviembre de 2014, Amazon AWS lanzó un nuevo producto Lambda. En ese momento, Lambda se describió como: un servicio informático que ejecuta el código del usuario según el tiempo sin preocuparse por los recursos informáticos subyacentes. En cierto sentido, Lambda está muy atrasado, es como el concepto PaaS de computación en la nube: los clientes solo se preocupan por el negocio, sin preocuparse por los recursos de almacenamiento y computación. No mucho antes, el 22 de octubre de 2014, Google adquirió Firebase, un inicio de base de datos back-end en tiempo real. Firebase afirma que los desarrolladores solo necesitan consultar un archivo de biblioteca de API para leer y escribir datos utilizando varias interfaces de la API REST estándar. Solo necesitan escribir código de front-end HTML + CSS + JavaScrip, sin código del lado del servidor (si hay integración se requiere, es extremadamente simple).
En contraste con los dos anteriores, Parse, que Facebook adquirió en febrero de 2014, se enfoca en brindar un servicio de back-end común. Estos servicios se denominan sin servidor o sin servidor. Piense en PaaS (plataforma como servicio), ¿verdad? Al igual que, los usuarios no necesitan preocuparse por la infraestructura, solo necesitan preocuparse por los negocios. Esta es una PaaS tardía y una PaaS más práctica. Es probable que esto cambie todo el proceso de desarrollo y el ciclo de vida tradicional de la aplicación. Una vez que los desarrolladores se acostumbren a esta creación y asignación totalmente automática de recursos en la nube, es posible que nunca regresen a quienes necesitan recursos de configuración de microaplicaciones. se fueron.
La arquitectura Serverless permite a los desarrolladores evitar la necesidad de prestar atención a la adquisición y operación de recursos informáticos en el proceso de creación de aplicaciones. La plataforma asigna recursos informáticos a pedido y garantiza el SLA (acuerdo de nivel de servicio) para la ejecución de la aplicación, y la facturación es basado en el número de llamadas, que es efectivo Ahorre costos de aplicación. La arquitectura de ServerLess se muestra en la figura anterior. Las ventajas son las siguientes:
Bajos costos operativos: en un escenario con emergencias comerciales extremadamente altas, para hacer frente a los picos comerciales, el sistema debe construir un sistema que pueda hacer frente a los picos de demanda. Este sistema está inactivo la mayor parte del tiempo, lo que conduce a un grave desperdicio de recursos y los costos aumentan. En la arquitectura de microservicio, el servicio debe ejecutarse todo el tiempo. De hecho, en condiciones de alta carga, cada servicio tiene más de una instancia, por lo que se puede lograr una alta disponibilidad; en la arquitectura sin servidor, el servicio se facturará de acuerdo con el número de llamadas realizadas por el usuario, de acuerdo con la nube Calcula el principio de pago por uso, si no hay nada en funcionamiento, no tienes que pagar, lo que ahorra costos de uso. Al mismo tiempo, los usuarios pueden responder eficazmente a los picos comerciales compartiendo recursos informáticos como redes, discos duros y CPU, y mediante una expansión flexible durante los períodos comerciales pico y compartiendo recursos con otros usuarios durante los períodos pico comerciales, lo que ahorra costos de manera efectiva.
Simplifique el funcionamiento y el mantenimiento de los equipos: en el sistema de TI original, el equipo de desarrollo debe mantener las aplicaciones y la infraestructura de hardware al mismo tiempo; en la arquitectura sin servidor, los desarrolladores se enfrentarán al desarrollo de terceros o API y URL personalizadas. El hardware subyacente es transparente para los desarrolladores, y el equipo técnico ya no necesita centrarse en el trabajo de operación y mantenimiento, y puede centrarse más en el desarrollo de sistemas de aplicaciones.
Mejorar la capacidad de mantenimiento: en la arquitectura sin servidor, las aplicaciones llamarán a una variedad de servicios funcionales de terceros para formar la lógica final de la aplicación. En la actualidad, los servicios de terceros, como los servicios de autenticación de inicio de sesión y los servicios de base de datos en la nube, se han optimizado en gran medida en términos de seguridad, disponibilidad y rendimiento. El equipo de desarrollo integra directamente los servicios de terceros, lo que puede reducir eficazmente los costos de desarrollo y permitir las operaciones de las aplicaciones. El proceso de mantenimiento se ha vuelto más claro, mejorando efectivamente la mantenibilidad de la aplicación.
Velocidad de desarrollo más rápida: esto ahora se refleja bien en las nuevas empresas de Internet. Las nuevas empresas a menudo comienzan debido a problemas de personal y capital, y es imposible que cada línea de productos continúe al mismo tiempo. En este momento, se pueden considerar las plataformas Baas de terceros , Como el uso de autenticación de usuario de WeChat, RDS proporcionado por Alibaba Cloud, envío de mensajes de Aurora, pago de terceros y ubicación geográfica, etc., pueden desarrollar productos rápidamente, enfocarse en la realización comercial y hacer productos más rápidos para el mercado.
Pero la arquitectura ServerLess también tiene sus desventajas:
Vinculación de plataforma de proveedor: la plataforma proporcionará una arquitectura sin servidor para grandes jugadores, como AWS Lambda. Para ejecutarla, debe utilizar los servicios especificados por AWS, como API gateway, DynamoDB, S3, etc. Una vez que desarrolle un sistema complejo en Si se adhiere a AWS, tendrá que permitirles aumentar los precios o eliminarlos de los estantes en el futuro. Es difícil satisfacer las necesidades individuales y es imposible realizar una migración aleatoria o el costo de la migración es relativamente alto. , e inevitablemente traerá algunas pérdidas. Un incidente típico en la industria de Baas, el 19 de enero de 2016, Facebook cerró Parse, que solía gastar una gran cantidad de dinero para adquirir Parse, lo que provocó que los usuarios tuvieran que migrar a esta plataforma para generar más de un año de datos. lo que sin duda requiere mucha mano de obra y tiempo.
Hay relativamente pocos casos exitosos y no existen estándares de la industria: la situación actual solo es adecuada para el desarrollo de aplicaciones simples y carece de la promoción de casos exitosos a gran escala. La falta de un entendimiento unificado y los estándares correspondientes para Serverless hace que sea imposible adaptarse a todas las plataformas en la nube.
En la actualidad, la arquitectura de microservicios se encuentra en la corriente principal de las cuatro arquitecturas, y muchas empresas que utilizan la primera y la segunda arquitectura también han comenzado a recurrir lentamente a la arquitectura de microservicios. Hasta ahora, la tecnología de microservicios está relativamente madura en comparación con hace dos o tres años, y la cuarta arquitectura será una tendencia de desarrollo futuro.
Referencia: "¡Los últimos conceptos básicos de Java de 2020 y tutoriales en video detallados y rutas de aprendizaje! 》
Enlace original: https://zhuanlan.zhihu.com/p/343457113