はじめに： クラウド上のIaaSとクラウド上のPaaSの違いは何ですか？クラウドネイティブテクノロジーを使用して配信速度を上げる方法は？クラウドネイティブ時代を背景に、研究開発の焦点はどのように変化するのでしょうか。アリババクラウドのシニアテクニカルエキスパートであるXuXiaobinは、この記事を使用して、IaaSからクラウド時代、PaaSへのアプリケーションアーキテクチャの進化の方向性、およびクラウドネイティブテクノロジーとアプリケーションアーキテクチャの進化の関係を共有しています。
クラウドネイティブは、PaaSクラウドベースの段階に入りました
アリババは、IaaSがクラウドに移行する段階を経て、PaaSがクラウドに移行する時代に入りました。昨年の「Double11」で、Alibabaはコアeコマースシステムの完全なクラウド移行を実現しました。ここでのクラウド移行は主にIaaSレイヤーで行われます。いわゆるIaaSは、主にコンピューティング、ネットワーク、およびストレージの仮想化を指します。この段階の後、AlibabaはクラウドへのPaaSの段階に入りました。PaaSがクラウドに移行する段階では、ミドルウェア、ストレージ、キャッシング、さらにはアプリケーションホスティングプラットフォームなど、より多くのクラウド製品を使用する必要があります。
実際、IaaSフェーズとPaaSフェーズには大きな違いがあります。IaaSの段階では、アプリケーションの研究開発の場合、懸念事項はインフラストラクチャとリソース、一般的に言えば、アプリケーションアーキテクチャへの侵入がほとんどない仮想マシンまたはコンテナです。ただし、PaaSクラウドフェーズでは、クラウドRedis、クラウドRDS、クラウドOSS、クラウドRabbitMQなどのクラウド製品を使用すると、アプリケーションアーキテクチャへの侵入が比較的強くなります。したがって、この侵入がアプリケーションアーキテクチャにどのような影響を与えるかは、すべてのR＆Dアーキテクトが考える必要のある問題です。
クラウドネイティブテクノロジー
クラウドネイティブテクノロジーを検索しようとすると、Google Cloudの定義、CNCFの定義、および他の多くのクラウドベンダーとオープンソースソフトウェアの定義が表示されますが、これらの定義の見方は異なります。簡単な要約は、次の図に示すように、次のカテゴリに分類できます。垂直方向の観点からは、アプリケーションアーキテクチャ、ライフサイクル管理、トラフィック管理、インフラストラクチャと依存関係の4つの次元に分類され、水平方向には、マイクロサービスと12の要素に分類されます。アプリ、コンテナ、BaaS、GitOps / IaC、およびサービスメッシュのディメンション。
今日、誰もがJushiアプリケーションアーキテクチャや単純なCSアーキテクチャではなく、マイクロサービスアーキテクチャに基づくクラウドネイティブについて話します。Quarkusは12Factor Appsを提案しました。つまり、今日Quarkusやその他のアプリケーションホスティングプラットフォームでアプリケーションを実行する場合、アプリケーションには特定の要件があります。もちろん、構成やコードの分離など、12の原則がフォローアップです。多くの拡張機能があります。これらの原則の多くの項目は、これらの原則を満たしている限り、アプリケーションホスティングプラットフォームが無料の操作やメンテナンスなど、より多くの機能を提供できることを意味します。コンテナの中核は、標準の対話方法を使用して、プラットフォームがリリース、拡張、自己修復などのアプリケーションのライフサイクルを管理できるようにすることです。
BaaS-サービスとしてのバックエンド。既存のサービスを可能な限り使用してアプリケーションを構築できます。サービスメッシュの本質はトラフィックを管理することです。今日のアプリケーションはトラフィックを受信しており、サービスを提供するときにトラフィックを送信する必要があります。このプロセスでは、サービス検出とトラフィックルーティングルールを管理する方法にサービスメッシュテクノロジが必要です。最後に強調する必要があるのは、GitOpsとIaC（Infrastructure as Code）です。これらのテクノロジーは、業界でますます注目を集めています。事実上の標準はありませんが、多くのクラウドコンピューティング企業は常に懸命に取り組んでいます。つまり、今日インフラストラクチャを使用する場合、コードを使用してこれらのインフラストラクチャのニーズを宣言できます。全体として、上記のコンテンツは、アプリケーションアーキテクチャ、ライフサイクル管理、トラフィック管理、インフラストラクチャと依存関係の4つの側面を中心に展開しています。
ビジネスは配達速度を気にします
ビジネスの場合、最も懸念されるのは多くの場合、配信速度です。ビジネスディレクターやCTOと話すと、彼らはあなたに尋ねます、ビジネスのためにこれほど多くのテクノロジーを持つことの利点は何ですか？コスト面でも管理面でもメリットがありますが、ほとんどの企業にとって最も重要なことは、研究開発の効率化です。したがって、クラウドネイティブテクノロジーがどのように高速配信を実現するのに役立つかを考える必要があります。
クラウドネイティブテクノロジーを使用してサービス提供の速度を向上させることは、大きく3つのステップに分けることができます。
標準化されたプラットフォーム/サービスおよびアプリケーションプロトコル
プラットフォーム/サービスとアプリケーション間の合意を標準化します。IaaSレイヤーがクラウドを使用する場合、プロトコルはマシン、つまり仮想マシン、コンテナーなどです。ビジネスアプリケーションの場合、表示されるのはオペレーティングシステムであるため、アプリケーションはオペレーティングシステム上のさまざまなリソースを使用できます。これの利点は、使用しないことです。物理的なマシンとマシンの障害に注意する必要があります。
プラットフォームへのビジネスに依存しない機能のさらなる分離
ビジネスアプリケーションの場合、表示されるのはオペレーティングシステムではありません。より高いレベルのプロトコルが提供されるため、プラットフォームは、アプリケーションが自動スケーリングや自己修復などを実現するのに役立ちます。また、基盤となるインフラストラクチャが発生したときに、アプリケーションが自動移動を実現するのにも役立ちます。障害が発生した場合、アプリケーションをあるマシンから別のマシンに移行できます。これがライフサイクル管理です。上記の合意に基づいて、プラットフォームの多くの機能を沈めることができます。たとえば、元々手動で管理する必要があるものは、コード宣言によってのみ適切に実装できます。これらの合意により、ビジネスアプリケーションは関連するライフサイクル管理を管理できます。プラットフォームを与える。
アプリケーションアーキテクチャのアップグレード
上記の2つのポイントに加えて、3番目のステップは、アプリケーションアーキテクチャをアップグレードを通じて適応させ、関連する機能をクラウドプラットフォームにシンクできるようにすることです。
クラウドフェーズからクラウドネイティブフェーズへのIaaSの移行
さらに改良を加えると、元のIaaSクラウドフェーズでは、ビジネスロジックに加えて、ビジネスアプリケーションのライフサイクル管理とトラフィック管理にも注意を払う必要があります。また、クラウド環境などでミドルウェアを自分で構築および構成する必要があります。 Redis、kafkaなどは途中で構築されているため、アプリケーションの依存関係の管理に多くの時間が費やされ、クラウドプラットフォームを管理できません。今日、PaaSまたはクラウドネイティブ移行の段階で、私がやりたいのは、クラウドプラットフォームが提供する機能を可能な限り使用し、ビジネス自体に重点を置き、クラウドにビジネスに関連しない一般的な技術機能を引き継ぐことです。管理する。
中心的な問題：
- ビジネスに依存しない機能をプラットフォームに切り離す方法は？
- プラットフォームとビジネス（アプリケーション）間の合意はどのように定義されていますか？
- アプリケーションアーキテクチャはどのように適応する必要がありますか？
以前は、IaaSクラウドフェーズでは、アプリケーションとオペレーティングシステム間の相互作用のための標準プロトコルがありましたが、現在、PaaSクラウドフェーズでは、そのような合意がどうあるべきかを再定義する必要があります。さらに、このようなプロトコルに基づいて容量のシンクを実現する方法は、Alibaba Cloudを含む多くのクラウドベンダーが行っていることです。たとえば、Alibaba CloudはRocketMQに基づいてRocketMQサービスを構築し、コンテナーに基づくいくつかのプロトコルに基づいてコンテナーサービスを提供しています。もちろん、今はほんの始まりに過ぎず、コンテンツのこの部分は、将来、より豊かでより完全なものになるでしょう。
例1：サービスメッシュは、サービスの検出とトラフィックをビジネスから分離します
同時に、アプリケーションアーキテクチャも適応する必要があります。例としてサービスメッシュを取り上げます。アプリケーション内のトラフィックはSDKの形式であったため、サービス検出とトラフィックをビジネスSDKから分離し、進化プロセス中にSidecarに配置してから、クラウドプラットフォームに渡して処理する方法を説明します。これは、アプリケーションアーキテクチャの進化の例です。
- サービスの登録と発見
- トラフィックルーティング
- トラフィックの再生
- 公開中のフロー制御
例2：軽量コンテナはビジネスからのログ収集を取り除きます
過去にログ収集を行っていた場合、各仮想マシンでログ収集プロセスを開始し、収集したログをログ収集プラットフォームに転送し、ビジュアルインターフェイスを介して分析する必要がありました。今日、クラウドネイティブの時代では、コンテナサービスにstdoutからログを取得させるか、構成を通じて特定のログディレクトリからログデータを取得することをお勧めします。ただし、エージェントのアップグレードを実現するには、収集物をSidecarに移動する必要があります。したがって、軽量コンテナによるビジネスからのログ収集の分離も、アーキテクチャの進化の例です。
- リソースの分離
- 独立したアップグレード
例3：ビジネスは、プラットフォームがライフサイクル管理を実現できるようにするためのプローブを提供します
アプリケーションアーキテクチャのライフサイクル管理の要件は、元のアプリケーションが開始後に正常であるか不正常であるかです。これは、アプリケーションの運用と保守、または研究開発の責任と懸念事項です。クラウドネイティブの時代では、このプロトコルを修正し、ビジネスを通じてプローブを提供して、アプリケーションが正常かどうかを判断することが望まれます。これには、HTTPプロトコルまたはシェルを介してアプリケーション内で正常性情報を提供する必要があります。アプリケーションのライフサイクル管理はプラットフォームに分類されます。
- 自動柔軟性
- 自動移動
- 自動再起動（自己修復）
契約（契約）= API +構成
全体として、プロトコルはAPI +構成です。APIの場合、キャッシングを使用する場合、基本的にオープンソースプロトコルをAPIとして扱います。このようなプロトコルは通常、クローズドソースプロトコルよりも使いやすいです。RPCプロトコルの場合、オープンソースのGRPCとDUBBOはプライベートHSFよりも優れています。さらに、TerraformやPulumiなど、実際にオープンソースの構成言語を定義しているインフラストラクチャのプロトコルがあります。これらの構成言語は、コンテナ、ディスク、ネットワーク、ストレージなどの必要なインフラストラクチャを宣言するのに役立ちますが、現在は構成言語には多くの種類がありますが、JavaのSDKと同様に、最終的に1つまたは2つの言語が形成されます。将来のクラウドリソースの使用は、必然的に一連のSDKを提示します。これは、一連の構成コーディング言語に基づいている必要があります。構築されました。さらに、GitOpsなどは、リリースプロセスとリリース戦略を一連の言語として定義しています。これは、将来、アプリケーションとクラウドの間の標準的な合意になります。
- Docker（＆OCI）は、標準のソフトウェア配信APIです。
- RPCプロトコルとして、オープンソースのGRPC / DUBBOはプライベートHSFよりも優れています。
- キャッシングプロトコルとして、オープンソースのRedisはプライベートTairよりも優れています。
- MicrosoftのDaprは、サイドカーアーキテクチャに基づいてAPIをHTTP / GRPCレイヤーに標準化して、SDKを削除し、複数の言語をサポートしようとしています。
- TerraformやPulumiなどのIaC製品は、構成言語を介してインフラストラクチャを宣言します。
- GitOpsはさらにコードを使用して、環境、リリースプロセス、およびリリース戦略のコンテンツを宣言します。
R＆Dフォーカスのシフト
元々、さまざまなSDKやさまざまな操作および保守イベントなど、アプリケーションが気にする必要のあるものが多すぎましたが、これらは実際にはモデルに抽象化され、新しい言語で定義できます。クラウド業界全体が気にかけていること。
新しい言語と新しいプロトコルが強調されている理由は、新しい言語またはプロトコルを定義した後、アプリケーションがこれらを気にする必要があるためです。開発者にとって最も懸念されるのはコードです。そのため、コードを使用して、インフラストラクチャ、運用と保守、およびホスティングに関するアプリケーションの要件を記述できる場合、アプリケーションにとって非常に使いやすいものになります。アプリケーションはこのプロトコルに接続できる必要があるだけで、独自のクラウド、パブリッククラウド、およびAlibabaCloudで同時に実行できます。
総括する
将来的には、クラウド上のリソースはますます豊富になります。インフラストラクチャに加えて、クラウドプラットフォームは、オペレーティングシステムがプロセスの機能を提供するのと同じように、より多くのPaaS機能を提供し、多くのSDKがあります。ただし、これらの機能は現在非常に非効率的で非標準的な使用であり、使用プロセスも面倒です。今日、私たちは同様のアセンブリ形式でクラウドを使用しており、クラウドネイティブは、アプリケーションとクラウドプラットフォーム間の契約を再定義し、この契約に基づいてより高度なプログラミング言語とツールを構築しています。これは、クラウドネイティブ時代のコンテキストにおけるアプリケーションアーキテクチャの進化にとって非常に重要な方向性です。
元のリンク：https ：//developer.aliyun.com/article/776095？
著作権に関する声明： この記事の内容は、Alibaba Cloudの実名登録ユーザーによって自発的に提供されています。著作権は元の作成者に帰属します。AlibabaCloud開発者コミュニティはその著作権を所有せず、対応する法的責任を負いません。特定の規則については、「Alibaba Cloud DeveloperCommunityユーザーサービス契約」および「AlibabaCloudDeveloperCommunity知的財産保護ガイドライン」を参照してください。このコミュニティに盗難の疑いがある場合は、侵害の申し立てフォームに記入して報告してください。確認が完了すると、コミュニティは侵害の疑いのあるコンテンツをすぐに削除します。