JavaプログラミングとPythonプログラミングの違いの詳細な分析
。JavaとPythonはどちらも比較的ホットなプログラミング言語です。Javaは2017年に世界一のプログラミング言語であり、Pythonは2017年に最も人気のあるプログラミング言語でした。どちらも不可欠です。違い。
JavaとPythonのバージョンはオープンソース言語であり、Javaコードの多くの中国語バージョンであり、Pythonは主に英語です。- さまざまなクロスプラットフォームメソッド
Javaクロスプラットフォームは、さまざまなクラスライブラリに依存して、さまざまなプラットフォームインターフェイスを提供し、クロスプラットフォーム効果を実現します。Pythonのクロスプラットフォームは、言語自体の特性によって決定され、多くのプラットフォームでPythonコードを直接記述することで実行できます。 - オブジェクト指向の
Java言語の設計は、オブジェクトとそのインターフェイスに重点を置いており、単純なクラスメカニズムと動的なインターフェイスモデルを提供します。オブジェクトは、状態変数と対応するメソッドをカプセル化して、モジュール性と情報の隠蔽を実現します。クラスはオブジェクトのクラスのプロトタイプを提供し、継承メカニズムを通じて、サブクラスは親クラスが提供するメソッドを使用して実現できます。コードの再利用。
Javaと比較して、Pythonは非常に強力でシンプルな方法でオブジェクト指向のプログラミングを実装します。Pythonは、プロセス指向の機能プログラミングとオブジェクト指向の抽象プログラミングの両方をサポートしています。プロセス指向の言語では、プログラムはプロセスまたは再利用可能なコードの関数から構築されます。オブジェクト指向の言語では、プログラムはデータと関数で構成されるオブジェクトから構築されます。
ファイル：n459.com/file/25127180-478863045
以下は関係ありません。
- - - - - - - - - - - - - - - - - - - - - -境界線 - - - ----------------------------------------
CNCFはじめに
CNCF（Cloud Native Computing Foundation）、中国語は「Cloud Native Computing Foundation」を意味し、CNCFはLinux Foundationの下にある財団であり、非営利団体として理解できます。
Googleでコンテナを調整するために内部で使用されていたBorgプロジェクトはオープンソースでした。プロジェクトのより良い開発のために、GoogleとLinuxFoundationは共同でCNCFを設立しました。同時に、GoogleはGoでBorgを書き直し、Kubernetesに名前を変更して、CNCFに寄付しました。
この組織の設立の当初の意図またはビジョンは、簡単に言えば：
クラウドネイティブコンピューティングの持続可能な開発を促進し、
クラウドネイティブテクノロジー開発者が優れた製品を迅速に構築できるよう支援します
。CNCFは、コミュニティを確立し、多数のオープンソースプロジェクトを管理することにより、テクノロジーとエコシステムの開発を促進します。
APMは、
誰もがAPM（Application Performance Monitoring）と分散トレースについて聞いたことがあるはずです。後者は前者のサブセットです。分散追跡は、主にマイクロサービスアーキテクチャでの過度に長い要求リンクによって引き起こされる位置決めと監視の難しい問題を解決するために、マイクロサービスの人気とともに出現した用語です。現在、この分野でよく知られている製品は、Jaeger、Pinpoint、Zipkinなどで、非常に競争力があると言えますが、これには問題があります。ほとんどすべてがに基づいていますが、それぞれに独自のデータ収集標準とSDKのセットがあります。 Google Dapper契約ですが、その実装は大きく異なります。この問題を解決するために、外国の神々が以前にOpenTracingとOpenCensusを作成しました。まず、これら2つの製品を見てみましょう。
OpenTracing
OpenTracingは、プラットフォームおよびベンダーに依存しない一連のプロトコル標準を開発しました。これにより、開発者は、基盤となるAPMの実装を簡単に追加または置換できます。
2016年11月にマイルストーンイベントが発生しました。CNCF.ioはOpenTracingを受け入れました。これはCNCFの3番目のプロジェクトでもあります。最初の2つはすでに有名です：KubernetesとPrometheus。これはオープンソースの世界がAPMの強調、統一された基準の強調と要望。
OpenTracingプロトコルに従う製品には、Jaeger、Zipkinなどがあります。
中国のOpenCensusには古いことわざがあります。ShengyuHeShengliang以来、OpenTracing自体が早く登場し、人気が高まっています。OpenCensusプロジェクトがあるのはなぜですか。
背景知識を追加しましょう。分散追跡については前述しました。実際、APMの分野では、非常に重要な監視サブカテゴリがあります。cpu、メモリ、ハードディスク、ネットワーク、その他のマシンインジケータなどのメトリックインジケータの監視、grpc要求の遅延、エラー率などのネットワークプロトコルインジケータ、およびユーザー数、訪問数、注文数などのビジネスインジケータをすべてカバーできます。
まず、このプロジェクトには非常に強力な父親がいます。Google、分散追跡に関する基本的な論文でさえGoogleによって提案されていることを知っておく必要があります。Googleは父親であると言えます。
第二に、OpenCensusの本来の目標は、OpenTracingの仕事をつかむことではなく、Go言語のメトリックコレクションとリンクトラッキングをGo言語に付属するプロファイルツールと統合して、ユーザーの使用法を統一することです。プロジェクトが進むにつれ、野心も広がりましたが、この時、他の言語のコレクションを統一してみませんか？その後、プロジェクトチームはOpenTracingを発見し、突然、私がGoogleとして標準をプレイしていないことを発見しました。標準をプレイして、世界を統一することをどのように考えますか？（これが著者のクレイジーな言葉です）したがって、OpenCensusのシーンはさらに拡張され、メトリックの基本的なインジケーターモニタリングだけでなく、OpenTracingの古いラインである分散トラッキングも拡張されました。
グーグルはすでにゴッドファーザーになるのに十分です、そしてゴッドファーザーとして別のマイクロソフトに参加しますか？離陸しようとしていますか？したがって、OpenCensusの開発において、Microsoftの直接の追加は、以前の競争力のバランスを崩し、間接的にOpenTelemetryプロジェクトの誕生につながったと言えます。
ここでのOpenTracingとOpenCensusは、SteveFlandersの比較チャートを直接取得しました。
特徴
OpenTracingとOpenCensusには、機能と機能の点でそれぞれ長所と短所があることがわかります。OpenTracingは、より多くの言語をサポートし、他のシステムへの結合を低くします。OpenCensusは、メトリック、分散トレースをサポートすると同時に、APIレイヤーからインフラストラクチャレイヤーまでをサポートします。
オープンソースコミュニティ
結果を区別するのは難しいですか？対照的に、コミュニティは活発です。私が行くと、それは大惨事の半分のようです。あなたは大衆を使用するより広い基盤を持っています、そして私はグーグルとマイクロソフトを持っています。
したがって、上記から2つの製品は非常に人気があることがわかりますが、オープンソースプロジェクトとして、この種の競争はリソースを消費しすぎてユーザーにとって不親切です。どうすればよいですか？
OpenTelemetry
言われているように、世界は長い間分割されなければならず、世界は長い間分割されなければなりません。このとき、ヒーローがいるに違いありません：OpenTelemetryが判明しました。
2つの製品を組み合わせるときに最初に考慮すべきことは何ですか？経験のある人なら誰でも、両側のユーザーがそれを使い続けることができるようにする方法を知っています。したがって、新しいプロジェクトの主な目標は、OpenTracingおよびOpenCensusとの互換性を保つことです。
OpenTelemetryのコア作業は、現在主に3つの部分に集中しています。
仕様の策定とプロトコルの統合。仕様には、データ送信とAPIの仕様が含まれます。プロトコルの統合には、HTTP W3C標準のサポートと
、GRPCフレームワークのプロトコル標準多言語SDKの実装と統合が含まれます。ユーザーはSDKを使用して自動コードインジェクションを行うことができます。また、手動の埋め込みポイントは、他の3者間ライブラリ（Log4j、LogBackなど）のサポートを統合しながら
、データ収集システムの実装は現在、エージェントやコレクターを含むOpenCensusサービス収集システムに基づいています。
OpenTelemetry自体の位置付けは非常に明確であることがわかります。データ収集と標準仕様の統合であり、公式にはデータの使用、保存、表示、アラートの方法は含まれていません。現在、メトリックの保存と表示にはPrometheus + Grafanaを使用することをお勧めします。 Jaegerを使用して、分散追跡を保存および表示します。
まず、背景知識を追加しましょう。APMの2つの監視サブカテゴリである分散追跡とメトリックについて説明しました。実際には、3番目のタイプであるロギングがあります。一般的なログ収集プラットフォームには現在EFKとFluentdが含まれています。
上の図でわかるように、主に次の理由により、ロギングが欠落しています。
優先度は、上記の3つのコアタスクに基づいています。現在のロギングの優先度は比較的低くなっています（P2）。
ロギングは通常、サードパーティのプラットフォームを介して収集されます。現在、分散追跡およびメトリックデータと統合する方法は公式から提供されていません。
統合の設計
上記の背景から、OpenTelemetryの最終的な目標である、実現メトリック、統合トレース、ロギング、および統合を、データ取得APMの最終ソリューションとして見ることができます。
トレース：受信から処理までのリクエストのライフサイクル全体のトレースパスを提供します。リクエストは通常N個のシステムを通過するため、分散リンクトレース
メトリックとも呼ばれます（cpu、リクエスト遅延、ユーザーアクセスカウントなど）。 、ゲージ、ヒストグラムインジケータ
ロギング：従来のログは正確なシステムレコードを提供します
。これら3つの組み合わせにより、統合されたAPMソリューションを形成できます。
メトリクスアラームに基づいて異常を検出
します。トレースを使用して特定のシステムとメソッドを特定します
。最後に、モジュールログに基づいてエラーの詳細と根本原因を特定します。
メトリクスやその他の設定を調整して、より正確なアラーム/問題を発見します。
統合するにはどうすればよいですか。
これまでのAPMの理解では、これら3つは完全に独立していますが、時間が経つにつれて、人々は徐々に3つの関係を発見しました。たとえば、トレースのTraceIDをログログに記録できます。分散リンク追跡とログを相互に関連付けてデータを相互に通信することはできますが、それでも次の問題があります。
メトリックを他の2つに
関連付ける方法要求されたメソッド名、URL、ユーザータイプ、デバイスタイプ、地理的位置など、より多くの次元の関連付けを提供する方法。
関連付けの関係はどのように一貫しており、分散システムの
OpenTelemetryで拡散できますか？ Contextを使用して、メトリック、ロギング、およびトレースの統一されたコンテキストを提供しようとしています。3つすべてがこの情報にアクセスできます。同時に、要求リンクが深くなるにつれて、Contextは広がり続ける可能性があります。
タスク/リクエストの実行サイクル中にコンテキストデータにアクセスして、
コンテキスト情報を保存し、さまざまな言語や処理モデル（シングルスレッドモデル、スレッドプールモデルなど）で確実に機能するようにするための統合ストレージレイヤーを提供できます。 CallBackモデル、Go Routineモデルなど）
複数のディメンションの関連付けは、メタ情報（タグ）に基づいて実現されます。メタ情報はビジネスによって決定されます。たとえば、Envは、テスト環境と本番環境を区別するために使用されます。
分散コンテキスト伝播方法は、W3Cなどを介して提供されます。 Traceparent / tracestateヘッダー、GRPCプロトコルなど。
まとめ
GoogleDapper契約が提案されてから何年も経ち、川や湖も長年戦ってきました。今回、GoogleとMicrosoftは川と湖を終わらせる決意です。これは、将来の分散システムの監視にとって本当に素晴らしいニュースです。また、この2人の巨人のリーダーシップの下で、プロジェクトはより良く発展すると信じる理由があります。将来的には、オープンソースのプロジェクト、フレームワーク、プラットフォームがますます増えるでしょう。OpenTelemetryは、モニタリングデータ標準の統合を最終的に実現するためにネイティブに使用されます。