RFC con la implementación de una arquitectura modular

Question

Búsqueda de opiniones sobre la modularización de las aplicaciones web. Ya la mayoría de las aplicaciones, independientemente de la lengua tienen una base de datos back-end y de apoyo tie-ins con su respectivo servidor de aplicaciones Web (Apache, IIS, Lighttp, etc), pero una gran cantidad de desarrolladores que he tratado han problemas de llegar a un acuerdo con el uso de Memcached o nada fuera del espacio de proceso inmediato de la aplicación web.

Es modularización de una aplicación web como bueno una cosa como creo o hay algo que me falta que hace que todo el mundo de la Hna Desarrolladores de CTO de ser reacios a mover las partes específicas de la lógica de negocio fuera de la interfaz web y terminar en los servicios de back-end especializados?

Por ejemplo, hace unos años que recibió un disparo en una reunión de proyecto para una página web de tráfico muy alto cuando me sugirió que rasgar la lógica ACL intenso proceso fuera del marco frontal y convertirlo en un servicio semi-para clúster aplicación en el servidor. Para mí los beneficios fue una separación más limpia del código y la capacidad de reutilizar la lógica ACL en múltiples lugares mediante el uso de REST / JSON como el puente entre decir PHP y Python.

Los desarrolladores que no estaban de acuerdo con mi idea argumentaron que era "demasiado complicado", pero simplemente no podía ver cómo? Mis argumentos son que, así como no puede haber sopa de etiqueta para la capa de presentación, no puede y suele ser una sopa lógica del código que es tan engranado juntos que si surge un problema que podría ser casi imposible llevar a cabo una solución "quirúrgica".

Así que para acortarlo abajo, lo son de la Y o contras pro de rotura de grandes aplicaciones abajo en procesos independientes pero cooperativos (no roscados o peticiones sub). MySQL, Memcache, proceso de servicio similar son grandes ... pero por qué no otra cosa? ¿Cómo va por este camino "demasiado complicado"?

Answer 1

Bueno, a veces "demasiado complicado" significa "no quiero pensar fuera de mi zona de confort."

La noción básica suena bien --- estás hablando de arquitectura orientada a servicios bastante plausibles aquí.

Ahora, en cuanto a los pros y los contras, la primera cosa en contra de ella es que hace de hecho tiene que hacer que la gente piense fuera de su zona de confort. Un aire más técnica es que es necesario preservar lo que es, en efecto, el estado de la sesión. Digamos que recoger el testigo de autenticación de su servicio de autenticación; ¿Cómo se va a quedar asociado con la sesión de usuario correcto esa señal.

Otra cuestión es que podría ser más difícil de depurar, ya que está sucediendo de forma más dinámica.

En el lado profesional, sin embargo, si se puede satisfacer la emisión de estados de sesión, se obtiene una arquitectura altamente escalable; si necesita más servicio, se puede ampliar el servidor o simplemente agregar otro servidor.

Answer 2

Soy un fan de la separación de la funcionalidad básica lógica del servidor / negocio del código de la aplicación web. Esto es por varias razones diferentes:

1. Se puede controlar mejor la lógica de negocio. No habrá manera de mezclar esto con código de interfaz gráfica de usuario y crear un lío. Usted quiere mantener toda la lógica de negocio separado para que pueda hacer más adelante una API para llamar a la funcionalidad de código y no esperamos que ninguna lógica de negocio se abrió camino en el código de interfaz gráfica de usuario.
2. Desde el primer momento usted tiene que diseñar una buena API que usted tiene que utilizar a sí mismo para comunicarse con el servidor desde el cliente. El cliente puede ser la interfaz web o puede ser un usuario remoto.
3. Estabilidad. código de interfaz gráfica de usuario web puede ser fácilmente escrito mal y consumir demasiada memoria teniendo así por toda la aplicación.
4. Para escalar puede mover estos componentes por separado a diferentes servidores. Si está utilizando un sistema de almacenamiento en caché que ya permite la ampliación de la agrupación puede ser tan simple como la adición de más servidores de almacenamiento en caché.
5. Me he dado cuenta que las actualizaciones de aplicaciones se hacen con más frecuencia para el código de interfaz gráfica de usuario por lo que el servicio básico no tiene que ser derribados mayor parte del tiempo.
6. Seguridad. Puede estar seguro de que el código de seguridad se implementa en el código del servidor de modo que si alguien usa su API no van a ser capaces de saltarse cualquier código de seguridad que se abrió camino en el código de interfaz gráfica de usuario.

Nuestro sistema cuenta con un servicio básico 'motor' implementado como una aplicación Java. La aplicación web también está escrito en Java y (actualmente) la comunicación es a través de RMI. Nuestro sitio / aplicación está creciendo y todavía no hemos tenido que comenzar a usar un servicio de almacenamiento en caché como memcached o JCS.