{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Bloques de construcci\u00f3n de aplicaciones distribuidas. Segunda aproximaci\u00f3n","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anuncio<\/strong><\/p>\n

<\/p>\n

Colegas, a mediados del verano planeo lanzar otro ciclo de art\u00edculos sobre el dise\u00f1o de sistemas de servicio masivo: \u201cExperimento VTrade\u201d \u2014 un intento de escribir un marco para sistemas comerciales. En el ciclo se abordar\u00e1 la teor\u00eda y la pr\u00e1ctica de la construcci\u00f3n de bolsas, subastas y tiendas. Al final del art\u00edculo, propongo votar por los temas que les parezcan m\u00e1s interesantes.
\n<\/em><\/p>\n

<\/p>\n

\"Bloques<\/p>\n

<\/p>\n

Este es el art\u00edculo final del ciclo sobre aplicaciones reactivas distribuidas en Erlang\/Elixir. En primer art\u00edculo<\/a><\/noindex> se pueden encontrar los fundamentos te\u00f3ricos de la arquitectura reactiva. El segundo art\u00edculo<\/a><\/noindex> ilustra los principales patrones y mecanismos para construir tales sistemas.<\/p>\n

<\/p>\n

Hoy abordaremos cuestiones sobre el desarrollo de la base de c\u00f3digo y los proyectos en general. <\/p>\n

<\/a><\/noindex><\/p>\n

Organizaci\u00f3n de servicios<\/h2>\n

<\/p>\n

En la vida real, al desarrollar un servicio, a menudo es necesario combinar varios patrones de interacci\u00f3n en un solo controlador. Por ejemplo, el servicio de usuarios, que se encarga de gestionar los perfiles de los usuarios del proyecto, debe responder a solicitudes req-resp y comunicar actualizaciones de los perfiles a trav\u00e9s de pub-sub. Este caso es bastante simple: un controlador gestiona la l\u00f3gica del servicio y publica las actualizaciones.<\/p>\n

<\/p>\n

La situaci\u00f3n se complica cuando necesitamos implementar un servicio distribuido tolerante a fallos. Supongamos que los requisitos para los usuarios han cambiado: <\/p>\n

<\/p>\n

    \n
  1. ahora el servicio debe manejar solicitudes en 5 nodos del cl\u00faster, <\/li>\n
  2. tener la capacidad de ejecutar tareas en segundo plano, <\/li>\n
  3. y tambi\u00e9n ser capaz de gestionar din\u00e1micamente las listas de suscripci\u00f3n a las actualizaciones de los perfiles.<\/li>\n<\/ol>\n

    <\/p>\n

    Nota:<\/em> No abordamos la cuesti\u00f3n del almacenamiento consistente y la replicaci\u00f3n de datos. Supongamos que estas cuestiones ya se han resuelto y que en el sistema ya existe una capa de almacenamiento confiable y escalable, y que los controladores tienen mecanismos para interactuar con ella.<\/p>\n

    <\/p>\n

    La descripci\u00f3n formal del servicio de usuarios se ha complicado. Desde el punto de vista del programador, gracias al uso de mensajer\u00eda, los cambios son m\u00ednimos. Para satisfacer el primer requisito, necesitamos configurar la balanceo en el punto de intercambio req-resp. <\/p>\n

    <\/p>\n

    La necesidad de procesar tareas en segundo plano es com\u00fan. En los usuarios, esto puede incluir verificaciones de documentos de los usuarios, procesamiento de multimedia cargada o sincronizaci\u00f3n de datos con redes sociales. Estas tareas deben ser distribuidas de alguna manera dentro del cl\u00faster y controlarse su progreso. Por ello, tenemos dos opciones: usar la plantilla de distribuci\u00f3n de tareas del art\u00edculo anterior, o, si no es adecuada, escribir un programador de tareas personalizado que gestione el grupo de manejadores de la manera que necesitamos. <\/p>\n

    <\/p>\n

    El punto 3 requiere ampliar la plantilla pub-sub. Y para implementarlo, tras la creaci\u00f3n del punto de intercambio pub-sub, necesitamos iniciar adicionalmente el controlador de este punto dentro de nuestro servicio. As\u00ed, parece que estamos separando la l\u00f3gica de procesamiento de las suscripciones y desuscripciones de la capa de mensajer\u00eda a la implementaci\u00f3n de usuarios.<\/p>\n

    <\/p>\n

    Como resultado, la descomposici\u00f3n de la tarea mostr\u00f3 que para satisfacer los requisitos necesitamos lanzar 5 instancias del servicio en diferentes nodos y crear una entidad adicional: un controlador pub-sub, responsable de las suscripciones.
    \nPara lanzar 5 manejadores no se requiere cambiar el c\u00f3digo del servicio. La \u00fanica acci\u00f3n adicional es la configuraci\u00f3n de las reglas de balanceo en el punto de intercambio, de lo que hablaremos m\u00e1s adelante.
    \nAdem\u00e1s, surgi\u00f3 una complejidad adicional: el controlador pub-sub y el planificador de tareas personalizado deben funcionar en una \u00fanica instancia. Nuevamente, el servicio de mensajer\u00eda, como fundamental, debe proporcionar un mecanismo para elegir un l\u00edder.<\/p>\n

    <\/p>\n

    Elecci\u00f3n del l\u00edder<\/h3>\n

    <\/p>\n

    En sistemas distribuidos, la elecci\u00f3n del l\u00edder es el procedimiento de designaci\u00f3n de un \u00fanico proceso encargado de planificar el procesamiento distribuido de alguna carga. <\/p>\n

    <\/p>\n

    En sistemas que no tienden a la centralizaci\u00f3n, se utilizan algoritmos universales y algoritmos basados en consenso, como paxos o raft.
    \nDado que la mensajer\u00eda es un corredor y un elemento central, conoce a todos los controladores del servicio que son candidatos a l\u00edderes. La mensajer\u00eda puede designar un l\u00edder sin la necesidad de una votaci\u00f3n.<\/p>\n

    <\/p>\n

    Todos los servicios, tras su inicio y conexi\u00f3n al punto de intercambio, reciben un mensaje del sistema #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. En caso de que LeaderPid<\/code> coincida con pid<\/code> del proceso actual, se le designa como l\u00edder, y la lista Servers<\/code> incluye todos los nodos y sus par\u00e1metros.
    \nEn el momento de la aparici\u00f3n de un nuevo nodo y la desconexi\u00f3n de un nodo en funcionamiento del cl\u00faster, todos los controladores del servicio reciben #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> y #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> correspondientemente.<\/p>\n

    <\/p>\n

    De este modo, todos los componentes son conscientes de todos los cambios, y en el cl\u00faster hay garantizado un l\u00edder en cada momento.<\/p>\n

    <\/p>\n

    Intermediarios<\/h2>\n

    <\/p>\n

    Para implementar procesos complejos de procesamiento distribuido, as\u00ed como en tareas de optimizaci\u00f3n de arquitecturas existentes, es conveniente utilizar intermediarios.
    \nPara no modificar el c\u00f3digo de los servicios y resolver, por ejemplo, tareas de procesamiento adicional, enrutamiento o registro de mensajes, se puede incluir un manejador proxy delante del servicio, que realizar\u00e1 todo el trabajo adicional.<\/p>\n

    <\/p>\n

    Un ejemplo cl\u00e1sico de optimizaci\u00f3n pub-sub es una aplicaci\u00f3n distribuida con un n\u00facleo comercial que genera eventos de actualizaci\u00f3n, como cambios en los precios del mercado, y una capa de acceso: N servidores que proporcionan API websocket para clientes web.
    \nSi se aborda de manera directa, el servicio al cliente se ve de la siguiente manera:<\/p>\n

    <\/p>\n