Weifu: ¿el salvador o el sepulturero de Java EE?

Algunas personas dicen que Java está muy inflado y a menudo "hace un escándalo con un grano de arena". Pero las deficiencias de las extensiones PHP y Node.js son demasiado obvias. Se pueden utilizar aplicaciones pequeñas, pero no aplicaciones grandes. Además, existen demasiados marcos excelentes en el campo JavaEE para resolver el problema de la eficiencia del desarrollo. De hecho, al utilizar marcos como Spring, la eficiencia del desarrollo no es menor que la de PHP. En la era de Internet, muchos desarrolladores de Java no desarrollan aplicaciones web basadas en Servlet y EJB, y WebSphere solo existirá en los sistemas estándar de las grandes empresas. Java en las empresas de Internet está dominado por Tomcat.

Entonces, ¿pueden los microservicios compensar completamente las deficiencias de JavaEE? Para JaveEE, ¿qué papel juegan los microservicios? ¿Son salvadores o sepultureros?

Cuando nació Java, algunas empresas gigantes, incluidas IBM, BEA y Oracle, vieron las enormes oportunidades comerciales que Java, como excelente lenguaje de programación web, podría brindarles. Entonces, ¿cómo se gana dinero con un lenguaje de programación? La respuesta es utilizar este lenguaje para construir servidores extremadamente complejos y permitir que las grandes empresas gasten mucho dinero para comprarlos. Luego están la especificación JavaEE, la especificación JSR y el middleware de servidor como WebLogic y WebSphere. Los paquetes grandes implementados en estos servidores se ejecutan lentamente y consumen grandes cantidades de memoria. Desarrollar y depurar basándose en estos contenedores es la pesadilla de un desarrollador. Como compensación reciben generosas remuneraciones de sus empleadores.

Debido al enorme costo, pocas empresas pueden soportar Java durante mucho tiempo a un costo razonable. Si desea crear un sitio web en Java, debe pagar mucho dinero para ejecutar estos servidores, incluso si solo usa contenedores de Servlet. Las empresas y corporaciones han estado utilizando Java durante mucho tiempo porque sólo estas grandes empresas pueden permitirse los millones de dólares en costos de servidores y altos salarios para los desarrolladores de nivel empresarial.

Rod Johnson lanzó el marco Spring en 2003. Spring proporciona soporte IoC y POJO para ayudar a los desarrolladores a escapar de EJB. Como resultado, la eficiencia del desarrollo ha mejorado enormemente y una gran cantidad de desarrolladores han recurrido a Spring y han dejado de lado EJB. Los desarrolladores de servidores de aplicaciones vieron esto y proporcionaron algunas funciones en Java EE5 que pueden reducir la carga de los desarrolladores. Desafortunadamente, Spring ha sido tan popular que la gente casi lo confunde con el contenedor JavaEE. Todavía se ejecuta en contenedores JavaEE Servlet, que siguen el diseño de hace diez años y no tienen en cuenta las CPU multinúcleo ni NIO.

Mientras tanto, PHP se está poniendo al día. PHP utiliza menos memoria y recursos y cuenta con el respaldo de muchas empresas. Algunas plataformas CMS, como WordPress, Drupal, etc. , todos construidos en PHP, lo que atrae a una gran cantidad de desarrolladores de PHP. Sin embargo, aunque PHP sigue siendo el lenguaje de programación más popular en la actualidad, tiene sus propias deficiencias. No es muy rápido y escalar es difícil.

Ryan Dahl lanzó el proyecto Node.js en 2009. El proyecto admite E/S asincrónicas sin bloqueo y controladas por eventos. Si los subprocesos del servidor se utilizan correctamente, Node.js puede mejorar en gran medida la velocidad de respuesta. de un solo servidor. El rendimiento del servidor es comparable al de un clúster de servidores JavaEE. Node.js es un buen trabajo, pero también tiene sus propias limitaciones. Node.js es difícil de ampliar e integrar con sistemas heredados.

En 2014 apareció Undertow, un servidor web sin bloqueo basado en Java. Según los resultados de la prueba, se pueden procesar millones de solicitudes por segundo en un servidor Dell de 8.000 dólares, y Google necesitaría un clúster para manejar un millón de las mismas solicitudes. Es liviano, su núcleo requiere solo 1 M de memoria y también incluye un servidor integrado que usa menos de 4 M de memoria dinámica.

LightJavaFramework basado en UndertowCore es un contenedor de microservicios que admite unidad de diseño y generación de código, seguridad en tiempo de ejecución y verificación en tiempo de ejecución.

Proveedores de JavaEE Hace muchos años, los proveedores de JavaEE, como Oracle e IBM, gastaron cientos de millones de dólares en el desarrollo de servidores de aplicaciones (WebLogic y WebSphere) y los vendieron a grandes organizaciones por millones de dólares. Pero ahora estos servidores no se pueden vender porque JBoss rápidamente ganó participación de mercado y el soporte de Oracle para Java EE también está disminuyendo: #/story/16/07/02/1639 241/Oracle-May-Have-stop-funding-and- desarrollo-.

A medida que los microservicios se vuelven cada vez más importantes, es difícil vender estos servidores de aplicaciones porque son más adecuados para implementar aplicaciones individuales. Existe una aplicación que contiene cientos de EJB. Se necesitaron 45 minutos para probar una sola línea de cambio de código en WebLogic.

Clientes de JavaEE

Desde el punto de vista del cliente, no merece la pena gastar mucho dinero en comprar estos servidores, porque lo que JavaEE promete puede no ser cierto. Una aplicación desarrollada para WebSphere no se puede implementar en WebLogic, por lo que debe gastar más dinero para actualizar el servidor porque es posible que el proveedor ya no admita la versión anterior del servidor y dicha actualización le costará millones de dólares. Entonces, algunas personas inteligentes no pueden evitar preguntar: ¿por qué implementar aplicaciones en estos gigantes? ¿Por qué empaquetar aplicaciones en paquetes ear o paquetes war en lugar de paquetes jar? ¿Por qué no podemos dividir aplicaciones grandes en partes más pequeñas para poder implementarlas y escalarlas de forma independiente?

Microservicios

Los microservicios son el antídoto a estos problemas. Wikipedia define los microservicios como “un estilo de arquitectura de software. Las aplicaciones complejas se componen de procesos independientes que interactúan mediante API independientes del lenguaje. Estos servicios de procesos son pequeños, muy discretos y se centran en una tarea pequeña. Utilizan un enfoque modular para construir sistemas. “La arquitectura de microservicios facilita la creación de aplicaciones, que se dividen en servicios separados que se pueden combinar de cualquier forma. Cada servicio se puede implementar de forma independiente o combinarse en una aplicación. Estos servicios también pueden depender de otras aplicaciones. Acelera el desarrollo de servicios porque los servicios se pueden desarrollar en paralelo siempre que se defina la interfaz.

Los microservicios son flexibles y escalables. Los microservicios no dependen únicamente de un único servidor y una implementación, sino que se pueden distribuir en varias máquinas, en varios centros de datos y en cualquier otra región disponible. Si un servicio falla, se puede iniciar otro servicio. Dado que toda la aplicación se divide en microservicios (pequeños servicios), algunos servicios populares se pueden escalar fácilmente.

Si has utilizado COM, dCOM, CORBA, EJB, OSGi, J2EE, SOAP y SOA sabrás que los servicios y componentes no son nada nuevo. Uno de los mayores problemas que encuentran las empresas al utilizar componentes es su dependencia de grandes servidores de hardware, que ejecutan muchas aplicaciones en el mismo servidor. Tenemos EJB, paquetes war, paquetes ear y varios paquetes de componentes. Debido a que los recursos del servidor son demasiado caros, debemos aprovecharlos al máximo.

Sin embargo, a juzgar por el desarrollo de los últimos años, los métodos anteriores están algo obsoletos. Los servidores del sistema operativo cambian constantemente y se pueden liberar recursos virtuales como componentes, como EC2, OpenStack, vagger, Docker, etc. El mundo ha cambiado. La arquitectura de microservicios ha visto esta tendencia. El hardware, la tecnología de nube, la CPU multinúcleo y la tecnología de virtualización también se están desarrollando. Necesitamos cambiar los métodos de desarrollo anteriores.

Al iniciar un nuevo proyecto, no utilice paquetes EAR o WAR. Ahora podemos ejecutar la JVM en Docker. Docker es solo un proceso, pero funciona como un sistema operativo. Docker se ejecuta en un sistema operativo en la nube, que se ejecuta en una máquina virtual, y la máquina virtual se ejecuta en un servidor Linux. Estos servidores no pertenecen a nadie, sino que son compartidos por muchos desconocidos. ¿Qué pasa si hay mucho tráfico? En pocas palabras, utilice más instancias de servidor. Es por eso que los microservicios de Java deben ejecutarse en procesos separados y no dentro de contenedores JavaEE o de servlets.

Los microservicios generalmente proporcionan puntos finales API basados ​​en HTTP/JSON.

Esto se puede integrar fácilmente con otros servicios (de código abierto o de código cerrado) siempre que estos servicios proporcionen una interfaz HTTP/JSON. Los servicios se pueden consumir y componer de maneras más significativas. Los servicios EC2, S3 y otros de Amazon (u otras empresas) son buenos ejemplos. La infraestructura pasará a formar parte de la aplicación y serán programables.

Las aplicaciones que utilizan arquitectura de microservicios deben ser modulares, programables y componibles. Los microservicios son intercambiables. Ciertas partes de la aplicación se pueden reescribir o mejorar sin afectar toda la aplicación. La interacción entre microservicios será más fácil si todos los componentes proporcionan API programables (nunca confíe en microservicios a los que no se puede acceder a través de curl).

Con la popularidad de los microservicios, muchos fabricantes han comenzado a intentar convertir sus servicios web JavaEE en microservicios para poder seguir vendiendo sus productos obsoletos. APIGateway es uno de estos proveedores.

Jason Bloomberg es el presidente de Intellyx. En un artículo, señaló la diferencia entre los servicios web tradicionales y los microservicios, y cuestionó la tendencia de los servicios web tradicionales a transformarse en microservicios:

#/Danger-Microservices-Clean-Get Value - Stripping - Promotion

Los microservicios no son servicios web en el bus de servicios empresariales, ni son una arquitectura tradicional orientada a servicios, aunque sigue algunos conceptos básicos de SOA. Básicamente, los microservicios se diferencian de SOA porque todo el entorno ha cambiado por completo.

Un entorno de arquitectura de microservicios no tiene límites: las aplicaciones de extremo a extremo basadas en la nube se ejecutan en una infraestructura totalmente virtualizada y en contenedores. Los contenedores componen aplicaciones y servicios, y DevOps proporciona un marco para que la infraestructura de TI ayude a automatizar el desarrollo, la implementación y la gestión del entorno.

Aunque los microservicios no requieren contenedores, los microservicios se pueden ejecutar fácilmente en contenedores. Además, implementar código que no sea de microservicio en contenedores no es una buena elección.

Las tecnologías de contenedores como Docker se han considerado hasta cierto punto como el mejor compañero de los microservicios. Un contenedor es el subconjunto más pequeño de recursos que ejecuta un microservicio. Docker simplifica el desarrollo de microservicios y facilita las pruebas de integración.

Los contenedores son útiles para el desarrollo de microservicios, pero no son obligatorios. Docker también se puede utilizar para implementar aplicaciones independientes. Los microservicios y los contenedores pueden integrarse bien, ¡pero los microservicios incluyen mucho más que contenedores!

Conclusión

El estilo de desarrollo de aplicaciones ha ido cambiando en los últimos años y los microservicios se han vuelto cada vez más populares. Las grandes empresas dividen las aplicaciones grandes en aplicaciones pequeñas que se pueden implementar de forma independiente. Estas pequeñas aplicaciones se implementan en contenedores en la nube. LightJava es un marco de microservicios de código abierto que proporciona muchas funciones para estos microservicios que se ejecutan en contenedores. Admite el impulso del diseño, los desarrolladores solo necesitan centrarse en la lógica empresarial y el resto puede ser manejado por el marco y los procesos de DevOps. Entonces aquí viene el problema. ¿Qué opinas?