In-depth analysis of the difference between Java programming and Python programming.
Both Java and Python are relatively hot programming languages. Java was the world's number one programming language in 2017, and Python was the most popular programming language in 2017. Both are essential. the difference.
- Version of
Java and Python are open source languages, many Chinese version of Java code, Python is mainly in English. - Different cross-platform methods
Java cross-platform relies on various class libraries to provide various platform interfaces to achieve cross-platform effects; while Python's cross-platform is determined by the characteristics of the language itself, and it can be run by directly writing Python code on many platforms.
The design of object-oriented Java language focuses on objects and their interfaces. It provides a simple class mechanism and a dynamic interface model. The object encapsulates its state variables and corresponding methods to achieve modularity and information hiding; while the class provides a prototype of a class of objects, and through the inheritance mechanism, subclasses can use the methods provided by the parent class to achieve Code reuse.
Compared with Java, Python implements object-oriented programming in a very powerful and simple way. Python supports both process-oriented functional programming and object-oriented abstract programming. In a process-oriented language, a program is constructed from a process or just a function of reusable code. In an object-oriented language, programs are constructed from objects composed of data and functions.
File: n459.com/file/25127180-478863045
The following are irrelevant:
-------------------------------------------Dividing line----- ----------------------------------------
CNCF Introduction
CNCF (Cloud Native Computing Foundation), Chinese means "Cloud Native Computing Foundation", CNCF is a foundation under the Linux Foundation, can be understood as a non-profit organization.
The Borg project, which had been used internally for orchestrating containers at Google, was open sourced. For the better development of the project, Google and the Linux Foundation jointly founded CNCF. At the same time, Google rewritten Borg in Go, renamed it Kubernetes and donated it to CNCF.
The original intention or vision of the establishment of this organization, simply put:
Promote the sustainable development of cloud-native computing;
help cloud-native technology developers quickly build outstanding products;
CNCF promotes technology and ecosystem development by establishing communities and managing numerous open source projects.
APM
everyone should have heard of APM (Application Performance Monitoring) and Distributed Tracing, of which the latter is a subset of the former. Distributed tracking is a term that emerged with the popularity of microservices, mainly to solve the difficult problem of positioning and monitoring caused by excessively long request links in the microservice architecture. At present, the well-known products in this field are: Jaeger, Pinpoint, Zipkin, etc., which can be said to be extremely competitive, but this brings about a problem: each has its own set of data collection standards and SDK, although almost all are based on Google Dapper agreement, but their implementation is very different. In order to solve this problem, foreign gods have created OpenTracing and OpenCensus before. Let's take a look at these two products first.
OpenTracing
OpenTracing has developed a set of platform-independent and vendor-independent protocol standards, allowing developers to easily add or replace the implementation of the underlying APM.
In November 2016, a milestone event occurred. CNCF.io accepted OpenTracing. This is also the third project of CNCF. The first two are already famous: Kubernetes, and Prometheus. This shows that the open source world has The emphasis of APM, the emphasis and desire for uniform standards.
Products that follow the OpenTracing protocol include Jaeger, Zipkin, and so on.
There is an old saying in OpenCensus in China. Since Shengyu He Shengliang, OpenTracing itself appeared earlier and more popular. Why is there an OpenCensus project?
Let me add background knowledge. I mentioned distributed tracking earlier. In fact, in the field of APM, there is an extremely important monitoring sub-category: Metrics indicator monitoring, such as cpu, memory, hard disk, network and other machine indicators, grpc request delay, Network protocol indicators such as error rate, and business indicators such as the number of users, visits, and orders can all be covered.
First of all, the project has a very powerful father: Google, you must know that even the basic paper on distributed tracking is proposed by Google. It can be said that Google is a father.
Secondly, the original goal of OpenCensus is not to grab the job of OpenTracing, but to integrate the Metrics collection and link tracking of the Go language with the profile tool that comes with the Go language to unify the user's usage. As the project progressed, ambitions also expanded. At this time, I began to imagine why not unify the collection of other languages? Then the project team discovered OpenTracing, and suddenly discovered that I K, as Google, we don’t play standards. How dare you play standards and think about unifying the world? (Here is the author's crazy words) So, the scene of OpenCensus has been further expanded, not only did Metrics basic indicator monitoring, but also did OpenTracing's old line: distributed tracking.
A Google is already good enough to be a godfather, then join another Microsoft as a godfather? Is it about to take off? Therefore, for the development of OpenCensus, the direct addition of Microsoft can be said to have broken the previous competitive balance and indirectly led to the birth of the OpenTelemetry project.
OpenTracing vs OpenCensus
here directly took the comparison chart of Steve Flanders
Features
It can be seen that OpenTracing and OpenCensus have their own advantages and disadvantages in terms of functions and features. OpenTracing supports more languages and lower coupling to other systems; OpenCensus supports Metrics, distributed tracing, and at the same time supports from the API layer to the infrastructure layer.
Open source community
Hard to distinguish the outcome? In contrast, the community is active. I go, it seems to be half a catastrophe. You have a wider use of the mass base, and I have Google and Microsoft.
Therefore, it can be seen from the above that the two products are really popular, but as an open source project, this kind of competition is too resource-consuming and unfriendly to users. What should I do?
OpenTelemetry
As the saying goes: the world must be divided for a long time, and the world must be divided for a long time. At this time, there must be a hero: OpenTelemetry turned out.
What is the first thing to consider when combining two products? Anyone who has had experience knows how to enable users on both sides to continue using it. Therefore, the primary core goal of the new project is to be compatible with OpenTracing and OpenCensus.
The core work of OpenTelemetry is currently mainly concentrated in 3 parts:
The formulation of the specification and the unification of the protocol. The specification includes the specification of data transmission and API. The unification of the protocol includes: HTTP W3C standard support and
the implementation and integration of the protocol standard multi-language SDK of the GRPC framework . Users can use the SDK for automatic code injection And manual burying points, while providing integrated support for other three-party libraries (Log4j, LogBack, etc.);
the implementation of the data collection system is currently based on the OpenCensus Service collection system, including Agent and Collector.
It can be seen that OpenTelemetry's own positioning is very clear: the unification of data collection and standard specifications, the official does not involve how data is used, stored, displayed, and alarmed. We currently recommend using Prometheus + Grafana for Metrics storage and display. Use Jaeger to store and display distributed tracking.
First of all, let me add background knowledge. I mentioned the two monitoring subcategories of APM: Distributed Tracking and Metrics. In fact, there is a third type, Logging. Common log collection platforms currently include EFK and Fluentd.
As you can see in the above figure, Logging is missing, mainly due to the following reasons:
The priority is based on the three core tasks mentioned above. The current priority of Logging is relatively low (P2).
Logging is generally collected through a three-party platform. Currently, how to integrate with distributed tracking and Metrics data has not been given by the official the design of
the unified
With the above background, we can look at the top OpenTelemetry ultimate goal: the realization Metrics, integration Tracing, Logging and unified, as a data acquisition APM ultimate solution.
Tracing: Provides a tracing path for the entire life cycle of a request from receipt to processing. A request usually passes through N systems, so it is also called distributed link tracing
metrics: such as cpu, request delay, user access count, etc. , Gauge, Histogram indicator
Logging: Traditional logs provide accurate system records
. The combination of these three can form a unified APM solution:
Detect abnormalities based on Metrics alarms.
Use Tracing to locate specific systems and methods
. Finally locate the error details and root causes based on the module logs.
Adjust Metrics and other settings to more precise alarms/discover problems.
How to integrate?
In the past understanding of APM, these three are completely independent, but as time goes by, people gradually discovered the relationship between the three. For example, we can put the TraceID of Tracing into the Logging log, so Distributed link tracking and logs can be associated together to communicate data with each other, but there are still the following problems:
How to associate Metrics with the other two
How to provide more dimensional associations, such as the requested method name, URL, user type, device type, geographic location, etc.
How does the association relationship be consistent and can be spread
in OpenTelemetry in a distributed system ? Trying to use Context to provide a unified context for Metrics, Logging, and Tracing. All three can access this information. At the same time, Context can continue to spread down as the request link deepens.
Context data can be accessed during the execution cycle of Task/Request to
provide a unified storage layer for saving Context information and ensuring that it can work under various languages and processing models (such as single-threaded model, thread pool model, CallBack model, Go Routine model, etc.)
The association of multiple dimensions is based on meta-information (tags). Meta-information is determined by the business. For example, Env is used to distinguish between test and production environments.
Distributed context propagation methods are provided, for example, through W3C. Traceparent/tracestate header, GRPC protocol, etc.
Summary
It has been many years since the Google Dapper agreement was proposed, and the rivers and lakes have also been fighting for many years. This time Google and Microsoft are determined to end the rivers and lakes. This is really great news for the monitoring of distributed systems in the future. We also have reason to believe that under the leadership of these two giants, the project will develop better. In the future, there will be more and more open source projects, frameworks, and platforms. OpenTelemetry will be used natively to finally realize the unification of monitoring data standards.