prefacio
Al principio, decidí entender todas las cosas mencionadas en el artículo, al igual que escribí varios artículos sobre ByteByteGo, entendí cada oración. Pero para "Phoenix Architecture", esto es demasiado lento e innecesario. Es posible que algunas cosas nunca se usen, pero el artículo mencionará esas cosas para presentar completamente un contenido. Así que todavía tomo algunas notas adicionales para algunas de mis propias preguntas o cosas que quiero saber.
Mi idea inicial era resumir el artículo en forma de blog, pero en el proceso, me resultó difícil resumir. Cada oración del libro es necesaria. Este libro está realmente seco y lleno de cosecha.
Resumir
La era distribuida original: el rendimiento de las computadoras es muy insuficiente y se lleva a cabo una exploración preliminar de la distribución.
Era del sistema monolítico: para los sistemas de pequeña escala, es fácil de desarrollar, probar e implementar; para los sistemas de gran escala, su mayor problema no es inseparable y difícil de expandir, porque seguirá el principio de la arquitectura en capas como un todo , código También se dividirá según módulos y funciones para reutilizar y administrar códigos, y se pueden implementar múltiples métodos como Jar, War u otros para cumplir con los requisitos de expansión a través del equilibrio de carga. Su verdadero problema es, en primer lugar, que no puede detener la propagación de errores, cualquier error en cualquier parte del código puede afectar a todo el programa, en segundo lugar, no es conveniente para las actualizaciones dinámicas y es imposible detener y actualizar un cierto módulo por separado, y la mantenibilidad es pobre; La tercera es que no es fácil lograr la heterogeneidad técnica, y es necesario usar el mismo lenguaje o incluso la misma arquitectura. Hay otra razón fundamental para promover microservicios para reemplazarlo, de hecho, es un cambio en el pensamiento, del original "perseguir el menor error posible" a "los errores son inevitables". Permitir errores es la mayor ventaja de los microservicios.
Era SOA: también llamada arquitectura orientada a servicios, basada en la forma de invocación de servicios remotos, también lleva a cabo una exploración integral de lo distribuido, presenta principios rectores muy claros, resuelve con éxito los principales problemas en el entorno distribuido y también propone el desarrollo de software. metodología. No solo presta atención a la tecnología, sino que también presta atención al proceso de investigación y desarrollo. Pero sus defectos son que la especificación es demasiado estricta, la complejidad es demasiado grande y la universalidad no es fuerte, por lo que al final falló.
La era de los microservicios: una sola aplicación se construye a través de la combinación de múltiples servicios pequeños, con características como gobierno descentralizado, tecnología heterogénea, invocación remota, pensamiento orientado al producto, similar al desarrollo ágil, donde todos no solo están desarrollando, sino también prueba, operación y mantenimiento, etc.; Descentralización de datos; terminal fuerte y canalización débil, mecanismo de comunicación simplificado, usando estilo RESTful; tolerancia a fallas y evolución; automatización, etc., lo que hace que el desarrollo de software sea más libre. La desventaja es que sin especificaciones y restricciones unificadas, la dificultad del diseño de la arquitectura del software aumenta considerablemente.
Era posterior a los microservicios: en la era de los microservicios, las personas resuelven problemas distribuidos a nivel de código de software y, en la era posterior a los microservicios, el uso de Kubernetes puede implementar directamente capacidades de administración detalladas distribuidas a nivel de hardware, eliminando así los problemas técnicos que nada que ver con los negocios El problema se elimina del nivel de software, por lo que el desarrollo de software solo puede enfocarse en los negocios.
Era sin servicio: la visión de la ausencia de servicio es que los desarrolladores solo necesitan concentrarse exclusivamente en el negocio, sin considerar los componentes técnicos, cómo implementar, la potencia de cómputo o la operación y el mantenimiento, todos los cuales son atendidos por el negocio de computación en la nube completado. Sin embargo, la tecnología actual no está muy madura y aún no es competente para problemas como la lógica empresarial compleja y la dependencia del estado del servidor.
contenido principal
Historia de la evolución de la arquitectura del servicio:
-
La era distribuida original:
en los primeros días, el rendimiento de las computadoras era muy insuficiente. Para mejorar el rendimiento y la potencia informática de las computadoras, algunas exploraciones de distribución, como dónde están los servicios remotos (descubrimiento de servicios), cuántos ( equilibrio de carga), partición de red, tiempo de espera o error de servicio (fusible, aislamiento, degradación), cómo expresar parámetros de método y devolver resultados (protocolo de serialización), cómo transmitir información (protocolo de transporte) y cómo administrar permisos de servicio (autenticación , autorización), cómo garantizar la seguridad de la comunicación (capa de seguridad de la red), cómo llamar a los servicios de diferentes máquinas para devolver el mismo resultado (consistencia de datos distribuidos), etc., proponen muchas teorías que serán muy influyentes en el futuro. -
La era de los sistemas monolíticos:
según la definición de Wikipedia, "Monolito significa autónomo. Una aplicación monolítica describe un software de una sola capa compuesto por diferentes componentes de la misma plataforma tecnológica".
En primer lugar, los beneficios de un solo sistema pequeño son obvios, fáciles de desarrollar, probar e implementar, y debido a que el proceso de llamada de cada función, módulo y método en el sistema es una llamada en proceso, no hay procesos entre procesos. se producirá la comunicación, y todos los módulos y llamadas a métodos No hay necesidad de considerar las particiones de red, la replicación de objetos y la pérdida de rendimiento. Por lo tanto, la eficiencia de la operación es muy alta.
En cuanto a la falta de un sistema único, debe ser que los requisitos de rendimiento del software superan el independiente, y la escala de los desarrolladores de software obviamente supera el "2 Pizza Team" (un cuantificador para medir el tamaño del equipo propuesto por el fundador de Amazon, lo que significa que dos Pizzas pueden alimentar El número de personas que están llenas (alrededor de 6 a 12 personas) es de valor para la discusión.
Para un gran sistema monolítico, la gente dirá que es indivisible y difícil de expandir, por lo que no puede admitir una escala de software cada vez mayor. Esta idea es en realidad sesgada. Desde un punto de vista vertical, sigue una arquitectura en capas. Las solicitudes externas recibidas se transmitirán entre capas en diferentes formas de estructuras de datos, y responderán en orden inverso después de tocar la última base de datos; desde un punto de vista horizontal. La arquitectura monolítica también admite la división del software en varios módulos de acuerdo con las dimensiones de la tecnología, la función y la responsabilidad, a fin de reutilizar y administrar el código. El sistema monolítico no significa que solo pueda haber una forma de paquete de programa general. , sino puede estar completamente compuesto de múltiples Jar, War u otros formatos de módulos. En la forma de equilibrio de carga, se implementan varias copias del mismo sistema único al mismo tiempo para lograr el efecto de compartir la presión del tráfico. Esta también es una extensión muy común . Sus problemas reales son en realidad los siguientes puntos:
1) Es difícil que un monómero bloquee la propagación de errores. Después de la escisión, no se puede lograr la autonomía y el aislamiento. Los defectos en cualquier parte del código tendrán un impacto global que es difícil de aislar y luego afectará a todo el programa, como pérdidas de memoria, explosiones de subprocesos, bloqueos y bucles infinitos. Incluso si el problema son algunos recursos públicos de nivel superior, como el número de puerto o la fuga del grupo de conexiones de la base de datos, también afectará el trabajo normal de toda la máquina o incluso otras copias individuales en el clúster. (Como se mencionó anteriormente, con múltiples Wars y Jars expandidos horizontalmente, si un Jar se rompe, ¿los otros también se romperán? No se trata de esto, sino del monómero real) 2) No es conveniente actualizar dinámicamente
el programa . No se puede aislar (se puede usar OSGi, pero es muy complicado) y también significa que es imposible detener, actualizar y actualizar una parte determinada del código por separado. Por lo tanto, la capacidad de mantenimiento es deficiente y no es propicio para la liberación en escala de grises y las pruebas A/B.
3) Enfrentar la dificultad de la heterogeneidad técnica . La dificultad del aislamiento también conduce al hecho de que el código de cada módulo generalmente debe desarrollarse utilizando el mismo lenguaje de programación, o incluso el mismo marco de programación (JNI puede permitir que Java mezcle C o C ++, pero esto suele ser un último recurso y no una elección elegante).
Los problemas enumerados anteriormente no son la causa raíz de la tendencia actual de reemplazar los sistemas monolíticos con microservicios. El autor cree que la razón más importante es: el concepto subyacente de este estilo arquitectónico es esperar que cada parte del sistema, cada pieza de código Todos son lo más fiables posible, y se puede construir un sistema fiable teniendo pocos o ningún defecto. Sin embargo, no importa cuán bueno sea el nivel táctico, es difícil compensar la falta de nivel estratégico.La idea de confiar en la alta calidad para garantizar una alta confiabilidad puede funcionar bien en software de pequeña escala, pero cuanto mayor sea el escala del sistema, la entrega de un monómero confiable El sistema se vuelve cada vez más desafiante. Es precisamente con la evolución de la arquitectura de software y el cambio en el concepto de construir un sistema confiable de "perseguir la menor cantidad de errores posible" a enfrentar "los errores son inevitables" que la arquitectura de microservicios puede desafiar y gradualmente comenzar a reemplazar la arquitectura monolítica. que ha estado en funcionamiento durante décadas, donde reside la confianza.
Esta es una ventaja cuando la escala del sistema es pequeña, pero cuando la escala del sistema es grande o el programa debe modificarse, el costo de su implementación y los costos de migración para las actualizaciones de tecnología serán más altos. Para permitir que el programa cometa errores, para obtener la capacidad de aislamiento y autonomía, y para lograr la heterogeneidad técnica, es la razón para que el programa elija distribuirse nuevamente después del rendimiento y la potencia informática. -
Era SOA:
el nombre chino es Arquitectura Orientada a Servicios (Service-Oriented Architecture). Para dividir un solo sistema grande, cada subsistema se puede implementar, ejecutar y actualizar de forma independiente. Antes de la llegada de SOA, los desarrolladores hemos probado muchos arquitecturas, las siguientes son tres arquitecturas representativas:
1) arquitectura chimenea, que se refiere a un patrón de diseño que no interopera ni se coordina con otros sistemas de información relacionados en absoluto. Usando empresas y departamentos como ejemplo, ¿hay realmente un departamento en la empresa que no interactúe en absoluto? Además, tal sistema de "división independiente" y "vejez y muerte independientes" es obviamente imposible de ver para las empresas.
2) Arquitectura de micronúcleo: en la arquitectura de chimenea, los sistemas sin relación comercial también pueden necesitar compartir algunos datos maestros públicos, como personal, organizaciones, permisos, etc., por lo que también podría poner estos datos maestros, junto con otros subsistemas que puede ser utilizado por cada subsistema Los servicios públicos, los datos y los recursos utilizados se reúnen para convertirse en un núcleo en el que confían comúnmente todos los sistemas comerciales Los sistemas comerciales específicos existen en forma de módulos complementarios, que pueden proporcionar escalabilidad, características flexibles y naturalmente aisladas. , la arquitectura microkernel.
Este patrón es muy adecuado para aplicaciones de escritorio y, a menudo, también se usa en aplicaciones web. Sin embargo, la arquitectura de microkernel también tiene sus limitaciones y requisitos previos. Se supone que los módulos de complementos en el sistema no se conocen entre sí y es impredecible qué módulos se instalarán en el sistema. Por lo tanto, estos complementos pueden acceder a algunos recursos públicos en el kernel, pero no interactuarán directamente. Sin embargo, ya sea que se trate de un sistema de información empresarial o de una aplicación de Internet, esta premisa no se cumple en muchos escenarios. Debemos encontrar una manera no solo de dividir los sistemas independientes, sino también de permitir una comunicación fluida entre los subsistemas divididos. comunicar.
3) Arquitectura basada en eventos: para permitir que los subsistemas se comuniquen entre sí, una solución factible es establecer un conjunto de conductos de cola de eventos entre los subsistemas. Los mensajes desde fuera del sistema se enviarán a la canalización en forma de eventos, y cada subsistema obtendrá los mensajes de eventos que le interesen y necesite procesar desde la canalización. Según esto, cada controlador de mensajes es independiente y está muy desacoplado, pero puede interactuar con otros controladores a través de la canalización de eventos.
Después de eso, la invocación de servicios remotos marcó el comienzo del nacimiento del protocolo SOAP, basado en esto, el software entró oficialmente en la era SOA. Ante los problemas de la era futura de los microservicios, la mayoría de los cuales son también dificultades previsibles cuando se propusieron por primera vez los servicios distribuidos, SOA ha llevado a cabo exploraciones más sistemáticas y específicas.
"Más específico" se refleja en que, si bien SOA tiene una mayor operatividad, existen principios rectores claros para el diseño de software, como encapsulación de servicios, autonomía, acoplamiento flexible, reutilización, componibilidad, falta de estado, etc.; El protocolo de la llamada; utilizar el canalización de mensajes llamada Enterprise Service Bus (ESB) para realizar la interacción de comunicación entre los diversos subsistemas, y así sucesivamente. Con el apoyo de todo este conjunto de componentes técnicos que pueden cooperar estrechamente entre sí, si se juzga únicamente desde la perspectiva de la viabilidad técnica, se puede considerar que SOA resuelve con éxito los principales problemas técnicos en el entorno distribuido.
"Más sistemático" se refiere al gran ideal de SOA. Su objetivo final es resumir un conjunto de metodología de desarrollo de software de arriba hacia abajo, con la esperanza de que las empresas puedan resolver el proceso de desarrollo de software en un paquete solo siguiendo la idea de SOA. Además, SOA no solo presta atención a la tecnología, sino que también presta atención a los requisitos, la gestión, el proceso y la organización involucrados en el proceso de investigación y desarrollo.
Pero una definición de especificación demasiado estricta trae consigo una complejidad excesiva. Y muchas superestructuras como ESB y BPM construidas sobre la base de SOAP agravan aún más esta complejidad. Después de todo, el desarrollo de sistemas de información no es una escritura estereotipada, los procesos y teorías demasiado sofisticados requieren profesionales que comprendan conceptos complejos para poder controlarlos. Puede realizar una integración e interacción complejas entre múltiples sistemas heterogéneos a gran escala, pero es difícil promoverlo como un estilo de arquitectura de software ampliamente aplicable. Tampoco funcionó al final. -
La era de los microservicios:
los microservicios son un estilo arquitectónico para crear una sola aplicación a través de la composición de múltiples servicios pequeños, que se construyen en torno a las capacidades comerciales en lugar de estándares técnicos específicos. Cada servicio puede usar diferentes lenguajes de programación, diferentes tecnologías de almacenamiento de datos y ejecutarse en diferentes procesos. El servicio adopta un mecanismo de comunicación ligero y un mecanismo de implementación automatizado para lograr la comunicación, la operación y el mantenimiento. Tiene las siguientes características:
1) Construir en torno a las capacidades comerciales, lo que también enfatiza la importancia de la Ley de Conway. Cuando una organización diseña un sistema, estará limitado por la estructura de comunicación de la organización, por lo que el producto debe ser el epítome de la estructura de comunicación de su organización; 2) Gobernanza descentralizada , los microservicios son más Se enfatiza que cuando la heterogeneidad técnica es realmente necesaria, uno debería tener el derecho de elegir la "no unificación"; 3) Realizar componentes independientes y autónomos a través de servicios. La razón por la que enfatizamos la creación de componentes a través de "Servicio" en lugar de "Biblioteca" es porque la biblioteca de clases está vinculada estáticamente al programa en tiempo de compilación y proporciona funciones a través de llamadas locales, mientras que el servicio es un componente fuera de proceso. funciones a través de llamadas remotas; 4) pensamiento de producto, en el pasado, bajo la arquitectura única, la escala del programa determinaba que era imposible que todo el personal prestara atención al producto completo, y habría una división detallada del trabajo en la organización, como desarrollo, operación y mantenimiento, y soporte. Miembros, todos solo se enfocan en su propio trabajo, pero bajo los microservicios, es factible que todos en el equipo de desarrollo piensen en el producto y se preocupen por todos los aspectos de todo el producto; 5) Descentralización de datos, microservicios El servicio aboga claramente por que los datos se gestionen, actualicen, mantengan y almacenen de forma descentralizada. En un único servicio, cada módulo funcional de un sistema suele utilizar la misma base de datos. Es cierto que El almacenamiento centralizado es inherentemente más fácil de evitar problemas de consistencia.Sin embargo, la forma abstracta de la misma entidad de datos es a menudo diferente desde la perspectiva de diferentes servicios. Por ejemplo, para los libros en la tienda, el enfoque está en el precio en el campo de ventas, la cantidad de inventario en el campo de almacenamiento y la información de introducción de los libros en el campo de visualización del producto.Si se usa como almacenamiento centralizado , todos los campos deben modificarse y se asignan a la misma entidad, lo que hace posible que diferentes servicios se afecten entre sí y pierdan su independencia. Aunque es bastante difícil lidiar con el problema de la consistencia en un entorno distribuido, a menudo es imposible utilizar el procesamiento de transacciones tradicional para garantizarlo, pero el menor de los dos males es que aún vale la pena pagar algunos costos necesarios;6) terminal fuerte tubería débil , tubería débil es casi un nombre directo contra SOAP y ESB Un montón de mecanismos de comunicación complejos, estas funciones integradas en la tubería de comunicación pueden ser necesarias para una parte determinada del servicio en un sistema determinado, pero es una carga impuesta para más servicios. Si el servicio necesita las capacidades de comunicación adicionales anteriores, debe resolverse en el propio Endpoint del servicio, en lugar de un paquete en la canalización de comunicación. Los microservicios abogan por un método de comunicación simple y directo similar a los filtros UNIX clásicos. La comunicación de estilo RESTful será una opción más adecuada en los microservicios; 7) El diseño tolerante a fallas requiere que haya un mecanismo automático para que los servicios de los que depende puedan realizar una detección rápida de fallas. , aislar cuando los errores persisten y volver a conectar cuando se restauran los servicios; 8) Diseño evolutivo, el diseño tolerante a fallas admite que los servicios funcionarán mal, y el diseño evolutivo admite que los servicios serán desechados por desuso. Un servicio bien diseñado debe poder desecharse, no se espera que viva para siempre. Si existen servicios inmutables e irremplazables en el sistema, esto no significa cuán excelente e importante es el servicio, sino más bien una muestra de la fragilidad del diseño del sistema.La independencia y autonomía que persiguen los microservicios también va en contra de la manifestación de esta vulnerabilidad. ; 9) Automatización de la infraestructura, la automatización de la infraestructura, como el rápido desarrollo de CI/CD, reduce significativamente la complejidad del trabajo de construcción, liberación y operación y mantenimiento. Debido a que los objetos de operación y mantenimiento bajo microservicios tienen un aumento de orden de magnitud en comparación con la arquitectura única, los equipos que usan microservicios dependen más de la automatización de la infraestructura y es difícil para los humanos brindar soporte a cientos, miles o incluso decenas de miles. de servicios. . El rápido desarrollo de , reduce significativamente la complejidad de los trabajos de construcción, lanzamiento, operación y mantenimiento. Debido a que los objetos de operación y mantenimiento bajo microservicios tienen un aumento de orden de magnitud en comparación con la arquitectura única, los equipos que usan microservicios dependen más de la automatización de la infraestructura y es difícil para los humanos brindar soporte a cientos, miles o incluso decenas de miles. de servicios. . El rápido desarrollo de , reduce significativamente la complejidad de los trabajos de construcción, lanzamiento, operación y mantenimiento. Debido a que los objetos de operación y mantenimiento bajo microservicios tienen un aumento de orden de magnitud en comparación con la arquitectura única, los equipos que usan microservicios dependen más de la automatización de la infraestructura y es difícil para los humanos brindar soporte a cientos, miles o incluso decenas de miles. de servicios. .
De las definiciones y características anteriores de los microservicios, debería ser obvio que los microservicios persiguen un estilo arquitectónico más libre, abandonando casi todas las restricciones y regulaciones que se pueden descartar en SOA. Sin embargo, si no hay una especificación y una restricción unificadas, ¿no reaparecerán repentinamente los problemas de los servicios distribuidos resueltos por SOA en el pasado? De hecho, ya no habrá una solución unificada para estos problemas en los microservicios. Incluso si solo discutimos los microservicios que se utilizarán en el ámbito de Java, solo un problema de llamada remota entre servicios puede incluirse en la lista de soluciones candidatas: RMI (Sun/Oracle), Thrift (Facebook), Dubbo (Alibaba), gRPC (Google), etc.
La libertad que brindan los microservicios es un arma de doble filo, por un lado, corta los complejos estándares técnicos establecidos por SOA, un servicio simple no necesariamente enfrenta todos los problemas en distribución al mismo tiempo, es decir, hay no hay necesidad de llevar la pesada carga técnica de SOA como una bolsa de tesoros Cualquiera que sea el problema que deba resolverse, cualquier herramienta que se introduzca. Por otro lado, debido a esta libertad, la dificultad del diseño de la arquitectura de software se ha incrementado considerablemente. -
Era posterior a los microservicios:
en la era de los microservicios, las personas eligen resolver estos problemas distribuidos a nivel de código de software en lugar de a nivel de infraestructura de hardware, en gran parte porque la infraestructura compuesta por hardware no puede seguir el ritmo de la infraestructura compuesta por software. La flexibilidad de los servicios de aplicaciones es un movimiento impotente. El software se puede dividir en diferentes servicios solo mediante el uso de comandos de teclado, y el servicio se puede escalar y expandir solo mediante la copia y el inicio. ¿No es posible que el hardware cambie el servidor de aplicaciones, el equilibrador de carga, el servidor DNS y la red correspondientes? tecleando en el teclado?¿Vincular estas instalaciones? (Es decir, deje que el software solo considere el negocio.
La solución a este problema es el contenedor. Sin embargo, el contenedor inicial solo se puede usar como un entorno operativo de servicio de inicio rápido. El propósito es facilitar la distribución y el despliegue de el programa. En esta etapa, está empaquetado para una sola aplicación El contenedor realmente no participa en la solución de problemas distribuidos. El cambio real proviene del desarrollo exitoso de Kubernetes. La siguiente figura muestra la comparación entre la solución técnica de Kubernetes para resolver problemas distribuidos y la solución de microservicio tradicional. Aunque los métodos y efectos de resolución de problemas son diferentes debido a sus diferentes puntos de partida, esto sin duda proporciona una forma nueva y más prometedora de resolver problemas.
Cuando el hardware virtualizado puede mantenerse al día con la flexibilidad del software, los problemas técnicos que no tienen nada que ver con el negocio pueden eliminarse del nivel del software y resolverse silenciosamente dentro de la infraestructura del hardware, lo que permite que el software se concentre solo en el negocio. Desde el nivel de software para tratar de forma independiente varios problemas causados por la arquitectura distribuida, hasta la era del código de aplicación y la infraestructura, la integración de software y hardware, y los esfuerzos conjuntos para hacer frente a los problemas de arquitectura, ahora los medios lo denominan "nativo de la nube". , que es bastante abstracto, para promocionar el nombre.
Sin embargo, Kubernetes aún no ha podido resolver a la perfección todos los problemas distribuidos: "imperfecto" significa que Kubernetes puro no es tan bueno como la solución Spring Cloud anterior desde un punto de vista funcional. Esto se debe a que algunos problemas se encuentran en el borde del sistema de aplicaciones y la infraestructura, lo que hace que sea realmente difícil ajustarlos a nivel de infraestructura. Por ejemplo, el microservicio A llama a dos servicios del microservicio B, llamados B1 y B2, suponiendo que B1 se comporta normalmente pero B2 tiene un error continuo de 500, luego B2 debe fusionarse después de alcanzar un cierto umbral, para evitar un efecto de avalancha. Si solo se maneja a nivel de infraestructura, se encontrará con un dilema, cortar la ruta de la red de A a B afectará la llamada normal de B1, si no se corta, seguirá afectado por el error de B2.
Los problemas anteriores no son difíciles de manejar en microservicios implementados por código de aplicación como Spring Cloud. Dado que el código del programa se usa para resolver el problema, siempre que sea lógico, las funciones que desea lograr solo están limitadas por la imaginación del desarrollador. y tecnología capacidades, pero la infraestructura se administra para todo el contenedor, y la granularidad es relativamente aproximada, solo hasta el nivel del contenedor, lo que dificulta la administración y el control efectivos de un solo servicio remoto.
Para solucionar este tipo de problemas, se presenta el "Sidecar Proxy" (Sidecar Proxy), que hoy en día se denomina "Service Mesh", se refiere a la inyección de un servidor proxy de comunicaciones en el Pod de Kubernetes, que toma el relevo silenciosamente. toda comunicación externa de la aplicación sin que la aplicación sea consciente de ello. Además de realizar la comunicación normal entre servicios (llamada comunicación del plano de datos), este agente también recibe instrucciones del controlador (llamada comunicación del plano de control) y analiza y procesa el contenido de la comunicación del plano de datos de acuerdo con la configuración en el plano de control. Para lograr varias funciones adicionales, como ruptura de circuitos, autenticación, medición, monitoreo y balanceo de carga. De esta forma, no es necesario agregar códigos de procesamiento adicionales a nivel de la aplicación, y también proporciona capacidades de gestión fina que son casi nada menos que los códigos de programa.
Es difícil juzgar conceptualmente si un servicio proxy que se ejecuta en el mismo contenedor de recursos que el sistema de la aplicación debe considerarse software o infraestructura, pero es transparente para la aplicación y la gobernanza del servicio se puede realizar sin cambiar ningún código de software. Aísle los problemas técnicos como "qué protocolo de comunicación elegir", "cómo programar el tráfico", "cómo autenticar y autorizar" del código del programa y reemplace las funciones de la mayoría de los componentes en el cubo de la familia Spring Cloud actual. consider business Basado en su propia lógica, esta es la solución de terminal inteligente ideal. -
La era del no-servicio:
Aún no existe una definición "oficial" particularmente autorizada de no-servicio, pero su concepto no es tan complicado como el de las arquitecturas anteriores. Originalmente, el no-servicio también se basa en "simple" como su principal estrategia de venta. punto, y solo involucra dos piezas de contenido: instalaciones y funciones de back-end.
Las instalaciones de back-end se refieren a bases de datos, colas de mensajes, registros, almacenamiento, etc., que se utilizan para respaldar el funcionamiento de la lógica comercial, pero no tienen significado comercial. Estas instalaciones de back-end se ejecutan todas en la nube. Para "backend como un servicio".
La función se refiere al código de lógica empresarial. El concepto y la granularidad de la función aquí son muy similares a la función desde la perspectiva de la codificación del programa. La diferencia es que la función en ningún servicio se ejecuta en la nube, y no hay necesidad de considerar poder de cómputo o planificación de la capacidad Llámelo "funciones como un servicio".
La visión de serverless es que los desarrolladores solo necesitan concentrarse únicamente en el negocio y no necesitan considerar los componentes técnicos. Los componentes técnicos de back-end están listos y se pueden usar directamente sin los problemas de adquisición, derechos de autor y selección de modelos; no es necesario considerar cómo implementar, el proceso de implementación está completamente alojado en la nube y la nube completa automáticamente el trabajo; no es necesario considerar la potencia informática, que es compatible con todo el centro de datos, y la informática el poder puede considerarse ilimitado, no hay necesidad de preocuparse por la operación y el mantenimiento, y mantener el funcionamiento continuo y estable del sistema es computación en la nube La responsabilidad del proveedor de servicios ya no es responsabilidad del desarrollador.
La perspectiva a largo plazo de la arquitectura sin servidor parece buena, pero el autor no es tan optimista sobre el desarrollo a corto plazo de la arquitectura sin servidor. No es adecuado para aquellas aplicaciones que tienen una lógica empresarial compleja, dependen del estado del servidor, la velocidad de respuesta y requieren enlaces largos. Esto se debe a que la suposición de "poder de cómputo ilimitado" sin servicio determina que se debe facturar de acuerdo con el uso para controlar la escala de poder de cómputo consumido. Por lo tanto, la función no permanecerá en el servidor en un estado activo todo el tiempo. , y solo comenzará a ejecutarse cuando llegue la solicitud. Esto hace que sea inconveniente que la función dependa del estado del servidor, y también hace que la función tenga un tiempo de inicio en frío, y el rendimiento de la respuesta no puede ser demasiado bueno (actualmente, el proceso de inicio en frío de ningún servicio probablemente esté en el nivel de decenas a cientos de milisegundos, para Java esta clase inicia aplicaciones con bajo rendimiento, incluso al nivel de cerca de segundos).
frase clave
- La fuerza impulsora más importante de la evolución de la arquitectura, o la fuerza impulsora más fundamental de esta tendencia de cambio "de grande a pequeño", es siempre facilitar la "muerte" y el "renacimiento" sin problemas de un determinado servicio. El cambio de vida o muerte de los servicios individuales es un factor clave relacionado con si todo el sistema puede sobrevivir de manera confiable.
- La arquitectura no es un invento, sino el resultado de una continua evolución.
- Es precisamente con la evolución de la arquitectura de software que el concepto de construir un sistema confiable ha cambiado de "perseguir el menor error posible" a enfrentar "los errores son inevitables". Es la base para que la arquitectura de microservicio desafíe y reemplace gradualmente a la arquitectura monolítica .
- El propósito del diseño del servicio distribuido propuesto por Unix DCE: "Permitir que a los desarrolladores no les importe si el servicio es remoto o local, y pueden llamar al servicio o acceder al recurso de forma transparente".
- Los negocios y la tecnología están completamente separados, y lo remoto y lo local son completamente transparentes. Quizás esta sea la mejor era.
otro
-
¿Qué es Unix?
En pocas palabras, es el creador de la mayoría de los sistemas operativos (como Windows no lo es), la siguiente es una respuesta de Zhihu.El sistema actual Windows, Mac OS, Linux y varias distribuciones, etc., excepto que el kernel de Windows de las versiones posteriores a Windows 3.1 es el kernel nt, todos los demás sistemas y versiones se originan en Unix en la parte inferior. Windows solo tiene 1 y 2, la capa inferior está relacionada con Unix y las versiones posteriores son completamente irrelevantes. Entre ellos, Mac OS es un kernel mixto, que es una mezcla de Unix y un kernel desarrollado por un profesor de Carnegie Mellon. Linux es completamente similar a Unix.
Cuando se trata de Unix, hay muchas palabras asociadas, como Mac OS, Linux, AIX, HP-UX y Solaris, todos los cuales son sistemas similares a Unix.
Los sistemas similares a Unix (inglés: similar a Unix; a menudo denominados UN X o nix) se refieren a varios sistemas derivados de Unix, como FreeBSD, OpenBSD, Solaris de SUN y varios sistemas similares a Unix tradicional, como Minix, Linux , QNX, etc Aunque algunos de ellos son software libre y otros son software propietario, todos heredan en gran medida las características del UNIX original, tienen muchas similitudes y todos cumplen en cierta medida con la especificación POSIX.
La marca registrada de UNIX es propiedad de la Organización Internacional de Estándares Abiertos. Solo los sistemas UNIX que se ajustan a la especificación única de UNIX pueden usar el nombre UNIX, de lo contrario, solo se puede llamar UNIX-like (similar a UNIX).
Gráfico más simple:
-
El significado de capas
incluye la arquitectura en capas con la que estamos más familiarizados, arquitectura MVC, modelo (Modelo)-vista (Vista)-controlador (Controlador), ¿cuál es el significado de estas capas? La esencia del diseño en capas es simplificar problemas complejos. La siguiente es la respuesta de Zhihu:Alta cohesión: el diseño en capas puede simplificar el diseño del sistema, permitiendo que diferentes capas se centren en un determinado módulo;
bajo acoplamiento: las capas interactúan a través de interfaces o API, y la parte que confía no necesita conocer los detalles de la parte dependiente;
reutilización: Código o la reutilización de funciones se puede lograr después de la estratificación;
escalabilidad: la arquitectura en capas puede hacer que el código sea más fácil de escalar -
JAR, WAR
Jar y War se pueden considerar como compresión de archivos.Este paquete es en realidad para comprimir el código y las cosas dependientes juntas.
El paquete Jar es un paquete Java y el paquete War puede entenderse como un paquete JavaWeb. El paquete Jar solo está empaquetado por proyectos escritos en Java, y solo contiene clases compiladas y algunos archivos de implementación. El paquete War contiene todo, incluidos los archivos de clase compilados a partir del código escrito, los paquetes dependientes, los archivos de configuración y todas las páginas del sitio web, incluidos HTML, JSP, etc. Un paquete War puede entenderse como un proyecto web, que contiene todos los elementos del proyecto. -
Versión en escala de grises La
versión en escala de grises es un método de publicación que permite a algunos usuarios continuar usando la función A del producto y a otros usuarios comenzar a usar la función B del producto. Si los usuarios no tienen objeciones a B, amplíe gradualmente el alcance y migre a todos los usuarios a B. Este enfoque permite probar y validar nuevas características o cambios sin afectar todo el sistema. -
La diferencia entre subprocesos múltiples y concurrencia
En primer lugar, un subproceso es una unidad de ejecución de un proceso y una entidad de programación dentro del proceso.Un proceso es un poco como proporcionar un entorno de aislamiento para cada aplicación.
Para la concurrencia y el paralelismo, la concurrencia significa que múltiples tareas se ejecutan alternativamente dentro del mismo período de tiempo y comparten recursos informáticos, centrándose en la programación de tareas y la gestión de recursos; el paralelismo significa que múltiples tareas se realizan al mismo tiempo, utilizando múltiples unidades de procesamiento o recursos informáticos, y de forma independiente, prestar atención a la división y ejecución de tareas.
El propósito de los subprocesos múltiples es generalmente para la computación paralela, y el sistema operativo puede asignar estos subprocesos a varias CPU para que se ejecuten simultáneamente. Entonces, una CPU de un solo núcleo no puede lograr la computación paralela.
De repente tengo una pregunta, ¿por qué a menudo oímos hablar de alta concurrencia pero no de alto paralelismo?
Una alta concurrencia significa que el sistema puede manejar una gran cantidad de solicitudes al mismo tiempo, mientras que un alto paralelismo significa cuántas tareas puede ejecutar el sistema al mismo tiempo. Una solicitud puede requerir varias tareas para completarse, o varias solicitudes pueden compartir la misma tarea. Entonces, el alto paralelismo es solo un medio para lograr una alta concurrencia.
La alta concurrencia es un concepto relativo a los usuarios o clientes, mientras que el alto paralelismo es un concepto relativo a los servidores o procesadores. Lo que les importa a los usuarios o clientes es si el sistema puede responder a sus solicitudes rápidamente, y no les importa cómo el sistema asigna y ejecuta las tareas internamente. Lo que le importa al servidor o procesador es cómo usar múltiples núcleos o múltiples máquinas para mejorar la velocidad de ejecución de las tareas. Por lo tanto, una alta concurrencia puede reflejar mejor la calidad del servicio externo del sistema, mientras que un alto paralelismo puede reflejar mejor el modo de funcionamiento interno del sistema.