¿Cómo surgió la computación distribuida?
Modo C/S tradicional. HTTP/FTP/SMTP/POP/DBMS y otros servidores. El cliente envía una solicitud al servidor, y el servidor procesa la solicitud y devuelve el resultado al cliente. El cliente es activo y el servidor es pasivo. Este tipo de llamada es explícita. Una llamada remota es una llamada remota y una llamada local es una llamada local. Debe tener claro cada detalle y no puede ser vago.
Tecnología de clúster. En los últimos años, la potencia informática de las PC se ha desarrollado rápidamente, pero la potencia informática de los servidores no puede satisfacer las necesidades de los clientes. Esta relación de muchos a uno es intrínsecamente injusta y la gente se ha dado cuenta de que los requisitos de rendimiento siempre se pueden cumplir aumentando la potencia informática de un único servidor. Ha surgido una tecnología llamada clustering, que conecta varios servidores y los utiliza como un solo servidor. La ventaja de esta tecnología es que es transparente no sólo para el cliente sino también para el software del servidor, que puede ejecutarse en el clúster sin modificaciones. El alcance de la aplicación de la tecnología de clúster se limita a esto: solo puede mejorar la potencia informática del mismo software, pero no puede hacer nada con el trabajo colaborativo de varios software diferentes.
Entorno informático distribuido general. Como CORBA/DCOM/RMI/DBUS, estas tecnologías (especificaciones) son casi todas transparentes a la red y el método llamado puede estar en otro proceso o en otra máquina. Básicamente, a la persona que llama no le importa si la llamada es local o remota. Por supuesto, es esta transparencia la que ha llevado al abuso de la informática distribuida, que es fácil de usar y todo el mundo piensa que es gratuita. De hecho, el coste de la informática distribuida es considerable. Se dice que la velocidad de las llamadas entre procesos se puede reducir en un orden de magnitud y la velocidad de las llamadas entre máquinas se puede reducir en dos órdenes de magnitud. Algunos expertos sugieren reducir el uso de la informática distribuida. Incluso si se utiliza, se deben utilizar llamadas de grano grueso para reducir la cantidad de llamadas.
También hay algunas formas mixtas (¿jabón?), en las que no entraré aquí. Presentamos principalmente el tercer modelo distribuido, que es adecuado tanto para aplicaciones empresariales como para aplicaciones de escritorio. Algunos se centran en aplicaciones empresariales (como CORBA), otros se centran en entornos de escritorio (como DBUS). Sus principios de implementación son similares y se basan básicamente en RPC tradicional o imitación de RPC. Sus principios básicos se presentan a continuación.
Veamos el modelo distribuido más simple:
En el enfoque tradicional, llamar a las funciones de un objeto es simple: simplemente cree el objeto y llame a sus funciones. En un entorno distribuido, el objeto está en otro proceso, en un espacio de direcciones completamente diferente, por lo que llamar a sus funciones puede resultar un poco difícil.
Mire el modo de solicitud del modo C/S tradicional. El cliente envía parámetros al servidor a través de la red, y el servidor completa el servicio correspondiente de acuerdo con los requisitos de los parámetros y luego devuelve los resultados al cliente. Una solicitud se completa cuando el cliente obtiene el resultado. Desde esta perspectiva, llamar a objetos remotos no parece difícil. El problema es que este método no es transparente en la red y usted mismo debe manejar cada detalle, lo cual es muy complicado.
Simplifique el diseño del software. Por supuesto, la operación de la red es transparente y ni la persona que llama ni el implementador necesitan preocuparse por la operación de la red. Para ello, podemos lograrlo de las siguientes maneras:
Los objetos proxy deben introducirse en el lado del cliente. Tiene plena autoridad para representar el objeto real. La persona que llama ni siquiera sabe que es un proxy y puede llamar a este objeto como si fuera un objeto local. Cuando la persona que llama llama a la función de proxy, el proxy no realiza operaciones reales, sino que encapsula estos parámetros en un paquete de datos de red y envía el paquete de datos al servidor a través de la red.
Se introduce un objeto stub en el servidor. Después de que el stub recibe el paquete de datos enviado por el agente, descomprime el paquete de datos, lo reorganiza en una lista de parámetros y utiliza estos parámetros para llamar a la función del objeto real. El objeto real realiza las operaciones relevantes y devuelve los resultados al Stub, que luego empaqueta los resultados en un paquete de red y envía el paquete a través de la red al proxy del cliente.
Después de que el agente reciba el paquete de resultados, lo descomprimirá en un valor de retorno y se lo devolverá a la persona que llama. En este punto, se completa toda la operación.
¿Qué tal? Simplifícalo.
El proxy oculta las operaciones de red del cliente y el stub oculta las operaciones de red del servidor, logrando transparencia de la red. Se podría argumentar que no existe ninguna simplificación, pero la red opera de forma aislada y la implementación de proxies y stubs sigue siendo la misma molestia.
Así es. Pero si estudia detenidamente las funciones de Proxy y Stub, encontrará que estas operaciones son similares para diferentes objetos. No son más que empaquetar y desempacar, repetidos monótonamente. Debe haber un patrón en las cosas que se repiten monótonamente. Si tiene reglas a seguir, puede utilizar un generador de códigos para generar código automáticamente.
Como DCOM y CORBA, por cierto. Primero, el lenguaje IDL se utiliza para describir la interfaz del objeto y luego el compilador IDL genera automáticamente código proxy y código auxiliar. Todo el proceso no requiere que los desarrolladores se preocupen en absoluto.
El término técnico para empaquetar y desempacar se llama agrupar y desempacar, que generalmente se traduce al chino como agrupar y dispersar. Pero estas dos palabras son demasiado técnicas y aún más confusas cuando se traducen al chino. Creo que es más informal utilizar las palabras empaquetar y desempacar.
En el modelo anterior, llamar a los métodos del objeto hace que la red sea transparente. Los lectores pueden preguntar, ¿qué se debe hacer si desea acceder a las propiedades de un objeto? Los atributos del objeto son variables, y las variables son áreas de memoria, y las áreas de memoria son completamente independientes en diferentes procesos. Esto parece ser un problema real. Todavía recuerdo lo que dicen muchos libros sobre diseño de software: no exponer las propiedades del objeto. La persona que llama debe acceder a las propiedades del objeto a través del método get/set. ¿No está bien? El acceso a las propiedades se convierte en llamadas a métodos de objetos.
Bien, llamar al método del objeto y acceder a las propiedades del objeto está resuelto. Otro punto importante es cómo se crean los objetos. Debido a que el objeto real no está fijo en la máquina, su posición puede ser dinámica. Incluso el propio agente no sabe dónde se está ejecutando el Stub. Si espera que la persona que llama lo especifique, el proceso de creación del objeto aún no es transparente para la red. El enfoque habitual es introducir un intermediario externo. Este intermediario es fijo y se puede encontrar mediante un método determinado. Un tercero intermediario es responsable de conectar el proxy del cliente y el stub del servidor. Por lo general, existen dos tipos de intermediarios externos: uno solo es responsable de ayudar al cliente a encontrar el servidor y luego el cliente se comunica directamente con el servidor. El otro es responsable no sólo de encontrar el servidor, sino también de reenviar todas las solicitudes.
El modelo anterior no está completo porque los objetos reales no siempre son pasivos. Pero bajo ciertas condiciones, algunos eventos se activarán activamente y se informarán a la persona que llama. En otras palabras, se trata de una acción bidireccional. El modelo C/S simple no puede cumplir con los requisitos y se debe utilizar el método P2P. El cliente original también existe como servidor y acepta solicitudes de su propio servidor. Al igual que en COM, si el cliente desea registrar el evento de un objeto, debe implementar una interfaz IDispatch y llamar al objeto en secuencia.
Cuando te des cuenta tú mismo, debes considerar los siguientes puntos:
l Capa de abstracción de transporte. La distribución puede ser entre procesos o entre máquinas. En diferentes situaciones y utilizando diferentes métodos de comunicación, el desempeño será diferente. Es un buen diseño crear una capa de abstracción de transmisión, que puede elegir diferentes métodos de transmisión en diferentes situaciones.
lTexto o binario. ¿Empaquetar datos en texto o binario? Las ventajas de empaquetar como texto son que es portátil y fácil de depurar porque la gente puede entenderlo. La desventaja es que la velocidad es un poco lenta y el tamaño de los datos empaquetados aumentará significativamente. La ventaja de usar binario es que es rápido y el tamaño de los datos después del empaquetado no es muy diferente del antes del empaquetado. La desventaja es que no es fácil de depurar y tiene poca portabilidad.
lOrden de bytes y alineación de bytes. La portabilidad es un problema si se transmite en binario. Debido a que existen algunas diferencias en el orden y la alineación de los bytes en diferentes máquinas, estas instrucciones deben agregarse al paquete para mejorar la portabilidad.