Arquitectura de servidor micro vs monolítico

Actualmente estamos trabajando en nuestro nuevo producto / proyecto, es una aplicación cliente-servidor dirigida a ciertas empresas industriales / de servicios específicas. Estamos construyendo un servidor (lenguaje C y Linux solamente) que ejecuta un protocolo personalizado sobre TCP con un front-end Java. Estamos aproximadamente al 20% en el trabajo de codificación y nos enfrentamos a una situación en la que tenemos que elegir entre arquitectura de kernel micro o monolítica.

Soy consciente de que Micro vs. Monolithic generalmente está relacionado con la arquitectura del kernel, pero estamos hablando específicamente de servidores.

¿Por qué un servidor personalizado y no algo existente?

• Nuestras necesidades de IU son significativas y muy dinámicas, por lo que las soluciones basadas en Web / navegador web no eran apropiadas.
• El procesamiento estadístico es significativo en el extremo del cliente y, por lo tanto, nuevamente, los navegadores fueron de poca ayuda. (Por supuesto, podríamos hacer el procesamiento en el extremo del servidor y pasar los datos procesados ​​al cliente, pero eso implicaría una gran carga en el servidor y el desperdicio de recursos del cliente).
• Además, con al menos tres tecnologías (JS / HTML / CSS) para administrar incluso un solo evento, hace que toda la experiencia sea como barrer la casa en medio de una tormenta del desierto: lo barres n veces, el polvo se acumula n + 1 veces.

¿Qué pasa con el servidor micro y monolítico? ¿De qué hablas?

Considere la siguiente solicitud (hipotética) del cliente:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Al recibir dicha solicitud, un servidor, por lo general, lo hace (estamos ignorando las técnicas de concurrencia, como el subproceso y los tenedores por simplicidad):

• Analiza la cadena de solicitud
• Identificar la acción (Fetch HistoricDataSets LIMIT Year (2010)en nuestro caso)
• Interactúe con la capa de persistencia (Oracle, digamos, en nuestro ejemplo) y obtenga los datos.

• Formatee los datos según el protocolo. Ex:

  respuesta-id: 123
  éxito:
  texto de respuesta verdadero : conjuntos de datos

• Responda al cliente con los datos así formateados.

Esto es lo que llamamos un servidor monolítico (similar a un núcleo monolítico donde todos los trabajos del sistema operativo se realizan en el espacio del núcleo).

Considere la misma solicitud nuevamente, al recibo, esta vez el servidor (asumimos solo la memoria compartida como IPC, nuevamente por simplicidad):

• Pone la solicitud en la memoria compartida para el Parserproceso.
• El Parseranálisis sintáctico de la cadena, se identifica la tarea y dirige el Executionerproceso para ejecutar las tareas.
• La Executionerentonces pasa los datos al Fomatterproceso que, después de formatear los datos en una cadena de protocolo, vuelve al servidor.
• El servidor lo envía al cliente (respuesta).

Por supuesto, en lugar de Parser, Executionery Formatterpodría haber sido un proceso único pero separado. Esto es lo que llamamos un Micro Server (similar a un micro kernel que apenas requiere lo mínimo). El servidor efectivamente solo está escuchando y respondiendo, mientras que todos los pasos son atendidos por diferentes procesos.

¿Cuál elegir? ¡Estamos confundidos! Si bien los servidores monolíticos se prueban y prueban (¿la mayoría de los servidores web HTTP?) Y son más fáciles de programar y pueden manejar la concurrencia bastante bien. Los micro servidores, prima facie, parecen rápidos y en línea con el principio UNIX de un programa para hacer una tarea, pero también son complicados de desarrollar, especialmente. teniendo en cuenta la concurrencia.

Pregunta (s)
- ¿Cuáles son (posiblemente podrían ser) los pros y los contras de cada enfoque?
- ¿Cuándo usar cuál? (También podría interpretarse como una pregunta general: ¿Cuándo usar IPC?)
- Si se elige Micro kernel, ¿qué funciones deben ser parte del servidor central y qué no?

Preguntas similares / relacionadas

• Peligros de gran aplicación monolítica.
• Navegador externo externo incrustado (tangencial)
• Consejos para convertir la aplicación monolítica en multiproceso (tangencial)

• Nuestros clientes potenciales se pueden dividir en dos categorías:
  • Grande: alrededor de 1,700 - 2,000 solicitudes por minuto
  • Pequeño: alrededor de 650 - 700 solicitudes por minuto
• Se puede suponer que el volumen de datos por ciclo de solicitud (solicitud y la respuesta posterior) se distribuye normalmente con una media de ~ 1.20 MB y, en el peor de los casos, alrededor de 250-300 MB.
• El concepto del producto es relativamente nuevo, pero tiene la capacidad de afectar las operaciones centrales, por lo tanto, esperamos que los presupuestos de los clientes sean flexibles solo después de un cierto retraso (9-12 meses) después de la implementación, esto limita la cantidad de hardware que el cliente estará dispuesto cometer esp. los pequeños
• Cada cliente tendrá su propia pila cliente-servidor. El servidor se ejecutará en el hardware del cliente administrado por el equipo del cliente, mientras que los clientes se implementarán en las máquinas de los empleados funcionales.
• Las actualizaciones remotas para el cliente y la aplicación del servidor son imprescindibles
• Los PUSHservicios en tiempo real del servidor pueden ser 'altamente' deseados si el producto hace clic.

La economía a veces gobierna una respuesta mucho más crítica que la teoría central detrás de las elecciones. Lo más importante es que si está buscando algo 'vasto' en su caso, donde su aplicación necesita un despliegue realmente difícil: cuanto menor sea el número de ruedas que invente, mejor será. Si funciona, no me importará si es monolítico o micro; si no es así, ¡tampoco me importará!

Puede ser cierto que las aplicaciones basadas en páginas web muy convencionales podrían no ser para usted, pero debe mirar un poco más y ver que puede usar las cosas listas para usar y luego evolucionar para ver si puede reemplazar ese elemento por algo mejor. De esa manera, no solo ahorrará tiempo para lo primero, sino que también mejorará su comprensión de lo que realmente importa en la vida real. Aquí hay algunos consejos que puede considerar.

1. Si realmente necesita una escalabilidad muy alta, considere cómo sus servidores dividirán la tarea en lugar de reducir los números tan rápido como puedan. Eventualmente, tendrá una carga que un servidor realmente no puede asumir, incluso si Intel es el procesador más rápido del mundo y el cliente está listo para pagar. Por lo tanto, el enrutamiento de solicitudes y el equilibrio de carga es más importante que la eficiencia del protocolo en sí.

2. HTTP sigue siendo el mejor, si necesita escalar. (También puede obtener equilibradores de carga fáciles de comprar si lo usa). El protocolo personalizado requiere arreglos personalizados.

3. HTTP no significa que deba lanzar HTML, script java en absoluto. Ni siquiera significa que necesite tener un servidor Apache y un navegador web regulares. Puede usar HTTP entre dos clientes personalizados y elementos como el servidor AOL o lighthttpd que pueden usarse como biblioteca si la comunicación no es una gran transferencia de datos. También puede usar SOAP en ambos lados con kits de herramientas como gSOAP .

4. Incluso si HTTP definitivamente no se ajusta a la factura, considere algo como BEEP , que lo ayuda a hacer las cosas más eficientes. Alternativamente, existen muchos mecanismos RPC, RMI probados que existen.

5. Intente ver que puede hacer un trabajo máximo al máximo haciendo un procesamiento paralelo en el back-end y los servidores solo se consultan cuando se realiza el trabajo. Si esto funciona, existen marcos como MPI , o hay muchos otros kits de herramientas informáticas distribuidas que pueden ser de ayuda.

6. Finalmente, aunque puede que no esté en condiciones de conocer las necesidades exactas, pero es posible que necesite distribuir muchos datos o hacer muchos cálculos, si necesita ambos, todavía hay algunas ineficiencias arquitectónicas centrales.

Para mí, crear un nuevo Protocolo y luego crear un nuevo marco de servidor es un experimento doble que no deberían hacer juntos. Si sus apuestas son tan altas, primero debe intentar experimentar con las herramientas existentes para ver los límites de lo que se ha hecho hasta ahora, solo entonces sabrá los desafíos reales.

Se ha logrado mucho más en la investigación de sistemas distribuidos que solo aplicaciones web. Entonces deberías investigar eso.

Dipan

Esto me parece muy académico. Y, francamente, creo que el segundo enfoque es igual de monolítico. Esto es lo más lejos que debería llegar:

1. Analiza la solicitud
2. Manejar la solicitud

El controlador de solicitud elegido en función de los parámetros de solicitud debe encapsular todos los aspectos del manejo de la solicitud. Si el controlador realmente realiza consultas en su almacén de datos y si utiliza o no el formato estándar para devolver los datos es irrelevante de la capa anterior. De hecho, probablemente hará exactamente eso, pero no tiene ningún valor hacer suposiciones al respecto.

1. El núcleo monolítico es mucho más antiguo que el Microkernel . Se usa en Unix. mientras que Idea of ​​microkernel apareció a fines de la década de 1980 .

2. el ejemplo de sistemas operativos que tienen núcleos monolíticos son UNIX, LINUX, mientras que los sistemas operativos que tienen Microkernel son QNX, L4, HURD , inicialmente Mach (no mac os x) luego se convertirá en núcleo híbrido, incluso MINIX no es núcleo puro porque el controlador del dispositivo es compilado como parte del núcleo.

3. El núcleo monolítico es más rápido que el microkernel . mientras que el primer microkernel Mach es 50% más lento que el núcleo monolítico, mientras que la versión posterior como L4 solo es 2% o 4% más lento que el núcleo monolítico .

4. El núcleo monolítico generalmente es voluminoso . mientras que el núcleo monolítico puro debe ser de tamaño pequeño, incluso encajar en el caché de primer nivel del procesador (microkernel de primera generación).

5. en el controlador del dispositivo del núcleo monolítico residen en el espacio del núcleo . mientras que en el controlador de dispositivo Microkernel residen en el espacio del usuario .

6. Como el controlador del dispositivo reside en el espacio del núcleo, hace que el núcleo monolítico sea menos seguro que el microkernel. (La falla en el controlador puede provocar un bloqueo) mientras que los Microkernels son más seguros que el núcleo monolítico, por lo tanto, se utilizan en algunos dispositivos militares.

7. Los núcleos monolíticos usan señales y zócalos para garantizar IPC, mientras que el enfoque de microkernel utiliza colas de mensajes . 1 generación de microkernel IPC mal implementado por lo que fueron lentos en los cambios de contexto.

8. agregar una nueva función a un sistema monolítico significa volver a compilar todo el núcleo, mientras que puede agregar nuevas funciones o parches sin volver a compilar .