¿Kafka es adecuado para usar en Docker? ¿Tiene sentido un clúster de una sola máquina?
Primero permítanme explicar la capacidad de implementación. Lo que se analiza aquí es la implementación de clústeres Yarn o Mesos, no las aplicaciones en ellos. Además de depender de JDK, Yarn no depende del sistema operativo. Básicamente, se puede ejecutar tan pronto como se instala. Debido a que Mesos está desarrollado en C/C, la instalación y la implementación pueden tener dependencias de biblioteca. No sé si todos se toman esto en serio, pero yo sí. El software debería poder ejecutarse tan pronto como se descargue. Entonces, en 2012, desarrollé un marco de servicio Java yo mismo. Después del desarrollo, simplemente ejecuté el método principal. Deje que la aplicación contenga contenedores en lugar de arrojarla a contenedores como Tomcat, que es demasiado complicado y poco intuitivo. Para los ingenieros de Java/Scala, el desarrollo secundario Yarn es solo un paquete Jar, similar al paquete de desarrollo de índice Lucene. Puede introducirlo en el proyecto y crear cualquier paquete que desee. Este es uno de ellos. En segundo lugar, Yarn proporciona muchas interfaces de extensión y muchas implementaciones se pueden conectar. Reemplazable. En la configuración XML, puede reemplazar fácilmente la implementación original con la suya propia. No es demasiado intrusivo, por lo que incluso si Yarn se actualiza en el futuro, no habrá grandes problemas. En comparación, Mesos se parece más a un producto listo para usar que se puede usar directamente después de la implementación, pero no es compatible con el desarrollo secundario. Ventajas ecológicas Yarn nació de Hadoop, el proyecto "creador" de big data, por lo que tiene ventajas inherentes en el campo de big data. La capa inferior es, naturalmente, el sistema de almacenamiento distribuido HDFS, que es estable y eficiente. Admite los primeros puestos en campos de big data como Spark y MR, y ha sido probado durante mucho tiempo. La comunidad es sólida, los lanzamientos de versiones recientes se han acelerado significativamente y el soporte para tareas largas es cada vez mejor. Soporte para tareas largas Hablando del soporte para servicios de larga duración, algunas personas piensan que Yarn fue diseñado originalmente para soportar tareas a corto plazo fuera de línea, por lo que puede tener soporte limitado para tareas largas. De hecho, no hay necesidad de preocuparse. Por ejemplo, SparkStreaming basado en él ahora se ejecuta las 24 horas del día, los 7 días de la semana, por lo que no hay problema para ejecutarlo. En términos generales, para soportar tareas largas, se deben considerar los siguientes puntos: Tolerancia a fallos, principalmente tolerancia a fallos de AM. YarnSecurity, si el mecanismo de seguridad está activado, también es necesario anotar el tiempo de vencimiento de los tokens, etc. Los registros se recopilan en el clúster. También hay aislamiento y prioridad de recursos. Si el aislamiento de recursos se realiza mal, tendrá un impacto en las tareas de larga duración. Si está interesado, puede consultar Jira primero. Creo que este Jira comenzó hace 13 años, lo que demuestra que este asunto se tomó en serio desde muy temprano. A continuación explicaremos algunos de los puntos mencionados por nuestro equipo. FaulttoleranceYarn en sí tiene alta disponibilidad. Actualmente, Yarn's Master ha implementado HA. Tolerancia a fallas AM, creo que la opción keepcontainersacrossattempt ha sido compatible desde la versión 2.4 (consulte el código fuente, es posible que sea compatible con versiones anteriores). ¿Qué significa? Es decir, si AM cuelga, durante el proceso de reinicio de Yarn, todos los contenedores administrados por AM se mantendrán y no se eliminarán. A menos que Yarn lo intente varias veces, no puede iniciar AM nuevamente (el valor predeterminado es dos veces). Esto demuestra que desde la perspectiva de la programación subyacente, se ha hecho muy bien. La recopilación de registros en el clúster La recopilación de registros en la versión 2.6 ya se realiza mientras se ejecuta. Aislamiento de recursos: en términos de aislamiento de recursos, Yarn no funciona bien. Actualmente, el efectivo es la memoria. Siempre hemos querido admitir otros aspectos, pero ha sido limitado. Esta es probablemente la razón por la que mucha gente finalmente elige Mesos. Pero ahora esta ventaja de Mesos ha desaparecido, porque los contenedores Docker han hecho un trabajo bastante bueno en el aislamiento de recursos. Una vez que Yarn y Docker se integran, se complementan. Resumen Mesos y Yarn son marcos de programación muy buenos, cada uno con sus propias ventajas y desventajas. La programación flexible y la gestión unificada de recursos son una tendencia en plataformas futuras. Marcos de programación y gestión de recursos similares seguramente se volverán populares.
Algunos malentendidos comunes nacieron de Hadoop y heredaron su halo y ecología. Sin embargo, esto también le traerá cierta confusión. En primer lugar, el halo ha sido cubierto por Hadoop y, debido a la inercia inherente, todos lo darán por sentado. Por supuesto, Yarn es solo un componente de Hadoop. ¿Alguien ha pensado alguna vez en sacar Yarn y usarlo por separado? Sin embargo, como enfaticé repetidamente en un curso anterior, Hadoop es una colección de software, que incluye almacenamiento distribuido, gestión y programación de recursos y un marco informático. No existe una relación necesaria entre ellos y pueden ser independientes. Yarn es un motor de programación y gestión de recursos. Su objetivo de diseño inicial es ser universal, no solo para ejecutar MR. Ya existen muchos servicios basados en Yarn, como Spark. Hay otro malentendido aquí. Actualmente, MR es básicamente sinónimo de lotes fuera de línea. Esta vez la gente piensa erróneamente que Yarn solo es adecuado para programar tareas por lotes fuera de línea. De hecho, este no es el caso. Ya he dado el análisis anterior. Yarn puede garantizar completamente el funcionamiento estable y confiable de tareas largas. Cómo desarrollar programas distribuidos basados en Yarn. Este artículo no le enseñará específicamente cómo usar la API de Yarn. Sin embargo, si desea conocer la API de Yarn pero cree que la documentación oficial es demasiado breve, puedo darle dos sugerencias aquí: Código. ejemplos de uso Puede consultar el código relacionado con SparkYarn. Puede considerarse como un adaptador de hilo muy optimizado. Compre un libro sobre Yarn y comprender su arquitectura también lo ayudará a comprender el diseño de su API. El siguiente contenido explorará los dos temas siguientes: Algunos preparativos necesarios para desarrollar programas distribuidos basados en Yarn Algunas ideas básicas para desarrollar sistemas de programación de contenedores basados en Yarn Algunos preparativos necesarios para desarrollar programas distribuidos basados en Yarn No debes arremangarte Solo comienza haciéndolo. ¿Qué necesitamos saber antes de comenzar? La API nativa de Yarn es de nivel demasiado bajo y demasiado complicada. Si desea desarrollar felizmente aplicaciones Yarn, es necesario encapsular la API de Yarn. Para ser flexible o satisfacer la mayoría de las necesidades de los desarrolladores, la API interactiva subyacente de Yarn es relativamente primitiva. Naturalmente, el desarrollo es muy difícil. No soy el único que piensa esto. La capa Twill y Adapter de Apache cuando fueron desarrolladas por Hulu en realidad están diseñadas para resolver este problema. Entonces, ¿por qué no usé Twill? La primera es que hay muy pocos documentos y la segunda es que es un poco complicado, no necesito algo tan complicado. Creo que en lugar de desarrollar tantas funciones, Twill debería escribir buena documentación. Lo mejor es desarrollar un marco que resuelva un tipo de problema. Yarn es solo un motor de programación y gestión de recursos de bajo nivel. Generalmente, es necesario desarrollar un marco basado en él para resolver problemas específicos. Tomando Spark como ejemplo, resuelve algunos problemas relacionados con la informática distribuida. El programador de contenedores que desarrollé es en realidad para resolver la implementación dinámica de aplicaciones web. Encima de ellos está su aplicación. Por ejemplo, si desea recopilar estadísticas de registros, solo necesita desarrollar una aplicación en Spark. Por ejemplo, si desea proporcionar un sistema de recomendación, solo necesita empaquetarlo en un contenedor y el programador del contenedor puede programarlo e implementarlo. En términos generales, las aplicaciones distribuidas basadas en Yarn deben ajustarse a este nivel: Yarn-gt; Adapter-gt; ApplicationAdapter es lo que dije primero, usted mismo encapsula la API de Yarn; Framework es un marco de programación que resuelve un tipo de problema y la aplicación es el sistema que realmente desea resolver su negocio. A través de este desacoplamiento, cada nivel sólo necesita centrarse en sus propios puntos funcionales centrales.
Es típico asegurarse de que su marco/aplicación de capa superior se pueda trasplantar a Spark. Puede ejecutarse en Mesos, en Yarn, en sí mismo (independiente), en tiempo real, en Yarn y en modo independiente. son bastantes de ellos. Esto se debe al hecho de que Spark en sí no depende del motor de programación y gestión de recursos subyacente. En realidad, estos son los dos beneficios que mencioné anteriormente, porque con el Adaptador, el Marco de la capa superior no necesita estar vinculado a un determinado motor de programación de recursos. El marco permite que la aplicación no necesite prestar atención a los asuntos de programación subyacentes, sino solo centrarse en el negocio. Además, para el Framework en el que ha trabajado tan duro para desarrollar, naturalmente espera que pueda ejecutarse en la plataforma y satisfacer las necesidades de las personas, ¿verdad? Algunas ideas básicas para desarrollar un sistema de programación de contenedores basado en Yarn Primero, debemos comprender dos conceptos: aplicaciones tontas. Las llamadas aplicaciones tontas se refieren a aplicaciones que no pueden interactuar directamente con el sistema distribuido, y el sistema distribuido solo puede controlar el ciclo de vida a través del contenedor, como cerrar o abrir. Las aplicaciones básicas típicas incluyen MySQL, Nginx, etc. Generalmente tienen sus propios métodos de interacción únicos, como la línea de comandos, el protocolo de socket o el protocolo HTTP. Componentes complementarios. Debido a la existencia de aplicaciones tontas, el sistema distribuido necesita un agente para interactuar con estas aplicaciones. Este proxy y la aplicación tonta del proxy tienen el mismo ciclo de vida. Un ejemplo típico es que después de cerrar un servicio, el sistema distribuido informará el evento. El sistema distribuido enviará el evento al componente complementario de Nginx. El componente complementario lo convertirá en instrucciones que Nginx pueda reconocer y. el servicio detenido se eliminará del sistema. Eliminado de la lista de Nginx ProxyBackend. En el sistema de programación de contenedores, si el NodeManager de Yarn administra directamente Docker, el propio Yarn necesita brindar soporte. La responsabilidad de Yarn es administrar, asignar y programar recursos. No es necesario combinarlo con una tecnología específica. Después de todo, Yarn es un marco general de programación y gestión de recursos. Con base en la teoría anterior, desarrollamos un marco basado en Yarn. Este marco será una estructura maestro-esclavo típica (esto está determinado por Yarn). Los esclavos de este marco son en realidad objetos complementarios de Docker. El maestro puede gestionar indirectamente el contenedor a través de estos esclavos. Describamos brevemente su proceso: el usuario envía la aplicación y solicita recursos; Yarn inicia el maestro del Framework; Yarn inicia el esclavo del Framework y envía un latido para que el maestro conozca el estado; del esclavo inicia Docker y el esclavo se inicia. Este dockercontainer tiene una correspondencia uno a uno; el esclavo monitorea periódicamente el contenedor; el esclavo sale automáticamente y se notifica a Yarn; y recupera recursos; el maestro descubre que un nodo ha fallado, emite una nueva solicitud de nodo, reinicia el esclavo en otro servidor y repite los pasos desde 2. Hay otro problema aquí. Si el esclavo se mata normalmente, el contenedor también se puede cerrar a través de JVMShudownHook. Pero si Kill-9 mata al esclavo o falla de manera anormal, puede causar una fuga de recursos. Actualmente, el maestro informa esta información a la plataforma de gestión del clúster, que la limpiará periódicamente. También puede almacenar esta información, como en Redis o MySQL, y luego iniciar la tarea de limpieza en segundo plano.
Después de comprender esta idea, la implementación específica se vuelve simple: desarrollar un programa maestro-esclavo basado en Yarn, y luego el esclavo administra el contenedor Docker correspondiente, incluida la aceptación de nuevas instrucciones. El maestro proporciona una interfaz de administración para mostrar información del contenedor y el estado de ejecución. Por supuesto, también puede desarrollar otro FrameworkB para interactuar específicamente con Nginx. Por ejemplo, si el sistema anterior realiza un cambio de nodo, notifica al maestro de B, y luego el maestro de B completa la actualización de Nginx a través de su propio componente complementario Slave, logrando así. Servicios back-end. Cambios y notificaciones automáticas.