El nuevo CTO prohíbe la separación de front-end y back-end, ¡y también dijo muchas ventajas y desventajas!

Haga clic en la fuente azul de arriba y seleccione "Cuenta oficial de Star"

Artículos de alta calidad, entregados de inmediato

Siga la cuenta oficial detrás del escenario para responder al pago o al centro comercial para obtener información real del proyecto + video

Autor: fuzhongmin05

blog.csdn.net/fuzhongmin05/article/details/81591072

1. Antecedentes

La separación de front-end y back-end se ha convertido en la forma de uso estándar de la industria para el desarrollo de proyectos de Internet. Se desacopla de manera efectiva a través de nginx + tomcat (también puede agregar un nodejs en el medio) y la separación de front-end y back-end será la futura arquitectura distribuida a gran escala y la arquitectura de computación elástica. La arquitectura de microservicio y los servicios de múltiples terminales (múltiples clientes, como navegadores, terminales de vehículos, Android, IOS, etc.) sientan una base sólida. Este paso es la única forma de que la arquitectura del sistema evolucione de un simio a un adulto.

La idea central es que la página HTML de front-end llama a la interfaz API RESTFUL de back-end a través de AJAX y utiliza datos JSON para la interacción.

Servidor web: generalmente se refiere a servidores como Nginx y Apache, generalmente solo pueden analizar recursos estáticos;

Servidor de aplicaciones: generalmente se refiere a servidores como Tomcat, Jetty, Resin que pueden analizar tanto recursos dinámicos como estáticos, pero la capacidad de analizar recursos estáticos no es tan buena como la de un servidor web;

Generalmente, solo se puede acceder al servidor web desde la red externa, y solo se puede acceder al servidor de aplicaciones desde la red interna.

La mayoría de los proyectos Java Web anteriores fueron programadores y madres de Java, front-end y back-end. Con el desarrollo de los tiempos, muchas empresas grandes, medianas y pequeñas han comenzado a dividir gradualmente los límites de front-end y back-end cada vez más claramente. Los ingenieros de front-end solo se preocupan por los asuntos de front-end, y los de atrás -Los ingenieros finales solo se preocupan por los asuntos de back-end. Como dice el refrán, hay una especialización en las artes, si una persona lo sabe todo, no es bueno en nada después de todo. Las empresas grandes y medianas necesitan talentos profesionales, y las pequeñas empresas necesitan todo terreno, pero para el desarrollo de la carrera personal, es necesario separar las partes delantera y trasera.

2. Época no separada (varios acoplamientos)

En los primeros días, se utilizó principalmente el marco MVC. El diagrama de estructura de Jsp + Servlet es el siguiente:

Aproximadamente todas las solicitudes se envían al Servlet como controlador, que acepta las solicitudes y las distribuye a la JSP correspondiente para responder de acuerdo con la información de la solicitud. Al mismo tiempo, Servlet también genera instancias de JavaBeans de acuerdo con los requisitos de JSP y las envía al entorno JSP. JSP puede obtener los datos en JavaBeans llamando directamente a métodos o utilizando las etiquetas personalizadas de UseBean. Cabe señalar que esta vista también puede utilizar motores de plantilla como Velocity y Freemaker. El uso de estos motores de plantilla puede hacer que la división del trabajo en el proceso de desarrollo sea más clara y mejorar la eficiencia del desarrollo.

Luego, durante este período, hay dos métodos de desarrollo de la siguiente manera:

método uno

Camino dos

El segundo método se ha eliminado gradualmente. Hay dos razones principales: 1) El front-end depende en gran medida del back-end durante el proceso de desarrollo. Si el back-end no se completa, el front-end no puede funcionar en absoluto; 2) Debido a problemas de tendencias, sepa JSP, comprenda la velocidad, el marcador libre y otros motores de plantilla. Hay cada vez menos interfaces, por lo que el segundo enfoque no se adopta gradualmente. Sin embargo, debo decir que el método uno todavía lo utilizan muchas pequeñas empresas de software tradicionales. Entonces, ¿cuáles son las deficiencias comunes del primer y segundo método? 1. El front-end no se puede depurar por separado y la eficiencia de desarrollo es baja;

2. La interfaz inevitablemente encontrará código de fondo, como:

<body>
   <%
       request.setCharacterEncoding("utf-8")
       String name=request.getParameter("username");
       out.print(name);
   %>
</body>

El acoplamiento de esta forma es demasiado fuerte. Por lo tanto, incluso si usa motores de plantilla como freemarker, no puede escribir código Java. El front-end también inevitablemente tiene que volver a aprender la sintaxis de la plantilla del motor de plantillas, lo que aumenta innecesariamente el costo de aprendizaje del front-end. Así como nuestro desarrollo de back-end no quiere escribir el front-end, piense en cómo se siente si su código de back-end está incrustado en el código de front-end. Por lo tanto, este enfoque es muy inapropiado.

3. Algunos otros problemas causados por JSP en sí. Por ejemplo, JSP es relativamente lento la primera vez que se ejecuta, porque contiene un paso para traducir JSP a Servlet. Por ejemplo, debido a la carga síncrona, cuando hay mucho contenido en la JSP, la respuesta de la página será muy lenta.

3. La era de los semiseparados

El front-end y el back-end están semi-separados. El front-end es responsable de desarrollar la página, obtener datos a través de la interfaz (Ajax) y usar la operación Dom para vincular los datos a la página. Finalmente, el front-end renderiza la página. Así es como se combinan las aplicaciones Ajax y SPA (aplicaciones de una sola página). El diagrama de estructura es el siguiente:

Los pasos son los siguientes: (1) El navegador solicita, el CDN devuelve la página HTML; (2) El código JS en el HTML solicita la interfaz Restful en segundo plano en modo Ajax; (3) La interfaz devuelve los datos Json, la página analiza los datos de Json y la procesa a través de la operación Dom; el back-end proporciona interfaces API en formato JSON para que las utilice el lado nativo, y las interfaces API en formato JSON también se proporcionan a WEB.

Entonces significa que el flujo de trabajo WEB es: 1. Abrir la web, cargar recursos básicos, como CSS, JS, etc .; 2. Iniciar una solicitud Ajax y luego solicitar datos del servidor, y mostrar la carga al mismo tiempo; 3. Obtenga los datos en formato json y luego, según Lógicamente, seleccione la plantilla para representar la cadena DOM; 4. Inserte la cadena DOM en la vista web de la página para representar la estructura DOM; estos pasos se realizan paso a paso en el dispositivo utilizado por el usuario, es decir, el rendimiento del dispositivo del usuario y la velocidad de ejecución de la APLICACIÓN La conexión es más estrecha. En otras palabras, si el dispositivo del usuario es de muy bajo nivel, más lenta la APLICACIÓN abrirá la página.

¿Por qué está semiseparado? Porque no todas las páginas son aplicaciones de una sola página. En el caso de las aplicaciones de varias páginas, debido a que el front-end no domina la capa del controlador, el front-end debe discutir con el back-end. o renderizado asincrónico de Json? Además, incluso en este período, generalmente un ingeniero se encarga de todo el trabajo de front-end y back-end. Por lo tanto, en esta etapa, solo se puede considerar como semiseparado.

En primer lugar, las ventajas de este enfoque son obvias. El front-end no incorpora ningún código de back-end, y el front-end se centra en el desarrollo de HTML, CSS y JS, y no depende del back-end. También puedo simular datos Json para representar la página. Si encuentra un error, puede localizar rápidamente de quién es el problema.

Sin embargo, bajo esta estructura, todavía existen evidentes inconvenientes. Los puntos más obvios son los siguientes: 1) JS tiene mucha redundancia. En el caso de negocios complejos, el código de la parte de representación de la página es muy complicado; 2) Cuando la cantidad de datos devueltos por Json es relativamente grande, el el procesamiento es muy lento, habrá congelaciones de páginas; 3) SEO (optimización de motores de búsqueda, es decir, optimización de motores de búsqueda) es muy inconveniente, porque los rastreadores de motores de búsqueda no pueden rastrear los datos procesados por JS de forma asincrónica, lo que da como resultado una página de este tipo, El SEO tendrá un cierto 4) El consumo de recursos es serio En el caso de negocios complejos, una página puede tener que iniciar múltiples solicitudes HTTP para representar la página por completo. Algunas personas pueden estar insatisfechas y sentir que está bien establecer múltiples solicitudes HTTP en el lado de la PC. ¿Has pensado en el terminal móvil ?, ¿sabes cuántos recursos consume el terminal móvil para establecer una solicitud HTTP?

Es precisamente debido a las deficiencias anteriores que necesitamos con urgencia una arquitectura de separación de front-end y back-end real.

4. La era de la separación

El ejemplo unánime de la separación de front-end y back-end es SPA (aplicación de una sola página). Todos los datos de visualización utilizados son proporcionados por el back-end a través de interfaces asíncronas (AJAX / JSONP), y el front-end solo se muestra. En cierto sentido, SPA logra la separación de front y back end, pero hay dos problemas con este enfoque:

Entre los servicios WEB, SPA representa una proporción muy pequeña. En muchos escenarios, también hay un modo híbrido síncrono / síncrono + asíncrono. SPA no se puede usar como una solución general; en el modo de desarrollo de SPA actual, la interfaz generalmente se proporciona de acuerdo con la lógica de presentación y con el fin de mejorar la eficiencia , también necesitamos un backend. Ayúdanos a lidiar con alguna lógica de presentación, lo que significa que el back-end todavía está involucrado en el trabajo de la capa de vista, no en la separación real de front-end y back-end. Separación estilo SPA de front-end y back-end, que se distingue de la capa física (piense que mientras el cliente sea el front-end, el servidor es el back-end) esta división ya no puede satisfacer las necesidades de front-end. -separación final y back-end, creemos que la división de responsabilidades puede cumplir con los escenarios actuales que se utilizarán:

El front-end es responsable de la capa de vista y controlador. El back-end solo es responsable de la capa de modelo. La capa de controlador y la capa de vista, como el procesamiento empresarial y la persistencia de datos, son solo una capa muy marginal para el back-end actual desarrollo. El java actual es más adecuado para la capa de persistencia. Negocio de capa de modelo.

Durante el período en el que los extremos frontal y posterior estaban completamente separados, el alcance del extremo frontal se amplió y la capa del controlador también se consideró parte del extremo frontal. Durante este período: Front end: Responsable de las capas View y Controller. Backend: Solo responsable de la capa de Modelo, procesamiento de datos / negocios, etc.

Sin embargo, el personal del servidor no está familiarizado con la estructura HTML del front-end y el front-end no comprende el código del back-end ¿Cómo implementar la capa del controlador? Este es el efecto mágico de node.js, que es adecuado para escenarios con alta concurrencia, intensiva E / S y una pequeña cantidad de lógica empresarial. El punto más importante es que el front-end no necesita aprender otro idioma, para el front-end, el dominio se mejora enormemente.

Puede pensar en Nodejs como una API que interactúa con la interfaz. En general, el rol de NodeJs es equivalente a C (controlador) en MVC. La lógica de implementación del enrutamiento de Nodejs es enviar el código de la página estática del front-end como una cadena al cliente (como un navegador). La comprensión simple puede entenderse como un conjunto de interfaces api proporcionadas al cliente, pero los datos devueltos son los caracteres del código de página Solo cadena.

Utilice NodeJs como puente para conectar la salida JSON mediante la API del lado del servidor. Por motivos de rendimiento y otras razones en el back-end, el formato de datos devuelto por la interfaz proporcionada puede no ser adecuado para el uso directo del front-end. La función de clasificación y la función de filtrado requeridas por el front-end, así como la visualización de la página en el capa de vista, es posible que todos deban estar en la interfaz. Los datos proporcionados se someten a un procesamiento secundario. Aunque este procesamiento se puede realizar en la interfaz, tal vez una gran cantidad de datos desperdicie el rendimiento del navegador. Entonces, agregar una capa intermedia de nodo es una buena solución.

El navegador (vista web) ya no solicita directamente la API JSP, pero: 1) el navegador solicita NodeJS en el lado del servidor; 2) NodeJS luego inicia HTTP para solicitar JSP; 3) JSP aún genera JSON a NodeJS como API; 4) NodeJS recibe Después de que se alcanza el JSON, se procesa la página HTML; 5) NodeJS descarga la página HTML directamente al navegador; de esta manera, el navegador obtiene una página HTML normal sin enviar Ajax para solicitar el servidor.

La arquitectura de Midway Framework propuesta por el equipo de front-end de Taobao se muestra en la siguiente figura:

¿Cuáles son los beneficios específicos de agregar node.js como capa intermedia?

(1) Mejora de la adaptabilidad; de hecho, en el proceso de desarrollo, a menudo desarrollamos un conjunto de interfaces para PC, dispositivos móviles y aplicaciones. De hecho, para estos tres terminales, la mayor parte de la lógica empresarial del terminal es la misma. La única diferencia es que la lógica de presentación interactiva es diferente. Si la capa del controlador está en manos del back-end, y el back-end mantiene estos controladores para la lógica de visualización de estas diferentes páginas finales, la plantilla no se puede reutilizar, lo que aumentará el costo de comunicación con el front-end. Si se agrega la capa node.js, el diagrama de arquitectura es el siguiente:

Bajo esta estructura, la lógica de visualización de la interfaz de cada interfaz es mantenida por la propia capa de nodo. Si el gerente de producto quiere cambiar la interfaz o algo intermedio, el front-end puede mantenerlo a tiempo completo y el back-end no necesita preocuparse por eso. El front-end y el back-end cumplen sus funciones, el back-end se centra en el desarrollo de su propia lógica empresarial y el front-end se centra en el desarrollo de los efectos del producto.

(2) Mayor velocidad de respuesta; a veces, nos encontramos con que los datos devueltos por el back-end al front-end son demasiado simples y el front-end necesita realizar operaciones lógicas con estos datos. Entonces, cuando la cantidad de datos sea relativamente pequeña, las operaciones como las operaciones de agrupación no la afectarán. Pero cuando la cantidad de datos es grande, habrá un efecto de retraso obvio. En este momento, la capa intermedia del nodo puede poner muchos de estos códigos en la capa del nodo para su procesamiento, también puede compartir una lógica simple para el back-end y puede usar el motor de plantillas para controlar la salida del front-end. De esta manera, se mejoran enormemente la flexibilidad y la capacidad de respuesta.

Por ejemplo, incluso después de que la página esté estática, el front-end todavía tiene mucha información que debe obtenerse del back-end en tiempo real. Esta información se encuentra en diferentes sistemas comerciales, por lo que el front-end debe enviar 5 o 6 solicitudes asincrónicas. Con NodeJs, el front-end puede proxy estas 5 solicitudes asincrónicas en NodeJs. También es fácil hacer bigpipe, esta optimización puede mejorar mucho la eficiencia general de renderizado. En la PC, cree que está bien enviar 5 o 6 solicitudes asincrónicas, pero en el lado inalámbrico, es costoso establecer una solicitud http en el teléfono móvil del cliente. Con esta optimización, el rendimiento mejora varias veces a la vez.

(3) Se mejora el desempeño; todos deben conocer el principio de responsabilidad única. Desde este punto de vista, cuando solicitamos una página, es posible que tengamos que responder a muchas interfaces de back-end. Con más solicitudes, la velocidad naturalmente se ralentiza. Este fenómeno es más grave en el lado móvil. Utilizando el nodo como capa intermedia, los múltiples datos de back-end requeridos por la página se ensamblan directamente en la etapa de intranet y luego se devuelven al front-end de manera uniforme, lo que obtendrá un mejor rendimiento.

(4) La asincronía y la plantilla están unificadas; la página de inicio de Taobao está ensamblada por docenas de fragmentos HTML (un archivo para cada fragmento). Antes de PHP, estas docenas de fragmentos deben incluirse sincrónicamente, que deben ser seriales. El nodo puede ser asíncrono y puede leer Paralelamente, una vez que estos fragmentos también contienen lógica de negocios, la ventaja de la asincronía es obvia: es cierto que el archivo que se procese primero se generará y se mostrará primero. Cuanto más complejo sea el sistema de archivos de la máquina frontal y cuantos más fragmentos de la página, más obvio será el efecto de aceleración asincrónica. Las plantillas unificadas de front-end y back-end son muy útiles en el campo inalámbrico.Las páginas de PC y las páginas en la escena WIFI son adecuadas para la renderización de front-end (datos de back-end Ajax a front-end) y 2G y 3G débiles Los entornos de red son adecuados para el renderizado de back-end (los datos se escupen en el front-end junto con la página), por lo que para la misma plantilla, utilizando diferentes canales de renderizado en diferentes condiciones, la plantilla solo necesita desarrollarse una vez.

La división de las responsabilidades de front-end y back-end después de agregar la capa intermedia de NodeJS:

5. Resumen

Desde la era MVC clásica de JSP + Servlet + JavaBean, a la era del framework Java de SSM (Spring + SpringMVC + Mybatis) y SSH (Spring + Struts + Hibernate), a los frameworks front-end (KnockoutJS, AngularJS, vueJS, ReactJS En la era de MV *, y luego en la era de pila completa liderada por Nodejs, la tecnología y la arquitectura han ido mejorando. Aunque el modelo de "desarrollo de pila completa basado en NodeJS" es muy emocionante, todavía queda un largo camino por recorrer para convertir el desarrollo de pila completa basado en Node en un desarrollo estable y aceptable para todos. El camino hacia la innovación no se detendrá, ya sea el modelo de separación frontal u otros modelos, es para resolver más convenientemente las necesidades, pero son solo una "estación de tránsito". El proyecto de front-end y el proyecto de back-end son dos proyectos que se colocan en dos servidores diferentes y deben implementarse de forma independiente, dos proyectos diferentes, dos bases de código diferentes y desarrolladores diferentes. El front-end solo necesita prestar atención al estilo de la página y el análisis y la representación de datos dinámicos, mientras que el back-end se centra en la lógica empresarial específica.