Análisis en profundidad de la diferencia entre la programación Java y la programación Python.
Tanto Java como Python son lenguajes de programación relativamente populares. Java fue el lenguaje de programación número uno del mundo en 2017 y Python fue el lenguaje de programación más popular en 2017. Ambos son esenciales. la diferencia.
- La versión de
Java y Python son lenguajes de código abierto, muchas versiones en chino del código Java, Python está principalmente en inglés. - Diferentes métodos multiplataforma
Java multiplataforma se basa en varias bibliotecas de clases para proporcionar varias interfaces de plataforma para lograr efectos multiplataforma; mientras que la multiplataforma de Python está determinada por las características del lenguaje en sí, y se puede ejecutar escribiendo directamente código Python en muchas plataformas.
El diseño del lenguaje Java orientado a objetos se centra en los objetos y sus interfaces, y proporciona un mecanismo de clase simple y un modelo de interfaz dinámico. El objeto encapsula sus variables de estado y los métodos correspondientes para lograr la modularidad y el ocultamiento de la información; mientras que la clase proporciona un prototipo de una clase de objetos y, a través del mecanismo de herencia, las subclases pueden usar los métodos proporcionados por la clase principal para lograr Reutilización de código.
En comparación con Java, Python implementa la programación orientada a objetos de una manera muy potente y sencilla. Python admite tanto la programación funcional orientada a procesos como la programación abstracta orientada a objetos. En un lenguaje orientado a procesos, un programa se construye a partir de un proceso o simplemente una función de código reutilizable. En un lenguaje orientado a objetos, los programas se construyen a partir de objetos compuestos de datos y funciones.
Archivo: n459.com/file/25127180-478863045
Los siguientes son irrelevantes:
-------------------------------------------Línea divisoria----- ----------------------------------------
CNCF Introducción
CNCF (Cloud Native Computing Foundation), chino significa "Cloud Native Computing Foundation", CNCF es una fundación de la Fundación Linux, puede entenderse como una organización sin fines de lucro.
El proyecto Borg, que se había utilizado internamente para orquestar contenedores en Google, era de código abierto. Para un mejor desarrollo del proyecto, Google y la Fundación Linux fundaron conjuntamente CNCF. Al mismo tiempo, Google reescribió Borg in Go, lo renombró Kubernetes y lo donó a CNCF.
La intención o visión original del establecimiento de esta organización, en pocas palabras:
Promover el desarrollo sostenible de la computación nativa de la nube;
ayudar a los desarrolladores de tecnología nativa de la nube a crear rápidamente productos excepcionales;
CNCF promueve el desarrollo de la tecnología y el ecosistema mediante el establecimiento de comunidades y la gestión de numerosos proyectos de código abierto.
APM
Todo el mundo debería haber oído hablar de APM (Application Performance Monitoring) y Distributed Tracing (seguimiento distribuido). Este último es un subconjunto del primero. El seguimiento distribuido es un término que surgió con la popularidad de los microservicios, principalmente para resolver el difícil problema de posicionamiento y monitoreo causado por enlaces de solicitud excesivamente largos en la arquitectura de microservicios. En la actualidad, los productos más conocidos en este campo son: Jaeger, Pinpoint, Zipkin, etc., que se puede decir que son extremadamente competitivos, pero esto trae un problema: cada uno tiene su propio conjunto de estándares de recolección de datos y SDK, aunque casi todos se basan en Acuerdo de Google Dapper, pero su implementación es muy diferente. Para resolver este problema, los dioses extranjeros crearon OpenTracing y OpenCensus antes. Echemos un vistazo a estos dos productos primero.
OpenTracing
OpenTracing ha desarrollado un conjunto de estándares de protocolo independientes de la plataforma y del proveedor, lo que permite a los desarrolladores agregar o reemplazar fácilmente la implementación del APM subyacente.
En noviembre de 2016 se produjo un hito. CNCF.io aceptó OpenTracing. Este es también el tercer proyecto de CNCF. Los dos primeros ya se han hecho famosos: Kubernetes y Prometheus. Esto demuestra que el mundo del código abierto ha El énfasis de APM, el énfasis y el deseo de estándares uniformes.
Los productos que siguen el protocolo OpenTracing incluyen Jaeger, Zipkin, etc.
Hay un viejo dicho en OpenCensus en China. Desde Shengyu He Shengliang, OpenTracing apareció antes y más popular. ¿Por qué hay un proyecto OpenCensus?
Permítanme agregar conocimientos básicos. Mencioné el seguimiento distribuido anteriormente. De hecho, en el campo de APM, hay una subcategoría de monitoreo extremadamente importante: monitoreo de indicadores de métricas, como cpu, memoria, disco duro, red y otros indicadores de máquina, retardo de solicitud de grpc, Se pueden cubrir los indicadores de protocolo de red, como la tasa de error, los indicadores comerciales como el número de usuarios, visitas y pedidos.
En primer lugar, el proyecto tiene un padre muy poderoso: Google, debes saber que hasta el documento básico sobre rastreo distribuido lo propone Google, se puede decir que Google es un padre.
En segundo lugar, el objetivo original de OpenCensus no es tomar el trabajo de OpenTracing, sino integrar la colección de métricas y el seguimiento de enlaces del idioma Go con la herramienta de perfil que viene con el idioma Go para unificar el uso del usuario. A medida que avanzaba el proyecto, las ambiciones también se expandían.En ese momento, comencé a imaginarme ¿por qué no unificar la colección de otros lenguajes? Luego, el equipo del proyecto descubrió OpenTracing y, de repente, descubrió que I K, como Google, no jugamos con los estándares. ¿Cómo te atreves a jugar con los estándares y pensar en unificar el mundo? (Aquí están las palabras locas del autor) Entonces, la escena de OpenCensus se ha expandido aún más, no solo lo hizo el monitoreo básico de indicadores de Metrics, sino también la antigua línea de OpenTracing: seguimiento distribuido.
¿Un Google ya es lo suficientemente bueno como para ser padrino, y luego unirse a otro Microsoft como padrino? ¿Está a punto de despegar? Por lo tanto, para el desarrollo de OpenCensus, se puede decir que la incorporación directa de Microsoft rompió el equilibrio competitivo anterior e indirectamente condujo al nacimiento del proyecto OpenTelemetry.
OpenTracing vs OpenCensus
aquí tomó directamente la tabla de comparación de Steve Flanders
Caracteristicas
Se puede ver que OpenTracing y OpenCensus tienen sus propias ventajas y desventajas en términos de funciones y características. OpenTracing admite más lenguajes y menor acoplamiento a otros sistemas; OpenCensus admite métricas, seguimiento distribuido y, al mismo tiempo, admite desde la capa de API hasta la capa de infraestructura.
Comunidad de código abierto
¿Es difícil distinguir el resultado? En contraste, la comunidad está activa. Yo voy, parece ser la mitad de una catástrofe. Tienes un uso más amplio de la base masiva, y yo tengo Google y Microsoft.
Por lo tanto, de lo anterior se puede ver que los dos productos son realmente populares, pero como proyecto de código abierto, este tipo de competencia consume demasiados recursos y es hostil para los usuarios. ¿Qué debo hacer?
OpenTelemetry
Como dice el refrán: el mundo debe estar dividido durante mucho tiempo y el mundo debe estar dividido durante mucho tiempo.En este momento, debe haber un héroe: resultó OpenTelemetry.
¿Qué es lo primero a considerar al combinar dos productos? Cualquiera que haya tenido experiencia sabe cómo permitir que los usuarios de ambos lados continúen usándolo. Por lo tanto, el objetivo principal del nuevo proyecto es ser compatible con OpenTracing y OpenCensus.
El trabajo central de OpenTelemetry actualmente se concentra principalmente en 3 partes:
La formulación de la especificación y la unificación del protocolo. La especificación incluye la especificación de transmisión de datos y API. La unificación del protocolo incluye: soporte del estándar HTTP W3C y
la implementación e integración del protocolo estándar SDK multilenguaje del marco GRPC . Los usuarios pueden usar el SDK para la inyección automática de código Y puntos de enterramiento manuales, al tiempo que proporciona soporte integrado para otras bibliotecas de tres partes (Log4j, LogBack, etc.);
la implementación del sistema de recopilación de datos se basa actualmente en el sistema de recopilación de OpenCensus Service, incluido el Agente y el Recopilador.
Se puede ver que el posicionamiento propio de OpenTelemetry es muy claro: la unificación de la recopilación de datos y las especificaciones estándar, el funcionario no involucra cómo se usan, almacenan, muestran y alarman los datos. Actualmente recomendamos usar Prometheus + Grafana para el almacenamiento y visualización de métricas. Utilice Jaeger para almacenar y mostrar el seguimiento distribuido.
En primer lugar, permítanme agregar conocimientos previos. Mencioné dos subcategorías de monitoreo de APM: Seguimiento distribuido y Métricas. De hecho, hay un tercer tipo, Registro. Las plataformas comunes de recolección de registros actualmente incluyen EFK y Fluentd.
Como puede ver en la figura anterior, falta el registro, principalmente debido a las siguientes razones:
La prioridad se basa en las tres tareas básicas mencionadas anteriormente. La prioridad actual de Registro es relativamente baja (P2).
Generalmente, el registro se recopila a través de una plataforma tripartita. Actualmente, el funcionario no ha proporcionado la forma de integración con el seguimiento distribuido y los datos de métricas el diseño de
lo unificado
Con el trasfondo anterior, podemos mirar el objetivo final superior de OpenTelemetry: la realización de Métricas, Rastreo de integración, Registro y unificado, como una solución definitiva de adquisición de datos APM.
Seguimiento: proporciona una ruta de seguimiento para todo el ciclo de vida de una solicitud, desde la recepción hasta el procesamiento. Una solicitud generalmente pasa a través de N sistemas, por lo que también se denomina
métrica de seguimiento de enlaces distribuidos : como cpu, demora de solicitud, recuento de acceso de usuario, etc. , Medidor, Indicador de histograma
Registro: Los registros tradicionales proporcionan registros precisos del sistema
. La combinación de estos tres puede formar una solución APM unificada:
Detecta anomalías en función de las alarmas de métricas.
Usa el rastreo para localizar sistemas y métodos específicos
. Por último, localiza los detalles del error y las causas raíz en función de los registros del módulo.
Ajusta las métricas y otras configuraciones para alarmas más precisas / descubre problemas.
¿Cómo integrar?
En la comprensión anterior de APM, estos tres son completamente independientes, pero a medida que pasa el tiempo, la gente descubre gradualmente la relación entre los tres. Por ejemplo, podemos poner el TraceID de Tracing en el registro de registro, por lo que El seguimiento de enlaces distribuidos y los registros se pueden asociar para comunicar datos entre sí, pero aún existen los siguientes problemas:
Cómo asociar las métricas con las otras dos.
Cómo proporcionar asociaciones más dimensionales, como el nombre del método solicitado, la URL, el tipo de usuario, el tipo de dispositivo, la ubicación geográfica, etc.
¿Cómo la relación de asociación es coherente y se puede difundir
en OpenTelemetry en un sistema distribuido ? Intentando utilizar Context para proporcionar un contexto unificado para las métricas, el registro y el seguimiento. Los tres pueden acceder a esta información. Al mismo tiempo, el contexto puede continuar expandiéndose a medida que se profundiza el enlace de solicitud.
Se puede acceder a los datos de contexto durante el ciclo de ejecución de Tarea / Solicitud para
proporcionar una capa de almacenamiento unificada para guardar la información de contexto y garantizar que pueda funcionar en varios idiomas y modelos de procesamiento (como el modelo de un solo subproceso, el modelo de grupo de subprocesos, Modelo CallBack, modelo Go Routine, etc.)
La asociación de múltiples dimensiones se realiza en base a metainformación (etiquetas). La metainformación la determina la empresa. Por ejemplo, Env se utiliza para distinguir entre entornos de prueba y de producción.
Se proporcionan métodos de propagación de contexto distribuido, como a través de W3C. Encabezado de seguimiento / seguimiento de estado, protocolo GRPC, etc.
Resumen
Han pasado muchos años desde que se propuso el acuerdo Google Dapper, y los ríos y lagos también han estado luchando durante muchos años. Esta vez, Google y Microsoft están decididos a acabar con los ríos y lagos. Esta es una gran noticia para el monitoreo de sistemas distribuidos en el futuro. También tenemos razones para creer que bajo el liderazgo de estos dos gigantes, el proyecto se desarrollará mejor. En el futuro, habrá más y más proyectos, marcos y plataformas de código abierto. OpenTelemetry se utilizará de forma nativa para finalmente lograr la unificación de los estándares de datos de monitoreo.