¿La comunicación tranquila entre aplicaciones locales es una buena idea?

Question

Me pregunto si es una buena idea dejar que las aplicaciones locales (en el mismo servidor) se comuniquen entre sí por completo a través de API RESTFUL.

Sé que esto no es algo poco común, porque ya tenemos aplicaciones como CouchDB que usa HTTP REST para la comunicación, incluso con aplicaciones locales.

Pero quiero llevarlo a un nivel superior creando aplicaciones que actúen como módulos para una aplicación más grande, que también podría ser un módulo para otra aplicación, etc. En otras palabras, habrá muchas aplicaciones/módulos locales que se comunican con API RESTful.

De esta manera, estas aplicaciones/módulos podrían estar en cualquier idioma y podrían comunicarse sobre el cable entre servidores.

Pero tengo algunas preguntas:

• ¿Es esta una buena idea?
• ¿La transferencia de datos entre ellos será lenta?
• Si hago esto, entonces cada aplicación/módulo tiene que ser un servidor HTTP, ¿verdad? Entonces, si mi aplicación usa 100 aplicaciones/módulos, cada uno de estos tiene que ser un servidor web HTTP local, cada uno que se ejecuta en un puerto diferente (http: // localhost: 81, http: // localhost: 82, http: // localhost: 83 y así sucesivamente) ¿verdad?
• ¿Alguna mejor práctica/gotchas que deba conocer?

Answer 1

• ¿Es esta una buena idea?

Claro, tal vez.

• ¿La transferencia de datos entre ellos será lenta?

¡Sí! ¿Pero comparado con qué? En comparación con las llamadas internas nativas, absolutamente, será glacial. En comparación con alguna otra API de red, eh, no necesariamente más lento.

• Si hago esto, entonces cada aplicación/módulo tiene que ser un servidor HTTP, ¿verdad? Entonces, si mi aplicación usa 100 aplicaciones/módulos, tengo que tener 100 servidores web HTTP locales en ejecución cada uno con un puerto diferente (http: // localhost: 81,http: // localhost: 82, http: // localhost: 83 y así)?

No, no hay razón para asignar un puerto por módulo. Todo tipo de formas de hacer esto.

• ¿Alguna mejor práctica/gotchas que deba conocer?

La única forma en que esto tendrá éxito es si los servicios de los que está hablando son lo suficientemente gruesos. Estos tienen que ser grandes tipos de servicios cuadros negros que hacen que el gasto de llamarlos valga la pena. Incurrirá en los costos de conexión, los costos de transferencia de datos y el costo de mariscal de datos en cada transacción. Por lo tanto, desea que esas transacciones sean lo más raras posible, y desea que las cargas útiles sean lo más grandes posible para obtener el mejor beneficio.

¿Estás hablando realmente usando la arquitectura REST o simplemente enviando cosas de un lado a otro a través de HTTP? (Estas son cosas diferentes) El descanso incurre en sus propios costos, incluye enlaces integrados, tipos de datos ubicuos y comunes, etc.

Finalmente, es posible que simplemente no necesite hacer esto. Bien podría ser "un poco genial", un "agradable tener", "se ve bien en el tablero blanco", pero si, realmente, no lo necesite, entonces no lo hagas. Simplemente siga buenas prácticas de aislar sus servicios internos para que si decida más tarde hacer algo como esto, puede insertar la capa de pegamento necesaria para administrar la comunicación, etc. Agregar distribución remota aumentará el riesgo, la complejidad y el menor rendimiento (escala (escala ! = rendimiento) Así que debería haber una buena razón para hacerlo en absoluto.

Esa, posiblemente, es la "mejor práctica" de todos.

Editar - Respuesta al comentario:

Entonces, ¿quieres decir que ejecuto un servidor web que maneja todas las solicitudes entrantes? Pero entonces los módulos no serán aplicaciones independientes, lo que derrota a todo el propósito. Quiero que cada uno de los módulos pueda ejecutar solo.

No, no derrota el propósito.

Aquí está el trato.

Digamos que tiene 3 servicios.

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

De un vistazo, sería justo decir que estos son tres servicios diferentes, en 3 máquinas diferentes, que se ejecutan en 3 servidores web diferentes.

Pero la verdad es que todo esto puede estar ejecutándose en la misma máquina, en el mismo servidor web, incluso hasta (para llevar esto al extremo) ejecutando exactamente la misma lógica.

HTTP le permite mapear todo tipo de cosas. HTTP en sí es un mecanismo de abstracción.

Como cliente, todo lo que le importa es la URL de usar y la carga útil para enviar. ¿Con qué máquina termina hablando o qué código real lo ejecuta, no el problema del cliente?

A nivel de arquitectura, ha logrado una forma de abstracción y modularización. Las URL le permiten organizar su sistema es el diseño lógico que desee. La implementación física es distinta de la vista lógica.

Esos 3 servicios se pueden ejecutar en una sola máquina atendida por un solo proceso. Por otro lado, pueden representar 1000 máquinas. ¿Cuántas máquinas crees que responden a "www.google.com"?

Puede alojar fácilmente los 3 servicios en una sola máquina, sin compartir ningún código Guardar el servidor web en sí. Haciendo que sea fácil mover un servicio de su máquina original a otra máquina.

El nombre del host es la forma más sencilla de asignar un servicio a una máquina. Cualquier servidor web moderno puede atender cualquier cantidad de hosts diferentes. Cada "host virtual" puede atender cualquier cantidad de puntos finales de servicio individual dentro del espacio de nombres de ese host. En el nivel de "host", su trivial para reubicar el código de una máquina a otra si es necesario.

Debe explorar más las capacidades de un servidor web moderno para dirigir las solicitudes arbitrarias a la lógica real en el servidor. Los encontrarás muy flexibles.

Answer 2

¿Es esta una buena idea?

Sí. Se hace todo el tiempo. Así funcionan todos los servidores de bases de datos, por ejemplo. Linux está lleno de aplicaciones de clientes/servidores que se comunican a través de TCP/IP.

¿La transferencia de datos entre ellos será lenta?

No. TCP/IP usos localhost como un atajo para guardar las E/S de la red real.

El protocolo HTTP no es lo mejor para las conexiones dedicadas, pero es simple y bien compatible.

Si hago esto, entonces cada aplicación/módulo tiene que ser un servidor HTTP, ¿verdad?

No necesariamente. Algunos módulos pueden ser clientes y no tener un servidor.

Entonces, si mi aplicación usa 100 aplicaciones/módulos, cada uno de estos tiene que ser un servidor web HTTP local, cada uno que se ejecuta en un puerto diferente (http: // localhost: 81, http: // localhost: 82, http: // localhost: 83 y así sucesivamente) ¿verdad?

Sí. Así funciona.

¿Alguna mejor práctica/gotchas que deba conocer?

No "código duro" los números de puerto.

No use los números de puerto "privilegiados" (bajo 1024).

Use una biblioteca WSGI y será más feliz haciendo todos sus módulos en aplicaciones WSGI. Luego puede usar un servidor HTTP trivial de 2 líneas para envolver su módulo.

Lee esto. http://docs.python.org/library/wsgiref.html#examples

Answer 3

Al usar soluciones RESTful para la integración de la aplicación, creo que esta es una buena idea y profesó opiniones similares en otra pregunta.

• Cómo compartir datos en una organización

Answer 4

Para ser sincero, no creo que necesite 100 servidores para 100 aplicaciones, tal vez solo use 100 puertos en el mismo servidor.

Y también, RESTFUL Interface le dará la flexibilidad para expandir los servidores y permitir el equilibrio de carga si desea tener el potencial de escalar en ENORME.

Answer 5

No, no es una buena idea si no tienes una buena razón. Es una buena idea colocar el código de su aplicación para que pueda "descansar" en una etapa posterior si lo necesita. (O cualquier mejora del rendimiento se considera necesaria). La mayor complejidad de implementación de las "capas basadas en servidor" es una buena razón para no hacerlo. Yo sugeriría:

• Escriba una aplicación bien estructurada con un código bueno y limpio.
• Probarlo con las cargas de producción esperadas
• Si es necesario: refactor en capas que son servidores, pero .....

Un mejor enfoque es equilibrar la carga toda la aplicación. Si está haciendo algo como rieles sin estado en el servidor de aplicaciones, no debería ser un problema ejecutar varias instancias en paralelo.

Si está buscando complejidad, ignore mi respuesta. :-)