この記事は「MOOC」から初公開されました IT雑貨やプログラマーサークルのホットニュースをもっと知りたい方は「MOOC」に注目！
著者：Chen Yujiji | MOOC講師
近年のマイクロサービスの普及に伴い、日々の業務や技術交流の中で、どの企業も自社のプロジェクトをマイクロサービスでリファクタリングしているという声をよく耳にします.はい、マイクロサービスは確かに単一のシステムを解決することができます. . 企業がマイクロサービスを使用してアーキテクチャを再構築することを検討している場合、企業はマイクロサービスを実装するためのフレームワークを選択する必要があります。
マイクロサービス市場には 2 つの人気のあるフレームワークがあることは誰もが知っています。1 つは Ali の Dubbo で、もう 1 つは SpringCloud です。どちらが優れているかは常に頭の痛い問題でした。次に、マイクロサービスの技術を選択する方法について説明します。
1. 技術選択の考慮事項
実際には、Dubbo を使用するか SpringCloud を使用するかを検討することはできませんが、技術の選択自体に戻り、まず技術の選択に存在する可能性のある指標を見て、それらの指標に基づいてどのマイクロサービス フレームワークを選択するかを検討します。
| 考慮事項 | ジャッジ |
|---|---|
| バックグラウンド | 選抜技術の背景を探り、その源流を理解する |
| ビジネスニーズを満たしているかどうか | ビジネスのニーズを満たすことができるかどうか、過剰な参照を避けることを忘れないでください。テクノロジーはビジネスをサポートするものであり、ビジネスを先取りしすぎないようにしてください。 |
| 料金 | コストには、人件費、時間コスト、リソース ハードウェア コストが含まれます |
| オープンソースか | オープンソースの場合は、どの組織がオープンソースであるかを知り、コミュニティ版を慎重に使用する必要があります |
| コミュニティ活動 | コミュニティの活動は、ソフトウェアの品質をある程度決定します. 問題が発生したとき、アクティブなコミュニティは他の人がすでに遭遇しており、非常にうまく解決されている可能性があります. |
| 安全性 | フレームワークまたはコンポーネントが脆弱かどうかを知る |
| 会社の技術スタックと一致しているか | 品質とコストを確保するために、会社の技術スタックと一致する、または無関係な技術を検討するようにしてください |
| 慣れ親しんだ技術か | あまりにも多くの制御不能なリスクを回避し、安定性を確保するために、1 つの選択であまり多くの未知の新技術を使用しないでください。 |
| 安定 | システムがオープンソースで長期間稼働しているかどうか、テストに耐えているかどうか |
| スケーラビリティ | 他のプラットフォームに対応しているか、二次開発に使えるか |
| パフォーマンス効率 | スループット、応答時間などを考慮してください。 |
| 技術進歩のペース | 選択したテクノロジーのサイクルは、プロジェクトのライフ サイクルよりも大幅に長くする必要があります。これにより、テクノロジー自体が時間とともに厳密に反復されるようになります。 |
技術の選択にはまだまだ評価すべき指標が多く、経験が必要な判断でもあることがわかります。既存のビジネス状況に基づいて自分の状況に合った決定を下すには、多くの調査とインプットが必要です。
私たちが技術選択をするとき、最もタブーなことは、初めて詰め込み、インターネットでランダムにいくつかの比較記事を検索し、これらの断片的な情報を使用して決定を下すことです。私たちは、現在のビジネスの成長の判断に基づいて選択する必要があり、ビジネスの事実の背後にある仮定も理解する必要があります。
それでも最適なソリューションを選択することはできないかもしれませんが、この一連の評価基準により、現在のビジネスに合った技術スタックを選択することは絶対に可能です。
2.ダボまたはSprigCloud
2.1 ダボ
Alibaba によってオープンソース化された高性能で優れたサービス フレームワークである Dubbo は、現在、Dubbo によってサポートされている Ali 分散アプリケーションで数万のアプリケーションをサポートし、200,000 以上のサーバー インスタンスで実行され、毎日数兆レベルを呼び出します。アプリケーション クラスタ。現在、Dubbo は Ali からトップレベル プロジェクトとして Apache Foundation に寄付されています。
実際、Dubbo も浮き沈みの時期を経験しており、途中で大きなメンテナンスのない期間がありました。これは、Alibaba Cloud の充電プロジェクト HSF に取って代わられた可能性があります。ただし、apache トップレベル プロジェクトの下で維持されており、最新バージョンは 3.0 です。
2.2 スプリングクラウド
SpringCloud は Spring Source の製品です.Spring コミュニティの強力な支持は Java ビジネスの世界で比類のない組織と言えます.SpringBoot と SpringCloud はシームレスに接続されています.SpringCloud の開発の初期段階では,Netfix は強力なテクノロジを提供しました.出力、Netflix スイッチ スイートは基本的に、Spring Cloud の最初の心臓部です。ただし、Netflix の一部のコンポーネントは更新されていないため、SpringCloud はさまざまな面で代替またはさらに強力なソリューションを提供しています。
両者の背景だけを比較すると、前者は中国での影響力が大きく、後者は国内外の新興企業での影響力が大きい。ただし、Spring Source の強力な支援により、バックグラウンドでは、Spring Cloud の方がわずかに優れているはずです。ただし、選択フレームワークの主な基準として使用するべきではありません。
2.3 コミュニティ活動
Dubbo が Apache トップレベル プロジェクトに参加する前の 2017 年に、誰かが github で 2 つのフレームワークのアクティビティを比較したところ、SpringCloud は時間単位でアクティブであるのに対し、Dubbo は基本的に年単位でアクティブであることがわかります。
しかし、今日、Dubbo が apache トップレベル プロジェクトに参加した後、github で再比較したところ、差が縮まっていることがわかります。
もちろん、実際の活動を判断するのはそれほど単純ではありませんが、大雑把な観察では、コミュニティ、特に中国でのダボの活動が再開したという結論を導き出すことができます。公式のメンテナンスがない場合でも、Dubbo に基づいて Dangdang が開発した分散フレームワークである Dubbox など、Dubbo をさらに開発およびメンテナンスしている企業がまだいくつかあります。
2.4 両者の性能
Dubbo と SpringCloud は、実際にはソリューションのフレームワークにすぎません. 集中型パフォーマンスの違いは、主にサービス呼び出しと送信プロトコルに反映されています. Dubbo は、Dubbo のシリアル化を提供する RPC 通信プロトコルを使用します. Dubbo のデフォルトのプロトコルは、単一の long を使用しますlink および NIO 非同期通信 (接続維持、ローテーション トレーニング処理) は、カスタム メッセージを使用して、少量および大量の同時サービス呼び出しのシナリオに適しており、
SpringCloud はデフォルトで HTTP プロトコルの REST API を使用します。
インターネット上の誰かが、10 個の属性を含む Pojo オブジェクトを使用して 100,000 回要求し、異なる数のスレッドで Dubbo と SpringCloud を使用して、2 つのパフォーマンスをテストするために意図的にシミュレーション テストを行い、要求ごとに時間がかかりました (ミリ秒)
上記の写真とテスト結果はインターネットから取得したものです
当然のことながら、HTTP を使用する SpringCloud は、RPC を使用する Dubbo よりも劣っています。しかし、これは次のような結果になりました: パフォーマンスの観点から再利用が困難な Http + Json の Rest 通信は、実際には誤解です。
より高度なパフォーマンス評価は、Http プロトコルの通信がアプリケーションの負荷の実際のボトルネックになるかどうかを判断することです。
ほとんどの企業ネットワークでは、ネットワーク消費はそれほど問題ではありません。本当の問題がある場合、SpringCloud は Http + Json の強制バインドではなく、Thrift や Protobuf などの高性能 RPC を選択し、代わりにシリアル化を選択することもできます。
2.5 アーキテクチャの整合性
上記のポイントは、この選択の参照ポイントの 1 つにすぎません. 選択を実際に決定するのは、アーキテクチャの整合性であり、それが私たちのニーズを満たすかどうかを決定します.
実際には、SpringCloud と Dubbo をアーキテクチャの整合性の観点から比較するのは不公平です. Dubbo はサービス ガバナンスのみを実装していますが、SpringCloud はこれまでに github で 30 以上のプロジェクトを持ち、マイクロサービス アーキテクチャのすべての側面をカバーしています. Dubbo はある程度、SpringCloud のサブセットを指しますが、フレームワークの選択に関しては、まさにソリューションの完全性が最も重視する必要があることです。
上記の章で述べたように、マイクロサービスは、モジュールの明確な分割、独立した展開、および複数のスタイルのテクノロジの利点をもたらしますが、分散による多くの複雑さももたらします.これらの複雑さは、管理する必要があり、サポートに必要なコンポーネントが必要です. .
| ダボ | スプリングクラウド | |
|---|---|---|
| サービス レジストリ | 飼育係 | Netflix エウレカ / コンサルト / ナコス |
| サービスコールは常に | RPC | 残りの API |
| サービスゲートウェイ | なし | NetFlix Zuul / ゲートウェイ |
| ブレーカ | 不完全 | Netflix ハイストリックス |
| 分散構成 | なし | SpringCloud 構成 |
| リンク追跡 | なし | スプリングクラウド スルース |
| メッセージバス | なし | SpringCloud バス |
| バッチ タスク | なし | SpringCloud タスク |
いくつかの一般的に使用されるコア コンポーネントを上に示します. 表から, Dubbo が SpringCloud のサブセットにすぎない理由を見つけるのは難しくありません. ただし, 1 つのことを述べなければなりません. Dubbo の比較項目の「なし」は、それを意味するものではありません.実装することはできませんが、デフォルトの Dubbo フレームワーク自体は提供されておらず、市場には一致するオープン ソース コンポーネントが数多くあります。
例えば：
- サービス ゲートウェイ: Nginx + lua を基本ゲートウェイとして使用できます。これは、認証やルーティングなどの単純なゲートウェイのルールを実行できます。
- サーキット ブレーカー: Ali の Sentinel を使用できます。Sentinel は Hystrix よりも強力で、コンソールを備えています。
- 分散構成: Baidu の Disconf または Ctrip の Apollo を分散構成管理として使用できます. SpringCloud の Config と比較して, Config は git に保存および構成されます. デフォルトの構成を使用するのは直感的ではなく, Disconf と Apollo の両方が優れています. コンソールにはグレースケールの公開があります. 、および権限分離機能はより強力です。
- リンク追跡: SkyWalking を使用できます.SkyWalking は apache のトップ プロジェクトにも組み込まれています.この 2 年間で急速に発展しました.Zipkin と比較して,Cat は Zipkin よりも強力であり、Sleuth は言うまでもありません.
- メッセージ バス: RabbitMq を使用できます。また、AMQP プロトコルを使用する RabbitMq は、メッセージ エージェントを実装して、分散システム ノードを直列に接続し、ブロードキャスト状態に到達することもできます。
- バッチタスク: xxl-job を使用できます。
Dubbo は組み立てられたコンピューター、SpringCloud はブランド化されたコンピューターと考えることができます。以下は、組み立てのために選択されたほとんどのコンポーネントが国産である、組み立てられたダボとSpringCloudの比較です。
| Dubbo + オプション コンポーネント | スプリングクラウド | |
|---|---|---|
| サービス レジストリ | 飼育係 | Netflix エウレカ / コンサルト / ナコス |
| サービスコールは常に | RPC | 残りの API |
| サービスゲートウェイ | Nginx + セカンド | NetFlix Zuul / ゲートウェイ |
| ブレーカ | センチネル | Netflix ハイストリックス |
| 分散構成 | アポロ | SpringCloud 構成 |
| リンク追跡 | スカイウォーキング | スプリングクラウド スルース |
| メッセージバス | うさぎMq | SpringCloud バス |
| バッチ タスク | Xxlジョブ | SpringCloud タスク |
ダボはあらゆる面で選択の自由度が高く、外からしか選択できないとも言えます。しかし、結局のところ、それは外付けオプションであり、例えば、組み立てられたコンピューターにメモリまたはハードディスクを選択すると、問題が発生し、コンピューター全体がクラッシュします。あなたがDIYの達人であれば、これらは問題ではありませんが、あなたが初心者であるか、各コンポーネントにあまり慣れていない場合は、ブランドの機会があなたにより適しているかもしれません.
SpringCloud はブランド マシンのようなものです. Spring ソースの統合の下で, マシンの高い安定性を確保するために多くの互換性テストが行われています. ただし, SpringCloud のデフォルト コンポーネントには使いにくいコンポーネントもあります. .
上記で説明したコンポーネント間の違いに加えて、次のようないくつかの小さな詳細があります。
初期の頃、作者はDubboを使って暗黙のパラメータ受け渡しを実装し、Dubboのソースコードを変更しました（dubboは先にメンテナンスをやめたため、部分的な二次開発が行われました）。 RequestInterceptor を直接実装する.おそらく、SpingCloud はリリースが遅いため、いくつかの詳細でより思慮深く、Xiaobai の使用により適しています。
2.6 学習および採用コスト
SpringCloud の学習コストは Dubbo よりも低いと言っていいでしょう. さまざまなコンポーネントは基本的に箱から出してすぐに使えるものであり, SpringSource ツリーに依存しているため, 互換性と信頼性が保証されています. Java コードを書く人は誰もいないと思います.春に慣れていません。コーディングに関しては、SpringBoot に依存することで、さまざまなコンポーネント構成を使用できるため、学習とエントリのコストが大幅に削減されます。
3. まとめ
Dubbo と SpringCloud の関連する概念と比較は上記で明確に説明されていますが、Dubbo と SpringCloud のどちらを選択するかについては、お客様の状況とニーズによって異なり、ここで推奨される選択肢はありません。
著者は以前は常に Dubbo を使用していましたが、その後、新しい会社と新しいチームに行き、SpringCloud の ali バージョンを選択しました.検討の理由は、新しいチームはまだこの分野で関連する経験が不足しており、SpringCloud は完全なコンポーネントを提供するためです. 、SpringCloud は比較的安全な選択です。
新星として、SpringCloud はシンプルで使いやすく、SpringCloud は強力なコミュニティ サポートも提供しており、ドキュメントも非常に完成度が高く、新しいチームは散在するドキュメントを読んだり、さまざまなオープン ソースを調査したりするのに多くの時間を費やす必要はありません。コンポーネント. 時間はビジネスにあります.
さらに、同社には他の技術スタック チームもあり、インターフェイスの相互変調が必要です。Dubbo がデフォルトで使用する RPC はクロスランゲージをうまく実装できませんが、SpringCloud のデフォルトの Http REST 自体はクロスランゲージ実装をサポートしています。
「MOOC」アカウントへようこそ。IT サークルで高品質のコンテンツを提供し、乾いた知識を共有することを常に主張します。一緒に成長しましょう。
この記事はもともと Muke.com で公開されたものです。転載の際は出典を示してください。ご協力いただきありがとうございます