ホームページ >バックエンド開発 >Python チュートリアル >Dubbo が Go で書き直されるのはなぜですか?
私は技術的な「なぜ」の質問をよく考えます。 「歩いているとき、時々、ある問題について長い間考えますが、その問題のすべての点について自分自身を納得させるまで、それは終わりません。そこで、その思いを記録し、新たなシリーズとして記事にしたいと思います。これらの記事ではコードを見ることはできないかもしれませんが、見落とされがちないくつかの問題と、問題のより深い「理由」を垣間見ることができます。
今日は最初の記事です。なぜ Dubbo を Go で書き直す必要があるのですか?
Dubbo は Alibaba で生まれ、2011 年にオープンソース化されましたが、10 年が経ちました。 2019 年に Go で書き直されてオープンソース化され、2 年後の現在ではオリジナルの V1.0.0 バージョンから V3.0.0 に開発され、スター数は現在 3.8K となっています。
ある同僚が、なぜ Dubbo のような「古い」プロジェクトを Go で書き直す必要があるのかと尋ねました。それには実用的な意味がありますか?
今日は私の意見をいくつか話させてください。
この質問にうまく答えるには、Dubbo-go の本来の目的から始める必要があると思います。GitHub ホームページでは次のように紹介されています。
##正式な中国語訳は Apache Dubbo Go 言語実装、Java と Golang 間のブリッジの構築、gRPC との相互接続です。 /Dubbo エコシステムの相互運用性により、Java エコシステムはクラウド ネイティブ時代の技術的恩恵を享受できるようになります。 わかりやすく言い換えると、会社や部門で Java バージョンの Dubbo を使用する人もいれば、Go を使用する人もいます。この 2 つはコミュニケーションする必要があるため、Dubbo-Go はコミュニケーションを解決するために作成されました。問題。 最初の質問は、なぜ企業が Java を使用し、次に Go を使用するのかということです。プログラミング言語の選択ビジネスにおけるプログラミング言語の選択について会社内, 最も重要なことは効率であり、その他の点は二の次だと思います。営利企業の主な目的は利益を上げることなので、どのような言語であっても、最小限のコストで同等の利益が得られるのであれば、それは良い言語です。 効率にはいくつかの側面が含まれます:Thrift のみがこれより古いですが、Thrift は単なる RPC フレームワークであるのに対し、Dubbo には、サービスの登録と検出、ロード バランシング、フォールト トレランス、動的構成などのすぐに使用できるサービス管理機能が含まれています。
初期の Java RPC フレームワークには選択肢がなかったと言えます。
RPC フレームワークが隆盛を極め、多くの企業が RPC フレームワークを使用し、アリババの支持を得ている時代でも、Dubbo は依然としてその地位を保っています。
企業が Java プログラミング言語と Dubbo フレームワーク (まだ多くの選択肢があります) を選択し、その後 Go を試してみたい場合、または一部の新しいビジネスや新しい部門で Go を試してみたい場合その際、Go で Java の Dubbo とどのように通信するかという問題に直面しました。
Dubbo プロトコルはプライベート プロトコルであるため、Go で再実装するコストは依然としてかなり高くなります。この観点から見ると、Dubbo-Go は Java と Go の間の通信において依然として大きな価値を持っています。
Dubbo フレームワークを使用する場合、多くの場合、Dubbo ゲートウェイが必要になります。Dubbo ゲートウェイの詳細については、私の記事「The Evolution」を参照してください。マイクロサービス ゲートウェイの」。
この記事では、Dubbo ゲートウェイの背景、困難、選択、設計、進化、落とし穴の経験を詳しく紹介し、「スレッド プールで何をしたか」を紹介することに多くの時間を費やしました。 ", Java ではスレッドは非常に貴重ですが、Dubbo ゲートウェイが同期的に呼び出される場合、1 つのリクエストが 1 つのスレッドを占有する必要があり、その結果同時実行エラーが発生し、スレッド プールがいっぱいになると他のリクエストに影響を及ぼします。
したがって、解決策は、スレッド プールを分離するか、スレッド プールを非同期呼び出しに変更することです。分離スレッドプールはリクエストが相互に影響を及ぼさないという問題を解決するだけで、同時実行性はまだ向上していません。非同期呼び出しに変更すると問題は完全に解決されますが、コーディングが複雑すぎます。
Go のコルーチンはこの問題を解決できます。Go のコルーチンは非常に軽量で、スケジューリング効率が高いため、単純なコードで非常に効率的なゲートウェイを作成できます。
たとえば、Nginx のパフォーマンスは誰にとっても明らかであると直感的に感じることができますが、Java を使用して実装する場合、Nginx のパフォーマンスを達成するために何台のマシンをスタックする必要があるかわかりません。ただし、Baidu はリバース プロキシの作成に Go を使用しており、Nginx の代わりに BFE を使用すると、そのパフォーマンスがいかに誇張されているかがわかります。
コルーチンの概要と原則については、私の記事「1 年間 Golang を書いて、プロセス、スレッド、コルーチンについて話しましょう」を参照してください。
Dubbo ゲートウェイでは、Dubbo-Go も新しいソリューションを提供します。Tuya Smart はオンラインで使用するための Dubbo-Go ゲートウェイをすでに備えており、Dubbo-go としてオープンソース化されています。貔貅。
ServiceMesh は徐々に次世代のマイクロサービス アーキテクチャになりつつあり、K8S、Docker、その他のクラウドネイティブ基盤であっても、Go は間違いなく Mesh 上で輝くスター言語ですこれらの機能はすべて Go で書かれており、Go の開発速度とコルーチンの高い同時実行機能により、Go は Mesh に推奨される言語となっています。
これに基づいて、Dubbo のメッシュ化と Dubbo-Go もその道を切り開きました。ただし、DubboMesh はまだ小規模な段階にあり、完全な実装ソリューションはオープンソースではありません。同社は DubboMesh の道を歩みたいと考えており、Dubbo-Go も考慮すべき点の 1 つである可能性があります。
ここまで述べたので、Dubbo を Go で書き直す必要がある理由に直接答える時が来ました。この質問に対する答えは依然として公式の文です: Java と Golang の間のギャップを埋める。 橋。なぜ「この橋を架ける」必要があるのかについては、下の図を参照してください。
以上がDubbo が Go で書き直されるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。