Alibaba Cloud NativeにおけるDaprの実践

サービスメッシュとは何ですか?

2010年以降、SOAアーキテクチャは中規模および大規模インターネット企業の間で人気を博し、アリババも2012年にDubboをオープンソース化しました。その後、マイクロサービスアーキテクチャが普及し、多くのインターネット企業と従来型企業がマイクロサービスの構築に専念しました。国内には、Dubbo と Spring Cloud という 2 つの主要なマイクロサービス キャンプが徐々に形成されてきました。 2016年、マイクロサービス分野では、コンテナやKubernetesとの互換性を高めた、より最先端のマイクロサービスソリューションが開発され始めました。このテクノロジーはサービスメッシュと呼ばれます。現在、サービス メッシュの概念は広く普及しており、多くの企業が現場でサービス メッシュを実装しています。

サービスメッシュの定義

サービス メッシュは、サービス間の通信に重点を置いたインフラストラクチャ レイヤーです。現在のクラウドネイティブ アプリケーションのサービス トポロジは非常に複雑です。サービス メッシュは、この複雑なトポロジで信頼性の高いリクエスト送信を実現できます。サービス メッシュはサイドカー モードで実行されます。独立したサービス メッシュ プロセスがアプリケーションの隣で実行されます。サービス メッシュは、リモート サービスとの通信を担当します。軍用三輪バイクはサービスメッシュと非常によく似ています。軍用三輪バイクでは、1人の兵士が運転を担当し、もう1人の兵士が射撃を担当します。

サービスメッシュで解決できる問題点

従来のマイクロサービス アーキテクチャのほとんどは、RPC 通信フレームワークに基づいており、RPC SDK でサービス登録/検出、サービス ルーティング、負荷分散、フルリンク トラッキングなどの機能を提供します。アプリケーション ビジネス ロジックと RPC SDK は同じプロセスにあります。このアプローチは、従来のマイクロサービス アーキテクチャに多くの課題をもたらします。ミドルウェア機能関連のコードがビジネス コードに侵入し、結合が非常に高くなります。 RPC SDK のアップグレード コストは非常に高く、SDK バージョンの大きな差別化につながります。同時に、このアプローチでは、アプリケーション開発者に対して比較的高い要求が課せられ、広範なサービス ガバナンス、運用および保守機能、ミドルウェアの背景知識が必要になります。ミドルウェアを使用するための敷居は比較的高いです。

一部の RPC 機能をサービス メッシュにシンクすることで、関心の分離と責任の明確な境界を実現できます。コンテナと Kubernetes テクノロジーの発展により、サービス メッシュはクラウド ネイティブ インフラストラクチャになりました。

Istio の紹介

サービス メッシュの分野では、Istio が間違いなく王者です。 Istio はコントロール プレーンとデータ プレーンで構成されています。 ServiceMesh では、さまざまなサービスが Proxy Sidecar を介して通信します。 Istio のコア機能はトラフィック管理であり、これはデータ プレーンとコントロール プレーン間の調整を通じて実現されます。 Istio は、Google、IBM、Lyft によって開始されました。これは、CNCF エコシステムのサービス メッシュ分野における最も純粋な血統であり、サービス メッシュの事実上の標準になることが期待されています。

Istio のデータ プレーンはデフォルトで Envoy を使用します。これは、コミュニティのデフォルトかつ最高のデータ プレーンです。 Istio データ プレーンとコントロール プレーン間の相互作用プロトコルは xDS です。

サービスメッシュの概要

最後に、Service Mesh についてまとめます。

Service Mesh は、サービス間の通信のためのインフラストラクチャを提供するという位置づけで、コミュニティでは主に RPC と http をサポートしています。

Sidecar モードでデプロイされ、Kubernetes および仮想マシンへのデプロイをサポートします。

Service Mesh は転送に独自のプロトコルを使用するため、ネットワーク プロキシとも呼ばれます。このアプローチにより、アプリケーションへの侵入ゼロを実現できます。

Daprとは何ですか?

サービスメッシュの課題

ユーザーがクラウド上に展開する業務形態としては、主に共通アプリケーション型と FaaS 型が挙げられます。 Faas シナリオでは、ユーザーをより惹きつけるのはコストと研究開発の効率です。コストは主にオンデマンドの割り当てと極めて高い弾力性と効率性によって実現されます。アプリケーション開発者は、FaaS を使用して多言語プログラミング環境を提供し、起動時間、リリース時間、開発効率などの研究開発効率を向上したいと考えています。

サービス メッシュの実装は本質的には独自のプロトコル転送であり、アプリケーションへの侵入がゼロになるという利点をもたらします。ただし、元のプロトコルの転送にもいくつかの問題が生じます。アプリケーション側のミドルウェア SDK にもシリアル化やエンコード、デコードを実装する必要があるため、多言語実装には一定のコストがかかります。オープンソース テクノロジーの継続的な開発に伴い、使用されるテクノロジーも常に進化しています。 Spring Cloud から Dubbo に移行する場合、アプリケーション開発者が依存する SDK を切り替えるか、Service Mesh を使用してこの効果を実現する場合は、Service Mesh でプロトコル変換を実行する必要があり、コストがかかります。

サービス メッシュはサービス間の通信に重点を置いており、他の形式のメッシュに対するサポートはほとんど提供していません。たとえば、Envoy は RPC 分野での成功を除けば、Redis、メッセージング、その他の分野での試みは実を結んでいません。 Ant の Mosn は、RPC とメッセージの統合をサポートしています。全体的なマルチメッシュ形式に対する需要は存在しますが、各メッシュ製品は独立して開発されており、抽象化と標準が欠けています。多数のフォームを持つ Mesh は同じプロセスを共有していますか?プロセスを共有する場合、ポートも共有しますか?多くの疑問が未だに解決されていない。コントロール サーフェスに関しては、機能的な観点から見ると、その大部分はトラフィックを中心に展開されます。 xDS プロトコルの内容を読んだ後、その中心はサービス検出とルーティングを中心に展開されていることがわかりました。他の種類の分散機能は、基本的にサービス メッシュのコントロール プレーンには関係ありません。これらの分散機能をサポートするために xDS などのさまざまなプロトコルを抽象化することなどありません。

コストや研究開発の効率などの理由から、FaaS が選択される顧客が増えています。 FaaS では、多言語とプログラミング API の使いやすさに対する要求が高まっているため、Service Mesh では、これら 2 つの分野で顧客にさらなる価値をもたらすことができません。

分散アプリケーションの要件

Bilgin Ibryam 氏は、Kubernetes Patterns の著者であり、RedHat の主任ミドルウェア アーキテクトであり、Apache コミュニティで非常に活発に活動しています。彼は、分散の現在の困難さと問題の一部を抽象化し、分散アプリケーションの要件をライフサイクル、ネットワーク、状態、バインディングの 4 つの主要なカテゴリに分類した記事を発表しました。各タイプには、ポイントツーポイント、pub/sub、キャッシュ、その他の従来のミドルウェア機能などのサブ機能がいくつかあります。アプリケーションには分散機能に対する要件が非常に多く、サービス メッシュでは明らかにアプリケーションの現在のニーズを満たすことができません。 Biligin Ibryam 氏は、サービス メッシュのジレンマを解決するために、記事の中で Multiple Runtime の概念も提案しました。

多重ランタイム概念の導出

従来のミドルウェア モデルでは、アプリケーションと分散機能は SDK を使用して 1 つのプロセスに統合されます。さまざまなインフラストラクチャが下位に移動されるにつれて、さまざまな分散機能がアプリケーションから外部のアプリケーションに移動されます。たとえば、K8s はライフサイクル関連の要件を担当し、Istio、Knative などは一部の分散機能を担当します。これらすべての機能が独立したランタイムに移行されると、運用と保守の観点とリソースの観点からこの状況は受け入れられなくなります。したがって、現時点ではいくつかのランタイムを統合することが間違いなく必要であり、最も理想的な方法はそれらを 1 つに統合することです。このアプローチは、中国語でメカを意味する「Mecha」として定義されています。日本のアニメの主人公がメカに変身するのと同じように、メカの各コンポーネントは分散機能のようなもので、メカ内の人物はメインアプリケーション（Micrologic Runtime とも呼ばれます）に相当します。これら 2 つのランタイムは 1 対 1 のサイドカー モードにすることができ、従来のアプリケーションに非常に適しています。または、エッジ シナリオやネットワーク管理モードに適した多対 1 ノード モードです。

したがって、さまざまな分散機能を統合するという Mecha Runtime の目標自体は大きな問題ではありませんが、それをどのように統合するかが問題となります。メカの要件は何ですか?

Mecha のコンポーネント機能は抽象的であり、あらゆるオープンソース製品を迅速に拡張および統合できます。
Mecha には一定の構成可能性が必要であり、yaml/json を通じて構成およびアクティブ化できます。これらのファイル形式が主流のクラウドネイティブ アプローチと一致するのが最適です。
Mecha は標準 API を提供しており、メインアプリケーション間のインタラクティブなネットワーク通信は、元のプロトコルを転送するのではなく、この API に基づいて完了します。これにより、コンポーネントの拡張と SDK のメンテナンスが非常に便利になります。
分散機能のライフサイクルでは、一部の機能を K8s などの基盤となるインフラストラクチャに引き渡すことができます。もちろん、複雑なシナリオでは、K8s、APP、Mecha Runtime を一緒に完了する必要がある場合もあります。
理想的な状況はランタイムが 1 つだけであるのに、なぜ複数ランタイムと呼ばれるのでしょうか?アプリケーション自体は実際にはランタイムであり、さらに Mecha ランタイムも含まれているため、少なくとも 2 つのランタイムが存在します。

Dapr の紹介

マルチランタイムに関するこれまでの紹介は比較的抽象的です。 Dapr から Multiple Runtime を再理解することができます。 Dapr はマルチランタイムの優れた実践者であるため、サイドカー モードまたはノード モードのいずれかで Dapr をアプリケーションと共存させる必要があります。 Dapr という言葉は実際には造語ではありません。これは、Distributed Application Runtime の頭文字で構成されています。 Dapr のアイコンは帽子のように見えますが、これは実際にはウェイターの帽子であり、アプリケーションに優れたサービスを提供することを意味します。

Dapr は Microsoft によってオープンソース化されており、Alibaba も協力に深く関わっています。現在の Dapr はバージョン 1.1 がリリースされており、生産能力に近づいています。

Dapr は Multiple のベストプラクティスであるため、Dapr の動作メカニズムも Multiple Runtime の概念に基づいて構築されています。 Dapr は分散機能を抽象化し、Http と gRPC に基づいて構築された一連の分散機能 API を定義します。この抽象化と機能は、Dapr では Building Block と呼ばれます。 Dapr の分散機能を拡張するために、オープンソース製品や商用製品などのさまざまな種類の製品をサポートするために、Dapr にはコンポーネントと呼ばれる内部 SPI 拡張メカニズムがあります。 Dapr を使用すると、アプリケーション開発者は特定の実装にあまり注意を払うことなく、さまざまな分散機能 API に対してプログラミングするだけで済みます。 Dapr では、Yaml ファイルに従って対応するコンポーネントを自由にアクティブ化できます。

Daprの機能

アプリケーション開発者は、さまざまな多言語 Dapr SDK を使用して、さまざまな分散機能に直接アクセスできます。もちろん、開発者は HTTP と gRPC に基づいて呼び出しを完了することもできます。 Dapr は、独自のコンピュータ環境、任意の Kubernetes 環境、エッジ コンピューティング シナリオ、Alibaba Cloud、AWS、GCP などのクラウド ベンダーなど、ほとんどの環境で実行できます。

Dapr コミュニティには 70 を超えるコンポーネント実装が統合されており、アプリケーション開発者はそれらをすばやく選択して使用できます。同様の機能を持つコンポーネントの置き換えは Dapr を通じて実行でき、アプリケーション側ではそれを意識する必要がありません。

Dapr コアモジュール

Dapr 製品モジュールの観点から分析して、なぜ Dapr が Multitiple Runtime に適した方法なのかを見てみましょう。

コンポーネント メカニズムにより、迅速な拡張が可能になります。現在、コミュニティにはオープンソース製品だけでなくクラウド上の商用製品も含め、70 を超えるコンポーネント実装があります。

Building Block が表す分散機能は現時点では 7 のみをサポートしており、将来的にはさらに多くの分散機能が必要になります。 BuildingBlock は、オープンで非常に人気のある 2 つのプロトコルである HTTP と gRPC をサポートするようになりました。 Dapr の Building Block のどのコンポーネントがアクティブ化されるかは、YAML ファイルによって異なります。 Dapr は HTTP と gRPC を使用して機能を公開するため、アプリケーション側で複数の言語の標準 API プログラミング インターフェースをサポートしやすくなります。

Dapr Core: コンポーネントとビルディングブロック

Dapr コンポーネントは、Dapr プラグイン拡張のコアであり、Dapr の SPI です。現在サポートされているコンポーネントには、バインディング、Pub/Sub、ミドルウェア、ServiceDiscovery、シークレット ストア、状態が含まれます。拡張ポイントには、バインディング、pub/sub、状態などの機能的なものもあれば、ミドルウェアなどの水平的なものもあります。 Redis 用の Dapr 統合を実装する場合、Dapr の状態コンポーネントを実装するだけで済みます。 Dapr ビルディング ブロックは、gRPC および HTTP メソッドをサポートする Dapr によって提供される機能です。現在サポートされている機能には、サービス呼び出し、状態、Pub/Sub などがあります。

ビルディング ブロックは 1 つ以上のコンポーネントで構成されます。バインディング ビルディング ブロックには、バインディングとミドルウェアの 2 つのコンポーネントが含まれています。

Dapr の全体的なアーキテクチャ

Dapr にも、Istio と同様に、データ プレーンとコントロール プレーンがあります。コントロール サーフェスには、Actor Placement、Sidecar Injector、Sentry、OPerator が含まれます。 Actor Placement は主に Actor にサービスを提供し、Sentry はセキュリティと証明書関連の作業を行い、Sidecar Injector は主に Dapr Sidecar の挿入を担当します。 Dapr でのコンポーネントのアクティブ化は、YAML ファイルを通じて行われます。 YAML ファイルは 2 つの方法で指定できます。1 つはランタイム パラメータをローカルで指定する方法、もう 1 つはコントロール プレーン Operator を通じて完了する方法です。コンポーネントアクティベーションファイルは K8s CRD 形式で保存され、Dapr Sidecar に送信されます。コントロール プレーンの 2 つのコア コンポーネントは、実行に K8s に依存しています。現在の Dapr ダッシュボード機能はまだ非常に弱く、短期的には強化できません。さまざまなコンポーネントを統合した後も、各コンポーネントの操作とメンテナンスは元のコンソールで完了する必要があります。 Dapr コントロール プレーンは、特定のコンポーネント実装の運用と保守には関与しません。

Dapr の標準的な実行形式は、アプリケーションと同じ Pod 内ですが、2 つのコンテナー内にあります。 Dapr の残りの部分については、すでに十分に紹介されているので、ここでは紹介しません。

Dapr マイクロソフト着陸シーン

Daprは約2年間開発されてきました。 Microsoft 内ではどのように実装されていますか?

Dapr の github には、ワークフローと Azure Functions Dapr 拡張機能の 2 つのプロジェクトがあります。 Azure Logic App は、Microsoft が提供するクラウドベースの自動ワークフロー プラットフォームです。また、Workflows は Azure Logic App と Dapr を統合します。 Azure Logic App にはいくつかの重要な概念があり、トリガーとコネクタは Dapr に非常によく適合します。トリガーは Dapr の入力バインディングを使用して完了できます。 Dapr の入力バインディングの多数のコンポーネントを利用することで、トラフィックの入口の種類を拡張できます。コネクタと Dapr の出力バインディングまたはサービス呼び出し機能は非常に互換性があり、外部リソースに迅速にアクセスできます。 Azure Functions Dapr 拡張機能は、Azure Function 拡張機能に基づく Dapr サポートであり、Azure Function で Dapr のさまざまなビルディング ブロックの機能をすばやく使用できると同時に、関数開発者に複数の言語での比較的シンプルで一貫性のあるプログラミング エクスペリエンスを提供します。

Azure API Management サービスの観点は、上記の 2 つの実装シナリオと一致しません。これは、アプリケーションが Dapr Sidecar を介してアクセスされ、アプリケーションによって提供されるサービスが Dapr を介して公開されるという前提に基づいています。現時点では、非 K8s アプリケーションまたはクラスター間アプリケーションが現在のクラスターのサービスにアクセスする場合は、ゲートウェイが必要です。このゲートウェイは、Dapr の機能を直接公開し、ゲートウェイにいくつかのセキュリティと権限の制御を追加できます。現在、サービス呼び出し、pub/sub、リソース バインディングの 3 つのビルディング ブロックがサポートされています。

Daprの概要

Dapr が提供する機能指向の API により、開発者は複数の言語をサポートする一貫したプログラミング エクスペリエンスを実現できます。同時に、これらの API の SDK は比較的軽量です。これらの機能は、FaaS シナリオに非常に適しています。 Dapr 統合エコシステムが継続的に改善されるにつれて、開発者の能力重視のプログラミングの利点はさらに拡大します。 Dapr を使用すると、開発者がコードを調整する必要なく、Dapr コンポーネントの実装をより簡単に置き換えることができます。もちろん、元のコンポーネントと新しいコンポーネントの実装には、同じタイプの分散機能が備わっている必要があります。

サービスメッシュとの違い:

提供される機能: サービス メッシュはサービス呼び出しに重点を置いています。 Dapr は、さまざまな分散プリミティブをカバーする、より広範囲の分散機能を提供します。

動作原理: サービス メッシュは、侵入ゼロを実現するために独自のプロトコル転送を使用します。 Dapr は、多言語 SDK + 標準 API + さまざまな分散機能を使用します。

ドメイン指向: サービス メッシュは、従来のマイクロサービスの非侵入的なアップグレード サポートに非常に適しています。 Dapr は、アプリケーション指向の開発者にとってより使いやすいプログラミング エクスペリエンスを提供します。

アリババのDaprへの探査

アリババのダプルにおける発展の道

2019 年 10 月、Microsoft は Dapr をオープンソース化し、バージョン 0.1.0 をリリースしました。当時、アリババとマイクロソフトはすでにOAMで協力を開始しており、Daprプロジェクトについて知っていたため、評価を始めました。 2020年の初め、アリババとマイクロソフトはアリババでDaprに関するオフラインコミュニケーションを行い、マイクロソフトのDaprに対する見解、投資、その後の開発計画について知りました。この時点で、アリババはすでにDaprプロジェクトに大きな価値があると判断している。 Daprの作業が開始されたのは2020年半ばになってからだった。 10 月までに、Dapr は関数コンピューティング シナリオで一部の関数をオンラインでグレースケール化し始めました。本日現在、関数コンピューティングに関連するすべての Dapr 関数のグレースケールが基本的に完成しており、公開テストが開始されています。 2021年2月にようやくバージョン1.0がリリースされました。

Alibaba Cloud Function ComputeがDaprを統合

極めて高い弾力性などの運用と保守の利点に加えて、機能コンピューティングとミドルオフィス アプリケーションの違いは、機能コンピューティングでは開発者に優れた R&D エクスペリエンスを提供し、全体的な R&D 効率を向上させることに重点を置いていることです。 Dapr が関数コンピューティングにもたらす価値は、開発者が特定の製品に集中することなく、複数の言語で統合された機能指向のプログラミング インターフェイスを提供することです。たとえば、Alibaba Cloud 上の OSS サービスを Java で使用したい場合は、Maven 依存関係を導入し、いくつかの OSS コードを記述する必要があります。 Dapr では、Dapr SDK の Binding メソッドを呼び出すだけでこれを実行できます。プログラミングを容易にしながら、実行可能パッケージ全体に追加の依存パッケージを導入する必要がなく、制御可能です。

Function Compute の英語名は Function Compute で、略称は FC です。 FC アーキテクチャには多くのシステムが含まれており、開発者に関連するものとしては主に Function Compute Gateway と関数が実行される環境が含まれます。 FC ゲートウェイは主にトラフィックの受信を担当します。また、受け入れるトラフィックの量と現在の CPU およびメモリの使用量に基づいて、現在の関数インスタンスをスケールアップまたはスケールダウンします。関数コンピューティング ランタイム環境は Pod にデプロイされ、関数インスタンスはメイン コンテナーに、dapr はサイドカー コンテナーにデプロイされます。外部トラフィックが機能コンピューティング サービスにアクセスすると、トラフィックはまずゲートウェイに送られます。ゲートウェイは、アクセスされたコンテンツに基づいて、現在のサービスを提供する関数インスタンスにトラフィックを転送します。リクエストを受信した後、関数インスタンスが外部リソースにアクセスする必要がある場合は、Dapr の多言語 SDK を介して呼び出しを開始できます。このとき、SDK は Dapr インスタンスへの gRPC 要求を開始し、Dapr インスタンスは要求の種類と本文に基づいて対応する機能とコンポーネントの実装を選択し、外部リソースへの呼び出しを開始します。

Function Compute の英語名は Function Compute で、略称は FC です。 FC アーキテクチャには多くのシステムが含まれており、開発者に関連するものとしては主に Function Compute Gateway と関数が実行される環境が含まれます。 FC ゲートウェイは主にトラフィックの受信を担当します。また、受け入れるトラフィックの量と現在の CPU およびメモリの使用量に基づいて、現在の関数インスタンスをスケールアップまたはスケールダウンします。関数コンピューティング ランタイム環境は Pod にデプロイされ、関数インスタンスはメイン コンテナーに、dapr はサイドカー コンテナーにデプロイされます。外部トラフィックが機能コンピューティング サービスにアクセスすると、トラフィックはまずゲートウェイに送られます。ゲートウェイは、アクセスされたコンテンツに基づいて、現在のサービスを提供する関数インスタンスにトラフィックを転送します。リクエストを受信した後、関数インスタンスが外部リソースにアクセスする必要がある場合は、Dapr の多言語 SDK を介して呼び出しを開始できます。このとき、SDK は Dapr インスタンスへの gRPC 要求を開始し、Dapr インスタンスは要求の種類と本文に基づいて対応する機能とコンポーネントの実装を選択し、外部リソースへの呼び出しを開始します。

サービス メッシュのシナリオでは、メッシュはサイドカーの形で存在し、アプリケーションと同じポッドの 2 つのコンテナーにデプロイされるため、サービス メッシュのニーズを十分に満たすことができます。ただし、関数コンピューティングのシナリオでは、Dapr を独立したコンテナーとして実行するとリソースが消費されすぎるため、リソースの費用と第 2 レベルの弾力性を節約するために、複数の関数インスタンスが 1 つの Pod にデプロイされます。したがって、関数コンピューティングのシナリオでは、関数インスタンスと Dapr プロセスを同じコンテナーにデプロイする必要がありますが、2 つのプロセスとして存在する必要があります。

関数コンピューティング シナリオでは、現在の関数のインスタンスの最小数を示す予約インスタンスの数を設定できます。予約済みインスタンスがあるが、これらのインスタンスに長時間トラフィックアクセスがなく、一時停止/休止状態にする必要がある場合、この方法は AWS の方法と一致します。関数が休止状態になるには、インスタンス内のプロセスまたはスレッドの実行を停止する必要があります。 Dapr ライフ サイクルのスケジュールをサポートするために、関数ランタイムに拡張構造が追加されます。関数インスタンスが休止状態に入ると、拡張機能は Dapr に休止状態に入るように通知します。関数インスタンスが実行を再開すると、拡張機能は Dapr に以前の実行状態を再開するように通知します。 Dapr 内のコンポーネント実装では、このタイプのライフサイクル管理をサポートする必要があります。 Dubbo を例にとると、Dubbo の登録センター nacos は、通信を維持するために定期的に Nacos サーバーにハートビートを送信する必要があります。同時に、Dapr によって統合された Dubbo コンシューマーも Dubbo プロバイダーにハートビートを送信する必要があります。過渡状態に入るときは、ハートビートを終了する必要があります。操作を再開する場合は、全体の動作状態を復元する必要があります。

上で述べた関数コンピューティングと Dapr の組み合わせのポイントはすべて送信トラフィックに基づいていますが、では受信トラフィックについてはどうでしょうか?メッセージ トラフィックは、ゲートウェイを経由せずに Dapr に直接流れ込むことができますか?これを実現するには、Dapr Sidecar がパフォーマンス データをタイムリーに Gateway に報告し、Gateway がリソースの弾力性を実現できるようにする必要があります。

クラウド上のSaaSサービス

Alibaba が社内でより多くの SaaS ビジネスを育成するにつれて、SaaS ビジネスからの外部サービスに対する需要は非常に強くなります。しかし、SaaS ビジネスではマルチクラウド展開の需要が強く、顧客は SaaS ビジネスが Alibaba Cloud パブリック クラウドまたは Huawei プライベート クラウド上に展開されることを期待しています。さらに、顧客は、基盤となるテクノロジーがオープンソースまたは標準的なクラウドベンダーの商用製品であることを期待しています。

Alibaba のクラウド上の SaaS ビジネスを例に挙げてみましょう。左側がアリババのオリジナルシステム、右側が変換されたシステムです。変革の目標は、依存している Alibaba システムをオープンソース ソフトウェアに切り替えることです。 Ali RPC は Dubbo に切り替えられ、Alibaba の内部キャッシュ、メッセージ、構成はそれぞれ Redis、RocketMq、Nacos に切り替えられます。 Dapr は最も低コストのスイッチングを実現できると期待されています。

このミッションを達成するために Dapr を使用したいので、最も単純かつ最も厳しい方法は、アプリケーションを Dapr の SDK に依存させることです。ただし、この変換のコストが高すぎるため、元の API を変更せずに、基盤となる実装を Dapr SDK に適合させます。この方法では、アプリケーションは元の API を直接使用して Dapr にアクセスでき、対応する依存 JAR パッケージ バージョンをアップグレードするだけで済みます。変換後も、開発者は元の SDK 用にプログラミングを行いますが、基礎となるレイヤーは Dapr の機能指向プログラミングに置き換えられているため、移行プロセス中、アプリケーションはクラウド環境や異なるテクノロジごとに異なるブランチを維持する必要なく、一連のコードを使用できます。グループ内で Dapr Sidecar を使用する場合、rpc.yaml、cache.yaml、msg.yaml、config.yaml を使用してコンポーネント実装がアクティブ化されます。パブリック クラウドでは、dubbo.yaml、redis.yaml、rocketmq.yaml、nacos.yaml ファイルを使用して、Alibaba Cloud 環境に適したコンポーネント実装をアクティブ化します。異なる YAML ファイルを通じて異なるコンポーネントをアクティブ化することでコンポーネント実装を保護するこの方法は、SaaS ビジネスのマルチクラウド展開に大きな利便性をもたらしました。

DingTalk は Dapr の重要なパートナーおよびプロモーターであり、クラウド ネイティブ チームと協力して DingTalk への Dapr の実装を推進しています。一部のミドルウェア機能を Dapr Sidecar にシンクすることで、同様の機能の基盤となるミドルウェア実装が保護されます。しかし、DingTalk には依然として独自のビジネス上の問題点が残っています。 DingTalk の一般的なビジネス コンポーネントはビジネスに強く依存しており、特定のビジネスに合わせてカスタマイズする必要があります。これも再利用性の低下につながります。そのため、DingTalk はいくつかのビジネス コンポーネント機能を Dapr に組み込むことを望んでいます。これにより、さまざまなビジネスで同じプログラミング エクスペリエンスを実現でき、コンポーネントのメンテナーはコンポーネントの実装のみを保守すれば済みます。

Dapr 展望

インフラの沈下がソフトウェア開発のトレンドに

ソフトウェア アーキテクチャ開発の歴史は興味深いものです。アリババのシステムアーキテクチャの進化の歴史を振り返ることは、中国、さらには世界のソフトウェアアーキテクチャの発展の歴史を理解するのに役立ちます。 Taobao が最初に設立されたとき、それはモノリシックなアプリケーションでした。事業が拡大するにつれて、システムはまずスケールアップ方式でハードウェアをアップグレードしました。しかし、このアプローチではさまざまな問題が発生することがすぐに判明したため、2008 年にマイクロサービス ソリューションが導入されました。 SOA ソリューションは分散されており、安定性と可観測性を確保するには、回路ブレーカー、分離、フルリンク監視などの高可用性ソリューションを導入する必要があります。次の問題は、コンピュータ ルームと IDC レベルでビジネスに対して 99.99% を超える可用性の SLA をどのように達成するかということでした。この時、同じ市内に2つのコンピュータ室を設置したり、異なる場所でマルチアクティブにするなどのソリューションが登場しました。クラウド技術の継続的な発展に伴い、アリババはクラウドネイティブ技術の発展を受け入れ、その発展を導き、積極的にクラウドネイティブ技術を受け入れ、K8sに基づくクラウドネイティブ技術のアップグレードを積極的に実行しています。

この歴史から、ソフトウェア アーキテクチャに対する新たな要求がますます増えていることがわかります。元の基盤インフラストラクチャではそれらを完了することができなかったため、完了するにはアプリケーション側の SDK に引き渡す必要がありました。 K8s とコンテナが徐々に標準になった後、マイクロサービスと一部の分散機能がインフラストラクチャに戻ってきました。今後のトレンドとしては、Service Mesh や Dapr に代表される分散機能を取り込み、クラウドやクラウド ネイティブ技術の発展による利益を最大化していくことが挙げられます。

クラウドネイティブシナリオにおけるアプリケーション開発者の要求

将来のアプリケーション開発者は、特定のクラウド ベンダーやテクノロジに縛られない、機能指向で非依存の開発エクスペリエンスを期待すると同時に、クラウド テクノロジの究極の柔軟性を通じてコスト上の利点も実現できる必要があります。この理想はいつか実現すると信じています。現在の観点から、この目標をどのように達成できるでしょうか?

マルチランタイムのコンセプトは実際に実装でき、開発を継続できます。
Dapr を例にとると、Dapr の分散機能 API を業界標準に推進したいと考えていますが、この標準は継続的に開発される必要があります。
K8s とサーバーレス テクノロジーの継続的な開発により、将来的には究極の弾力性が実現されます。