クラウドネイティブ時代にマイクロサービスはどのように進化するのでしょうか?

[[339605]]

クラウドネイティブ時代において、マイクロサービスとクラウドネイティブはどのような関係になるのでしょうか?クラウドネイティブ時代のマイクロサービスの特徴とは？現在最も活発なマイクロサービス プロジェクトは何ですか? Alibaba の上級技術専門家 Li Xiang 氏は、マイクロサービス ライフサイクル、トラフィック ガバナンス、プログラミング モデル、信頼できるセキュリティという 4 つの側面から、マイクロサービスとクラウド ネイティブの関係についての理解を共有しました。

1. マイクロサービスアーキテクチャとクラウドネイティブ

マイクロサービスは 2010 年頃に登場し始めました。当初は、従来の IT インフラストラクチャ、つまり従来の IDC または物理マシンにマイクロサービス アーキテクチャが適用されました。私たちはこれらの物理マシンを使用してマイクロサービス アーキテクチャにリソースを提供し、相互に連携して動作する分散システムを形成します。

当社はITインフラ全体の発展に伴い、徐々にクラウド時代へと突入しました。

クラウド時代における当社の最初のステップはクラウド ホスティングでした。これは、従来の IDC の物理マシンをクラウド上の仮想マシンと仮想エラスティック リソースに置き換えることを意味します。マイクロサービス アーキテクチャへの変更は、実際にはそれほど大きくありません。元々物理マシンに展開されていたアーキテクチャ モデルを、クラウドでホストされている仮想マシンに簡単に転送できます。これはリフト アンド シフト方式とも呼ばれます。同時に、クラウド ホスティングの時代において、クラウド上の仮想マシンの弾力性をさらに活用して、マイクロサービスの自動水平スケーリングを実行しようとしています。

テクノロジーがさらに発展する中で、クラウドネイティブ時代では何が違うのでしょうか?クラウド ネイティブは、マイクロサービスや DevOps などのアーキテクチャと概念を、クラウドによって提供されるサービス、機能、プラットフォームとより適切に統合、調整、連携することを目的としています。クラウドは、ストレージ、コンピューティング、ネットワーク リソースなどの弾力性のある物理リソースを提供するだけでなく、マイクロサービスにとってより優れた運用環境とプラットフォームも提供できると期待しています。これには次の 2 つのことを行う必要があります。

リソースレベルでの共同最適化とリソースの有効活用。

クラウドサービスとプラットフォームを最大限に活用し、研究開発と運用保守の効率を大幅に向上します。

実際、クラウド ネイティブが実現したいのは、マイクロサービス アーキテクチャとシステムがクラウドおよびクラウド上のサービスやプラットフォームと連携して、コストを削減し、効率を向上する最善の方法を実現できるようにすることです。

2. マイクロサービスとクラウドネイティブ

マイクロサービスとクラウドネイティブをマイクロサービス中心の視点で見ると、それらの関係とクラウドネイティブ時代のマイクロサービスの進化について4つの点から語ることができます。

ライフサイクル管理。

交通管理。

プログラミングモデル。

信頼性が高く、安全です。

ライフサイクル

本質的に、マイクロサービスとは、巨大なアプリケーションであるモノリシック アプリケーションを、複数の小さなサービスに分割し、それらのサービスが連携して、元のモノリシック アプリケーションによって提供される同等のビジネス サービスを完成させることです。したがって、サービス間には依存関係があり、サービスは 1 つ以上のリソースにデプロイされる必要もあります。

上図に示すように、元の単一アプリケーションとリソースの関係は実際には 1 対 1 の関係であり、単一アプリケーションの連携も何らかの内部連携であり、外部の動的依存関係がないことがわかります。マイクロサービスに切り替えると、この図はネットワークになり、より複雑になることがわかります。

そのため、内部的な理由により、50% を超える企業がマイクロサービス アーキテクチャを採用している、またはマイクロサービス アーキテクチャを採用していると考えている場合、最大の課題は、より複雑な運用と保守、つまりより複雑なライフサイクル管理にあります。

今日は、クラウド ネイティブの基礎であるコンテナとコンテナ サービスについてお話します。これは、マイクロサービスがライフサイクル管理と運用保守管理の問題を解決するのに役立ちます。それらはどのように解決されるのでしょうか?

それは2つの部分に分けられると思います:

まず、異なるマイクロサービス間には、多少の異質性が存在する可能性があります。マイクロサービス システムの下で各チームの効率を最大化できるようにするために、異なるチームが異なるプログラミング言語、さらには異なるオペレーティング環境を使用してこれらのマイクロサービスを実行できるようにしています。そのため、マイクロサービスを運用および管理する際には、当初は異機種環境を処理するための統一された一連の標準がありませんでした。これが、クラウドネイティブ技術であるコンテナが普及した理由です。その重要な機能の 1 つは、標準カプセル化レイヤーと標準ランタイムを通じてマイクロサービスの展開を標準化することです。このように、ライフサイクル管理の観点から見ると、各マイクロサービス間の違いは少なくなり、共通点が多くなります。

このテクノロジーをベースに、Kubernetes など、現在でも非常に人気のあるコンテナ プラットフォームという別のレイヤーを開発しました。その役割は、基盤となるリソース上で標準化されたマイクロサービスを最も便利に実行できるようにすることです。これまで説明したストレージ、コンピューティング、ネットワークはすべて、Kubernetes レイヤーを通じて統一された方法で抽象化およびカプセル化されており、コンテナーによって統合されたマイクロサービスを Kubernetes プラットフォーム上で直接実行できます。したがって、運用および保守担当者は、マイクロサービスを特定のリソースまたはコンピューティング ユニットに割り当てる方法について心配する必要がなくなります。コンテナとコンテナ プラットフォームは、マイクロサービス自体のライフサイクル管理を大幅に簡素化し、マイクロサービス自体の運用および保守管理を簡素化し、より多くの企業によるマイクロサービスの採用を促進します。

よりミクロな視点から見ると、コンテナとコンテナ プラットフォームはマイクロサービスのライフサイクルに具体的にどのような支援を提供するのでしょうか?

たとえば、Kubernetes ではポッドと呼ばれる非常に興味深い概念が導入されています。ポッドは実際にはコンテナの集合です。ポッド内で 1 つ以上のコンテナを実行できます。一般的に、マイクロサービス アーキテクチャを採用する場合、マイクロサービスの本体はメイン コンテナ内で実行され、メイン コンテナのライフサイクルはポッド自体のライフサイクルと連動します。

さらに、ログ収集、ネットワーク プロキシ、ID 認証など、メイン コンテナの補助機能を提供するために、サイドカー コンテナもいくつか実行します。これをサイドカー コンテナに配置することで、マイクロサービスにスーパー パワーを与えることができます。提供されるコアビジネスサービスに加えて、さらに強化することもできます。つまり、追加の補助機能を動的に追加して、マイクロサービス管理をより強力にすることができます。

一方、ポッド モデルには、次のような非常に便利な機能もいくつかあります。

ステータス情報。 Pod は実行ステータスを表示するための標準インターフェースを提供します。たとえば、トラフィックを受信する準備ができていますか?そうであれば、イングレスからのトラフィックがマイクロサービスに到達する可能性があります。実行状態が悪い場合は、コンテナの修復、再起動、削除を試みたり、別のコンピューティング ユニットに切り替えて実行したりすることで、マイクロサービスの全体的な安定性を確保できます。

住所サービス。各ポッドには標準化された DNS アドレス サービスがあり、均一にアドレス指定できます。これは、均一に公開する必要がある API のログ記録、監視、およびトレース機能に非常に役立ちます。ポッドによって公開される可観測性情報は DNS アドレスに基づいてアクセスできるため、実行時の問題を迅速かつ簡単に発見できます。

したがって、コンテナ プラットフォームとコンテナは、実際にマイクロサービスの機能強化、堅牢性の強化、マイクロレベルでの監視性の向上に役立つことがわかります。

上の図に示すように、マイクロサービス ランタイムの観点から見ると、コンテナ プラットフォームは、Day 2 のマイクロサービス更新、リリース、および容量拡張操作を実行するのに役立つ非常に効果的な機能も提供します。たとえば、Kubernetes は、ローリング デプロイメント、ブルーグリーン リリースなど、いくつかの一般的なアップグレードまたは拡張戦略を提供します。これにより、運用と保守の作業が効果的に簡素化され、運用と保守自体の確実性と自動化の効率が向上しました。

まとめると、ライフサイクルの観点から見ると、コンテナとコンテナ プラットフォーム テクノロジの使用により、コンテナ ライフサイクル管理の標準化と自動化が大幅に改善され、人件費が節約され、効率が向上し、より多くの企業がマイクロサービス テクノロジを使用するようになりました。

交通管理

一方、マイクロサービスは、アーキテクチャの分割を通じて、静的コンパイル時に元々生成された機能と動的ランタイム間の関係を推測します。したがって、実行時には、特定のビジネス機能を完了するために、サービスが相互に通信し、連携する必要があります。人々がコミュニケーションやコラボレーションを行う場合、コミュニケーション プロセスを管理したり、トラフィック管理を実行したりする必要があります。たとえば、あるマイクロサービスから別のマイクロサービスを見つける方法や、マイクロサービスが通信するのに最適なマイクロサービス インスタンスを確実に見つけられるようにする方法を知る必要があります。これは、RPC 機能、サービス登録および検出機能、動的構成管理機能、サービス低下機能などを含む比較的複雑なプロセスです。

ビジネス開発者の負担を軽減し、マイクロサービスごとにマイクロサービス トラフィック管理の一般的な機能を繰り返し記述する必要を回避するために、多くのフレームワークが開発されてきました。たとえば、Java システムでは、有名な Spring Cloud が分散型マイクロサービス管理フレームワークを提供します。 Go 言語のオープンソース エコシステムには、Go Mirco のようなシステムもあります。 Alibaba には、HSF などのシステムから開発されたマイクロサービス ガバナンス フレームワークもあります。

したがって、抽象的なレベルでは、サービスは次の 2 つのレベルで構成されていることがわかります。

1 つのレベルはビジネス ロジックそのものであり、これはマイクロサービス ビジネス開発者によって記述され、機能の実装とビジネスの実装に関連するコードです。

もう 1 つのレベルは、マイクロサービス間の通信、トラフィック、およびサービス ガバナンスのコードを実装することです。これを、下の図でマークされている Spring Cloud などのフレームワークに抽象化します。このような抽象化によって、すべての共通機能がこの特定のフレームワークに依存するという問題が発生します。

Spring Cloud に加えて、Alibaba HSF などの他のサービス フレームワークを社内に導入するとします。 Spring Cloud フレームワークで記述されたマイクロサービスと通信したい場合はどのように操作すればよいでしょうか?これには、HSF と Spring Cloud 間の相互接続とプロトコルの相互理解が必要です。しかし実際には、これらのフレームワークにはこの機能が備わっていないことがよくあります。さらに大きな問題は、クラウドネイティブ時代において、これらのマイクロサービスの開発を異なる開発言語やモデルを使用してプログラムできるようになることかもしれません。したがって、フレームワークのシステム間の関係は 1 対 2 の関係ではなく、Spring Cloud と HSF の関係だけではありません。 Java システムと、JavaScript、Python、Go システムなどのマイクロサービス フレームワークを接続する必要がある場合があります。多言語および複雑な環境におけるマイクロサービスのガバナンスと管理の問題を解決することは、N から M の問題になります。

コンテナ、コンテナ プラットフォーム、Pod などの抽象化があり、ビジネスにおいてコードやフレームワークに全面的に依存せずにプラットフォームを提供できるようになった現在、上記の問題を解決するより良い方法はあるのでしょうか?

現在、「サービス メッシュ」と呼ばれる人気の概念があります。その本質は、多言語および多環境のシナリオにおけるトラフィック管理の問題をより適切に解決することです。その主な考え方は次のとおりです。

1 つ目は、トラフィック管理のこれらのフレームワーク機能を、ビジネスと結びついたバイナリから抽象化して分離し、トラフィック管理用の別のプロセスを形成し、それをサイドカー モードで Pod に展開することです。オペレーティング システム レベルでの透過的なトラフィック ハイジャックにより、マイクロサービス間のすべてのトラフィックがサイドカーにハイジャックされ、その後、サイドカー間の通信を通じてトラフィックが転送および管理されます。これにより、問題ははるかに簡単になります。トラフィック管理サイドカーが相互に通信し、相互接続できるようにするだけで済みます。現在よく知られ、人気のあるオープンソースのトラフィックハイジャックおよび管理サイドカー実装は、Envoy と呼ばれています。

もちろん、このトラフィック ハイジャックと管理のレイヤーだけでは不十分であり、コントロール プレーンからのサポートも必要です。たとえば、元のマイクロサービス システムによって実行されるサービス登録、サービス検出、トラフィック監視は引き続き必要であり、これらのポリシーとルールはトラフィック管理のために Sidecar エージェントに送信する必要があります。そのため、メッシュとクラスターを形成できるように、Pod に展開されたトラフィック管理用のデータ プレーンの単一ポイントを管理するコントロール プレーンも構築する必要があります。したがって、いくつかのコントロール プレーン機能が必要になります。オープンソースで人気のあるコントロール プレーンの実装は Istio と呼ばれます。主に、トラフィック構成、トラフィック セキュリティ、トラフィック監視の 3 つの機能を実装します。

クラウド ネイティブのプラットフォーム指向がますます強まる時代において、ほとんどの新しいアプリケーションとシナリオは、マイクロサービス トラフィック管理にサービス メッシュ ベースのテクノロジーを使用するようになると考えています。

プログラミングモデル

ドライバーをリクエスト

リクエスト駆動型、つまり、リクエストに基づいて動的な弾性スケーリングをサポートし、リクエスト処理ロジックを簡素化します。学生の中にはこのモデルをイベント駆動型と呼ぶ人もいるかもしれませんが、リクエスト駆動型は実際にはイベント駆動型の一種です。

リクエスト駆動型とは何ですか?従来のマイクロサービス アーキテクチャの観点から見ると、外部システムからのリクエストが届くと、通常は L4/L7 負荷分散を経て、さまざまなマイクロサービス インスタンスに渡されます。同じマイクロサービス インスタンスのプロセスには、通常 2 つのロジックが存在します。最初のロジックはリクエスト管理です。これは、キュー管理、リクエスト分散、その他の機能を備えた HTTP サーバーといくつかのハンドラーで構成される場合があります。これらのリクエストは最終的に、実際のリクエスト ビジネス処理ロジックである 2 番目の論理部分であるプロセッサに送信され、実際にこれらのリクエストを処理して応答します。

このアーキテクチャには 2 つの問題があります。

リクエスト管理ロジックは、さまざまなマイクロサービス フレームワーク実装で記述する必要があります。たとえば、Java、Go、Python には独自のリクエスト管理ロジックが必要です。

リクエスト管理とリクエスト処理は結合関係を形成します。したがって、このアーキテクチャには、要求を認識してトラフィック管理を実行できるグローバルで独立した制御層が存在しません。リクエストは、マイクロサービス インスタンス自体の処理層に到達した場合にのみ解析できます。このとき、マイクロサービス インスタンスが過負荷になったとしても、負荷分散のために他のマイクロサービス インスタンスにリクエストを転送することは困難です。

リクエスト駆動型システムは、これら 2 つの問題を解決しようとします。私たちはマイクロサービスでリクエスト駆動型の分離操作を実行しようとしています。

まず、外部システムから送信されるすべてのリクエストを標準化します。アダプターはあります。標準化後、リクエスト ロード バランサーに配置します。このロード バランサは、リクエスト自体のセマンティクスを理解し、リクエスト処理ロジックを駆動してリクエストを処理できます。要求処理ユニットが足りない場合は、要求処理マネージャーを通じて拡張できます。リクエスト処理用の論理ユニットが多数ある場合、それらのサイズを縮小してコストを節約できます。さらに、開発者はリクエスト管理ロジックを実装する必要がなくなり、開発コストが削減されます。

先ほど述べたリクエスト駆動型モデルは、次の 3 つの部分に分けられます。

リクエストの標準化

リクエストルーティング

リクエスト処理

実際、外部システムからのリクエストを標準化し、業務コードを含めずにリクエストのルーティングや処理管理を追加すれば、よく話題になるサーバーレスの概念が形成されます。これは、マイクロサービス システムとプラットフォーム ベースのサーバーレス システムを統合するプロセスです。

サーバーレス プラットフォームには Alibaba Cloud FaaSS と SAE、AWS には Lambda、Google は CloudRun、Azure には Functions などがあります。リクエストの標準化など、Serverless プラットフォームを独自に構築したい場合は、Cloud Events などのオープンソースのリクエスト標準や、リクエスト処理用の Knative などの処理ルーティングと水平スケーラビリティコンポーネントもあり、Kafka や RocketMQ を使用してリクエスト自体を永続化したり、リクエスト自体を転送したりすることもできます。

分散ランタイム

プログラミング モデルの分散ランタイムでは、マイクロサービスがより優れた多言語環境サポート、環境の移植性、および非常に高速な起動を実現できることを期待しています。

多言語サポート、環境の移植性、非常に高速な起動

モノリシック アプリケーションの時代では、ビジネス コードはミドルウェア コードと結合され、デプロイされたインスタンスでした。マイクロサービスの時代では、サービス メッシュによるトラフィック管理の後、ビジネス コードとトラフィック管理コードは実際には分離可能であり、一部のミドルウェア コードのみが依然として一部のビジネス コードと結合されてバイナリを形成していることがわかります。

多言語機能と環境の移植性を完全にサポートするために、残りのミドルウェア コードをビジネスから切り離したいと考えています。この技術はランタイム分離と呼ばれます。その基本的な概念は、ビジネス コードに標準的で拡張可能な API を提供することであり、多言語対応の軽量 API です。ミドルウェアの機能は、API を呼び出すことによって実装されます。私たちは、ミドルウェアの機能をトラフィック管理のようなサイドカーに組み込み、それを統一された言語で実装し、誰もがより多くのミドルウェア機能をプラグインできるようにプラグイン可能なモードを設計します。

ダプル

このテクノロジーの代表的な実践例の 1 つが、Microsoft が昨年リリースした Dapr と呼ばれる分散ランタイムです。

Dapr はビジネス コードに 2 つの API を公開します。1 つは HTTP API で、もう 1 つは grpc API です。どちらの API も非常に軽量で、複数の言語で動作します。分散ランタイムである Dapr 自体は、複数のミドルウェア システムに接続し、標準 API を通じて異なるシステム間の違いを隠し、ある程度のプログラミング インターフェイスの統一を提供できます。コード実装の観点では、ミドルウェア コードはアプリケーション レベルからサイドカーに抽出されます。上図に示すように、ビジネスレベルではビジネスコードのみを記述すればよく、その他のコードはほぼすべて Dapr ベースのプラットフォームが引き継ぎます。

Dapr 自体は 2 つの部分に分かれています。最初の部分は Dapr がアプリケーションに公開する API であり、もう 1 つの部分は Dapr のフレームワーク レイヤーです。

Dapr フレームワーク レイヤーを通じて、さまざまな Dapr 関連の実装にアクセスできます。Kafka/SQS などのリソース バンドリング、Redis/cassandra などのデータ管理、RabbitMQ などのパブリッシュ アンド サブスクライブ、さらには Prometheus/Open tracing などの分散トレースなど、これらはすべて Dapr フレームワークに接続でき、統合された標準 HTTP および gRPC API を通じてビジネス コードとアプリケーション コードに提供できます。このようにして、ビジネス コードはミドルウェアおよびトラフィック管理機能からより徹底的に分離され、アプリケーション開発者はビジネス コードの研究開発にさらに自由に集中できるようになります。

信頼できるセキュリティ

マイクロサービス間でネットワーク通信が必要なため、安全で信頼性の高い認証が必要です。従来のアプローチでは、ネットワーク環境で通信および実行されるすべてのアプリケーションまたはマイクロサービスが信頼されていると想定して、マイクロサービスを信頼できるネットワーク環境に配置します。自由に通信または交換することができ、特定のセキュリティ保護対策を実行するための軽量の認証と承認が存在する場合があります。

しかし、このモデルにはリスクが伴います。マイクロサービスがこの信頼できるネットワークに侵入すると、信頼できるネットワーク内の内部防御がある程度比較的欠けているため、マイクロサービス システム全体に大きなセキュリティ リスクが発生します。

さらに、信頼できるネットワーク内のマイクロサービス間の相互呼び出しや認証に問題が発生することもよくあります。一般的な解決策は、VPC ピアリングまたはゲートウェイ ネットワークのゲートウェイを介してそれらを開くことです。信頼できるチャネルは、マイクロサービス間の信頼性の高いネットワーク レベルの呼び出しを確保するために使用されます。しかし、それは問題も引き起こします。たとえば、別の信頼できるネットワークが侵入された場合、接続されている他の信頼できるネットワークも攻撃される可能性があり、攻撃を受ける可能性も高まります。

マイクロサービスの時代において、ネットワークが完全に信頼できる環境であると想定しない、より優れたソリューションがあるのではないかと考えています。そこで、マイクロサービスやアプリケーション トラステッド セキュリティと呼ばれる概念が提案されています。つまり、マイクロサービスまたは機密ファイル間のすべての通信は、ID システムに基づいています。マイクロサービスは、通信および連携するターゲット オブジェクトに ID 認証を提供します。ブラウザを通じて HTTPs ウェブサイトにアクセスする場合と同様に、これらのウェブサイトは証明書を提供する必要があり、マイクロサービスも独自の ID 認証を提供して、受信者がプラットフォームを通じて認証および承認を確認できるようにする必要があります。これらの認証に合格した場合にのみ、マイクロサービスとの通信が開始されます。

実際、プラットフォームの特性を生かし、ネットワーク層内でアプリケーションを中心に据えることで、統一されたアイデンティティ認証と認可に基づくシステムが構築されています。

しかし、このシステムを構築するのは依然として比較的困難です。これは、不完全な信頼ネットワークで信頼できるプラットフォーム層または中間層を要求することと同等であり、PKI の CA メカニズムに似ています。たとえば、HTTPS では、CA を信頼する場合、事前にオペレーティング システムに証明書を事前設定しておく必要がある場合があります。より安全なエンドツーエンドの信頼を提供するには、インストール時に事前に設定する必要があります。そうしないと、信頼チェーンを構築できません。同様に、このメカニズムはクラウド環境でも必要です。クラウド自体は制御可能なプラットフォームです。クラウドの最も基本的なハードウェア メカニズムからクラウド上で実行される OS、そして最終的にマイクロサービスが上方に展開されるプラットフォーム レイヤーに至るまで、検証可能な信頼チェーンを確立する必要があります。最終的には、各マイクロサービスに独自の ID ID と検証可能な承認情報が提供され、マイクロサービスは統一された検証可能で証明可能な ID を提供できるようになります。つまり、クラウドネイティブ時代においては、プラットフォーム思考がマイクロサービスセキュリティに大きな価値をもたらすことができるのです。

さらに、プラットフォーム間またはネットワーク間では、プラットフォームレベルの信頼できるクレジットを通じて関連付け関係を確立できるため、異なるプラットフォーム間のマイクロサービスでも信頼関係を確立できます。異なるプラットフォームを接続するために、統一された標準の ID ID と、統一された標準で認証情報を検証および認証する方法を提供する、spiffe と呼ばれるオープンソース プロジェクトがあります。

3EDAS

実際、ここまでお話ししてきたように、マイクロサービスのトラフィック管理、マイクロサービスのライフサイクル、マイクロサービスの信頼できるセキュリティとプログラミング モデルなど、オープン ソースの分野では新しいテクノロジーが絶えず登場していることがわかります。この機能やプラットフォームを自分で構築しようとすると、通常、多大な時間と労力がかかります。

そのため、Alibaba Cloud は最近、クラウド サービス EDAS をアップグレードし、EDAS を従来のマイクロサービス指向の管理システムから、クラウド ネイティブ インフラストラクチャに基づくクラウド ネイティブ アプリケーション PaaS へと変革しました。コンテナライフサイクル管理、マイクロサービスガバナンス、可観測性、安全なトラフィックガバナンスなどの機能を提供し、Alibaba Cloud ユーザーは、このようなプラットフォームの構築に時間を費やすことなく、クラウドネイティブ時代のマイクロサービスのメリットを最大限に活用できます。

したがって、クラウドネイティブマイクロサービスに興味のある学生は、EDAS を試してみることをお勧めします。

4つのクラウドネイティブマイクロサービス

クラウドネイティブ時代において、マイクロサービスには次のような特徴があります。

プラットフォーム化、マイクロサービス アーキテクチャなどのクラウドをプラットフォームとして使用して、より多くの機能を提供します。

標準化: マイクロサービス自体の展開と運用、およびマイクロサービスと他のサービス間の通信が標準化され、サービス間の相互接続が容易になることを期待しています。サービスはさまざまなプラットフォームに分散できるため、一度記述して一度定義すれば、複数の場所で実行できます。

マイクロサービスは軽量であるため、R&D 担当者はマイクロサービス ガバナンスに関連する複雑なロジック開発ではなく、コア ビジネス コードとビジネス ロジックの開発に集中できます。

マイクロサービスの製品化。私たちは、マイクロサービス アーキテクチャを製品化された方法で使用し、より使いやすく、より優れたものにするために、マイクロサービス関連の製品を構築したいと考えています。

5つのグローバルオープンソースマイクロサービスフレームワークの活動に関するレポート

私たちは最近、クラウドネイティブ時代に比較的活発に活動しているマイクロサービス プロジェクトを収集することに多大な労力を費やし、いくつかの特徴を発見しました。

クォーカスプロジェクトは非常に活発です。これにより、Java または Java エコシステムを可能な限り軽量化し、クラウドネイティブ時代の弾力性と効率的な起動速度の要件に適応できるようになります。

Spring Cloud の上昇傾向は依然として非常に良好です。 Java の非常に典型的なマイクロサービス フレームワークとして、Alibaba も Spring Cloud エコシステムに深く関わっています。現在最も人気のある Spring Cloud クラウド サービス プロバイダーは Spring Cloud Alibaba です。

最後に、アリババが構築に多くの人的資源を投入しているDubboやDaprなどのプロジェクトは、実際にかなり活発に行われています。