クラウド サービス OpenAPI の 7 つの主要な課題: アーキテクトはどのように対処すべきでしょうか?

[[279233]]

API は、モジュールまたはサブシステム間の相互作用のためのインターフェース定義です。優れたシステム アーキテクチャは優れた API 設計と切り離せないものであり、不完全な設計の API はその後のシステムの開発と保守を非常に困難にすることになります。より優れた API 設計テンプレートとしては、典型的な RESTful インターフェースである github や k8s を参照できます。クラウド サービスを外部に公開するための窓口が OpenAPI です。本日議論するトピックは、「クラウド サービス シナリオにおける OpenAPI 設計の課題」です。

API 仕様が必要な理由は何ですか?

「クラウドサービス」が強調される理由は、小規模な独立型APIの設計は、大規模な量産型APIが直面する問題とは異なる問題に直面するからです。同様に、自社製品 API の可用性のみに着目する場合と、クラウド サービス API システム全体の堅牢性をより高いレベルで考える場合とでは、構築するシステムが異なります。

例えば、WEB ページが利用する API を作る場合、ページと API が統合されており、一緒にリリースやロールバックができるため、パフォーマンス、安定性、認証のみ考慮すれば済みます。機能が正常であれば、API 設計に欠陥があってもユーザーはそれを受け入れることができます。クラウド サービス用の API を公開する際には、考慮すべき問題が多数あります。

• まず、クラウド サービスは、一般的にシステム レベルの接続であるインフラストラクチャとサービス インターフェイスを開きます。 API が一度オープンになると、それを変更するのは非常に困難です。
• 第二に、クラウド サービスは独立して動作しません。実際のシナリオでは、さまざまな製品が組み合わされるため、製品間の一貫性と相互運用性を考慮する必要があります。
• クラウドサービスAPIは多数存在します。より便利にご利用いただけるよう、API 検索、オーケストレーション、SDK の自動生成のサポートに対する要望が、通常のサービス以上に強くなっています。
• クラウドサービスの安定性は非常に重要です。コア製品の安定性は顧客の生命線であり、要求は非常に高いです。

したがって、製品ラインの数が多いため、クラウド サービスでは、クラウド製品間で一貫した API エクスペリエンスを確保するための統一された API 仕様と、上位レベルのアプリケーション プラットフォーム化を容易にするための基盤となるプラットフォーム レベルでの相互互換性が必要です。同時に、パブリッククラウドサービスを取り巻くサードパーティのエコシステム、オープンソースのエコシステム、エンタープライズのエコシステムも考慮する必要があります。

具体的な仕様のレベルでも、業界では絶えず実験が行われており、よく知られているものとしては OpenAPI 仕様と Google API 設計ガイドがあります。前者は、RESTful API 設計に関する非常に具体的な規制を詳細レベルで提供しており、RESTful API 設計の分野における事実上の標準となっています。一方、後者は、主にクラウドベンダーの観点から、多くのベストプラクティス仕様や提案を提案しています。これらの原則は、RESTful API だけでなく、他の種類の API 設計にも適用できます。 API 設計に興味のある開発者は、この資料を詳しく学習できます。

[[279234]]

2018年にOpenAPI仕様バージョン3.0がリリースされました。

画像ソース: https://swagger.io/

したがって、クラウド サービス プロバイダーにとって、主要なリンクで明確な API 仕様を策定することは、内部的にはクラウド サービス間の相互運用性の効率を向上させ、外部的には一貫したユーザー エクスペリエンスを提供し、クラウド サービスの統合を向上させるのに役立ちます。では、クラウド サービスの水平標準化を実施する際には、どのような困難に直面するのでしょうか?この記事では、実践から得た 7 つの主要な課題をまとめます。

課題 1: API 設計パターンの選択

単一製品の API 表現を検討する場合、まず特定の API スタイルを選択します。最も一般的なものは、RPC (リモート プロシージャ コール) と ROA (REST 指向アーキテクチャ) です。次に、複雑なデータ構造の場合、どのようなシリアル化プロトコルを使用するかを検討します。一般的なものには、データをカプセル化して送信するために使用される Json/Xml/WSDL/Hessian などがあります。ただし、製品が異なれば、具体的な選択の際に考慮すべき事項も異なる場合があります。

gRPC 図

画像ソース: https://www.grpc.io/docs/guides/

RESTful 設計スタイルの露出率は高いものの、すべてのクラウド サービス プロバイダーが RESTful に完全に従うことを選択しているわけではありません。たとえば、AWS と Alibaba Cloud では主に RPC スタイルが使用されていますが、Google と Azure では主に RESTful が使用されています。

Restful API の利点は、HTTP が使いやすく、異機種システムの統合が容易になり、開発と実行の効率が比較的高く、リソース要件も比較的高いことです。 RPC API は、より広範囲のフレームワークとソリューションを使用でき、技術レベルではより低レベルで柔軟性があり、設計が比較的単純で、習得するには一定のハードルがあり、アーキテクチャがより複雑です。

RESTful モデルと RPC モデルの比較

実際の状況やビジネス モデルに基づいて、チームごとに異なるソリューションが選択される場合があります。クラウド サービス全体を強制的に統合する必要があるのか​​、それとも任意に選択できるのか?統一されたスタイルが強制されると、RESTful スタイルに適した一部のサービスで RPC を使用する必要があり、見た目が悪くなります。単なる手続き型サービス呼び出しであれば、RESTful リソース設計の方向に移行するのは困難です。ただし、統一されたスタイルが強制されない場合、API の体系的なサポートはより複雑になります。たとえば、2 つのスタイルの SDK の自動化をサポートするには、2 セットのコードが必要になります。

一般的に、RESTful スタイルでは、API 設計者に比較的高い要求が課せられます。主な難しさは、リソース指向の設計では、開発者が事前に計画を立て、バックエンド データ モデルを API サービス モデルと一致させる必要があることです。したがって、RESTful API の開発者は、システムの全体的なエンティティ リレーションシップ モデルに精通している必要があります。バックエンドのビジネスを理解していない初心者が合理的な API を設計できるとは考えにくいです。つまり、RPC スタイルの API にはリソース指向の設計は必要ないということですか?実際にはそうではありません。 RPC スタイルの API をサポートするにはリソース モデルも必要です。これについては次のセクションで詳しく分析します。

したがって、クラウド サービス プロバイダーにとって、API スタイルを選択する際に考慮すべき問題がいくつかあります。

• どのスタイルをサポートするかを選択すると、ビジネス特性をより適切に反映し、顧客にとってより便利な操作が可能になります。
• API 設計がリソース指向であるかどうか、および対応するエンジニアリング担当者がそのような設計を行う能力を持っているかどうか。
• このスタイルのツール チェーンに対するサポートは十分ですか?入出力比率とは何ですか?
• 業界での一般的なトレンドは何ですか、他のシステムとの相互運用性を考慮する必要があるかどうか。

特定の設計モデルを選択した後は、複数のモデルが混在することによる管理コストの増加を避けるために、統一性を実現するよう努める必要があります。本当に両方の方法をサポートする必要がある場合（たとえば、Alibaba Cloud は RPC と ROA の両方をサポートしています）、技術的に十分な準備が必要です。

課題2: リソース用のAPIの設計

ユーザーが API を使用してクラウド サービスにアクセスする場合、基本的には、特定のクラウド リソースに対して特定の操作を実行してビジネス アクションを完了したいと考えています。 Restful API はリソース指向である必要があることはよく知られています。では、クラウド サービス シナリオでは、なぜ RPC インターフェイスにもリソース モデルが必要になるのでしょうか?

RPC API の構成形式は、ドメインと動作 (オブジェクトとメソッド) です。時間が経つにつれて、API の数が増え、最終的には巨大なコレクションが形成されます。 Alibaba Cloud を例にとると、外部に公開されている OpenAPI の数は 10,000 を超え、約 200 種類の製品をカバーしています。開発者は各 API を個別に学習する必要があるため、時間がかかり、エラーが発生しやすく、コンテキストなしでは理解するのが困難です。標準リソース モデルのセットがあれば、リソース モデルのディメンションに従って API を分類および整理することができ、ユーザーは API を使用する際の明確なパスを把握できるため、より優れたエクスペリエンスを実現できます。そうでなければ、非常に多くの API を少しずつ学習するのは間違いなく苦痛なプロセスになります。

また、クラウドサービスは、個々のサービスを単純​​に並べたものではなく、複数のシステムを水平統合したもので、全体として外部と有機的につながっているように見えます。クラウド コンピューティングの発展に伴い、企業顧客のクラウド サービスに対する要件は増加し続けています。最も典型的な例は、企業顧客が大規模にクラウドに移行し始めると、認証、オーケストレーション、柔軟なスケーリングなど、仮想化されたクラウド製品に対するさまざまな管理要件が提示されることです。

企業顧客のクラウドサービス管理ニーズ

最も一般的に使用される認証機能を例にとると、顧客はビジネスを実行するためにクラウド サーバーのグループを作成します。運用および保守担当者はサーバーを再起動する権限を持っている必要がありますが、他の役割の担当者にはそのような権限は必要ありません。そのため、RestartServer などの API には権限制御が必要です。通常、権限はクラウド プラットフォームで集中管理されるため、個々のクラウド製品を個別に管理する必要はありません。認証を統一的に処理する場合は、現在の API がどのようなリソースを操作しているか、また、それに関連するリソースは何か (たとえば、サーバー関連リソースには、ディスク、ネットワーク カード、ネットワーク、その他の関連リソースが含まれます) を把握し、関連するすべてのリソースを 1 つずつ認証して、API 操作が実行可能かどうかを確認する必要があります。

上記のリソースについては、重要なポイントが 2 つあります。まず、クラウド製品が特定の API を認証できるようにするための統一されたリソース モデルが必要です。第二に、リソースの関係を明確にする必要があります。リソース依存関係が発生した場合、関連する認証が必要になります。リソース関係の必要性は、Google の API ガイドに明確に記載されています。リソース関係は、API 設計モデリングに使用されるだけでなく、プラットフォーム機能の実現にも重要な役割を果たしていることがわかります。リソースの関係を理解し​​ないと、複数のリソースが 1 つの API にカプセル化され、使用や変更が困難になる可能性があります。後から問題が発見され、API を修正して分割したとしても、すでに多くのユーザーが使用しているため、開発コストと通信コストが非常に高くなるか、不可能になる可能性があります。したがって、明確なリソース モデルは API システムを整理するのに役立ちます。

明確に定義されたエンティティ関係図は、より完全なAPIの設計に役立ちます。

さらに、クラウド運用・保守管理インフラストラクチャの構築には、明確なリソース モデルが不可欠です。たとえば、リソースはタグ付け (Alibaba Cloud リソース タグを参照)、グループ化された承認 (Alibaba Cloud リソース グループを参照)、およびリソース監査 (Alibaba Cloud CloudConfig を参照) によって分類および管理できます。オープンソース ソフトウェア Terraform などのオーケストレーション ツールは、リソース モデルによりアクセスと使用が容易になります。

したがって、統合リソース モデルはクラウド サービスに非常に役立ちます。

• API の構造がより明確になり、ユーザーの理解が容易になります。
• API をバックエンドのエンティティ リレーションシップ モデルと比較するのに役立ち、より完全な API サービスを提供しやすくなります。
• 製品のコラボレーションがよりスムーズになり、リソース操作がより標準化されます。
• 基盤となるクラウド サービス プラットフォームをより統一し、実装しやすくすることができます。
• API を中心としたエコシステムの統合をよりシンプルかつ効率的に行うことができます。

非常に多くの利点があるため、多くのクラウド製品にとって、リソース中心のアプローチを維持し、実際に API を設計する際に上流と下流のニーズを十分に考慮することは大きな課題となります。

課題3: API設計スタイル

設計パターンとリソース モデルを決定したら、API 設計の詳細に移ります。 API名、パラメータ名、属性名、データ形式、エラーコードなどの情報は全く問題ないようです。内部のスタイルが一貫している限り、単一の製品は大きな問題にはなりません。ただし、複数のクラウド サービス製品の全体的な外部エクスペリエンスを考慮すると、次の問題を考慮する必要があります。

• API に名前を付けるとき、全体的なスタイルが同様になるようにするには、どのようなパラダイムに従う必要がありますか? API スタイルの統一性を保ち、理解にかかるコストを削減するために、動詞、名詞、前置詞をどのように組み合わせればよいでしょうか。
• 同様の操作についての使用仕様はありますか?どのような共通標準語彙があれば、類似の操作を理解しやすくなり、わかりにくい奇妙な語彙の使用を避けることができますか (たとえば、読み取り操作では、Read/Query/Describe/List/Get のどのような状況でどのような動詞が使用されるか)?
• さまざまな製品の表現における混乱を避けるために、広く使用されているパラメータを可能な限り一貫性のある状態に保つにはどうすればよいでしょうか (たとえば、ページング パラメータには PageNumber と PageNum のどちらを使用すればよいでしょうか)。
• べき等性、ページング、非同期 API 設計などの一般的なシナリオでは、ユーザー エクスペリエンスの一貫性のなさを回避するための統一された仕様がありますか?
• エラーコードはどのように設計すればよいでしょうか?パブリックエラーコードをどのように統一すればよいでしょうか?ビジネスエラーコードはどのように表現できますか?

上記の問題はすべて、実際の研究開発プロセス中に注意を払う必要があるものです。すべてをリストアップすると、これよりはるかに多くなります。 API の文言は、クラウド サービスが外部ユーザーに与える第一印象であり、決して気軽に書かれたものではありません。複数の製品ラインを持つ一定規模の組織にとって、組織のさまざまな部分を調整して統一された外部エクスペリエンスを提供することは大きな課題です。

HTTP プロトコルを振り返ると、最も広く知られているのは HTTP メソッド規則です。これは、9 つ​​の単語を使用して基本的なアクションの仕様を完了し、開発者に明確な思考モデルを提供します。

HTTP メソッド タイプ

画像ソース: https://tools.ietf.org/html/rfc7231

同様に、HTTP ヘッダーではブラウザ情報、言語、ネットワーク接続プロパティなどについても詳細な規定が設けられており、開発者が HTTP サービスを使用する際に一般的な合意が得られ、重要な情報に偏りがなく、異種システムのインターフェースの一貫性が保証されます。

したがって、クラウド サービスでは、API を管理する際に特定の仕様を考慮し、命名規則、標準用語、ベスト プラクティス パターン、エラー コード、その他の情報について明確な規定を設ける必要があります。同時に、API が誤った方向に進まないように、体系的かつプラットフォームベースの方法を使用して API を管理する必要があります。デザイン スタイルは、クラウド サービス API 設計において致命的な問題ではありませんが、クラウド サービスの外観に関係するため無視することはできません。

課題4: サーバー側のフォールトトレランス

API はバックエンド サービスの外部表現です。サービスの場合は、問題が予測可能か予期しないかにかかわらず、問題が発生する可能性があります。機能自体の機能特性のみを考慮し、異常事態に対する設計を無視すると、問題発生時に業務自体がサービスの異常を察知できない可能性があります。さらに、顧客の観点からすると、エラーの原因を効果的に取得できないのは非常に痛いことです。多くの場合、私たちにできることは何もないことであり、クラウド サービス プロバイダーの全体的な評判が低下し、収益に損害を与えることさえあります。

リソースを作成するための API があると仮定します。呼び出しごとに新しいリソースが作成されます。次の状況を考えてみましょう。

• 同じリクエストを複数回送信した場合、リソースは繰り返し作成されますか?
• リクエストの処理時間が長すぎる場合、クライアントは長時間待機する必要がありますか、それとも最初にタスク ID を非同期で返す必要がありますか?
• 待機が必要な場合、タイムアウトの最大値はいくらですか?
• 最大タイムアウト値に達した場合、クライアントの戦略は再試行するか諦めることです。
• 最終処理がまだ失敗する場合は、どのリンクに問題がありますか?正確なエラー情報を提供するにはどうすればよいでしょうか?
• 非同期の場合、非同期処理が完了した後、アクティブなクエリまたは別の通知はありますか?
• サードパーティのツールやインテグレーターはどこからこの情報を取得するのでしょうか?標準化されたプロセスは存在するのでしょうか?

実際には、問題 a が適切に処理されない場合、システムが異常なときに大量のリソースが繰り返し作成され、ユーザーまたはクラウド サービス プロバイダーのデータ損失が発生する可能性があります。問題が適切に処理されない場合、ユーザーは待機を余儀なくされたり、盲目的に再試行したりすることになり、ユーザー エクスペリエンスと効率が著しく低下する可能性があります。 fg は、自動化された処理ツールの効率と統合の効率を最大化する方法に関係しています。

非同期再試行のためのステートマシン

例外が発生すると、API は通常、エラー コードを使用してユーザーに問題を通知します。 HTTP プロトコル自体にはエラー コードに関する詳細な規定があり、RESTful API は可能な限り標準に準拠する必要があります。さらに、クラウド サービスでは、エラーの具体的な内容を説明するビジネス エラー コードやエラー メッセージをさらに提供する必要があります。

現在のクラウド サービスには多くのエラー コードがあり、非常に専門的であるように見えますが、問題は主に次の点に集中しています。

1. エラーの種類が多すぎる: エラー コードが多いほど、クライアントがエラー コードを処理しやすくなりますか? HTTP エラーコードを確認してください。すべてのシナリオをカバーするエラー コードには、5 つの主要カテゴリと数十のサブカテゴリしかありません。通常、誰もがよく知っているステータス コードとしては、200、400、404、500、502 などがあります。エラー コードの数が多いほど、クライアントが switch/case を使用してエラー コードごとに異なる操作を実行できる可能性が高くなると考える人もいます。これは意見の問題です。普通のプログラマーは、それほど多くの分岐プロセスを書かないかもしれませんし、その必要性もあまりありません。

2. エラーメッセージの表現が不十分: 多数のエラーコードを提供することよりも、エラーメッセージの明確な表現の方が重要です。エラーメッセージが十分に詳細でない場合、詳細を理解しておらず、制御できないクラウドサービスのユーザーとして、何が起こったのかを把握することはほぼ不可能です。作業指示書を提出するか、ただ受動的に待つかのどちらかしかできませんが、これでは顧客エクスペリエンスは悪くなります。

3. ビジネス エラー コードの意味は HTTP エラー コードの意味と一致しません。たとえば、パラメーター エラーが発生した場合は、4xx シリーズのコードが返される必要があります。 5xx シリーズのコードを返すのはプロフェッショナルとは言えません。 RPC スタイルの API であっても、HTTP ルールにほぼ準拠する必要があります。そうしないと、HTTP コードに依存する一部のシステムを誤解させる可能性があります。インターネット上では、バックエンドの応答が何であっても、HTTP コードは常に 200 を返し、Body 内のエラー情報は異常な情報を反映するという考えがあります。これは、監視システムがメッセージ本文を識別することによって機能が正常に応答するかどうかを判断することが困難であるため、インターフェイスの監視には役立ちません。

4. 同じエラーが異なるクラウド製品で一貫して表現されない: これにより、クライアント開発に問題が発生し、開発作業量が増加し、自動統合が妨げられ、ユーザーエクスペリエンスが低下します。

5. エラー コードは列挙可能なセットである必要があります。API が生成できるエラー コードの種類は予測可能である必要があります。ビジネスをアップグレードする場合でも、エラー コードの明確なリストを顧客に提供する必要があり、恣意的なものであってはなりません。ユーザーは、いつでも発生する可能性のある予測不可能な種類のエラーではなく、何が起こるかを正確に知る必要があるからです。エラーの種類が不明な場合は、エラーコード分岐処理が基本的に無効であることを意味します。

前述のサーバー側のフォールトトレランスの問題を解決するには、クラウドサービス全体のレベルからAPIのフォールトトレランス設計を強化し、エラーコードを標準化し、エラー情報の管理を強化してユーザーエクスペリエンスを向上させる必要があります。

課題5: バージョン管理

API は継続的に反復され、通常はバージョン管理が必要になります。クラウド サービス API のバージョン管理は、次の理由から特に重要です。

• クラウド サービス API はユーザーに直接提供されます。呼び出し回数が多いため、変更はより広範囲のユーザーに影響を及ぼすため、バージョンの変更は細心の注意を払って行う必要があります。
• クラウド サービスには、主にパブリック クラウド、プライベート クラウド、セグメント化された業界クラウドなど、さまざまな形式があります。クラウドによって、同じ機能 API に対する要件が異なる場合があり、API はより多様化しています。異なるバージョンが正常に機能することを保証し、異なるバージョンを迅速に展開して保守することは非常に困難です。
• 互換性のない変更を推進することは非常に困難であり、ユーザーが短期間で迅速にアップグレードすることは困難です。複数のバージョンの API を維持するコストは非常に高くなります。
• 変更が必要な場合、発信者が変更をタイムリーに認識し、スムーズに切り替えられるようにすることは技術的に非常に困難です。

さまざまな API シナリオを管理するには、さまざまなシナリオのニーズを考慮できる成熟した API 管理プラットフォームが必要ですが、これもかなりの課題です。

課題6: APIの公開方法

API をどのように開くかは奇妙な質問のように思えるかもしれません。 API は他の人に公開されることを意図しているのではないですか?終わったら開けるだけ？しかし、クラウド サービスのシナリオでは、状況は少し複雑になります。

製品テクノロジーは絶えず進化し、機能は常に増加し、新しい API が次々と登場しています。顧客の観点から、開発された API のオープン性に対する要件は何ですか?クラウド製品に 100 個の機能があり、そのうち 20 個は社内でのみ保持でき、合計 80 個の機能が公式 Web サイトで提供され、パブリック API に公開されているのは 50 個だけだとします。これはユーザーが期待する状態でしょうか?理想的な状態とはどのようなものでしょうか?

クラウド サービスには巨大なエコシステムが存在します。一般的な開発者に加えて、サードパーティのサービスプロバイダー、企業顧客、オープンソースツールも多数存在します。これらすべてのエコシステムメンバーのニーズを考慮すると、クラウドサービス自体の機能セットと顧客が利用できる機能セットの違いが、製品のオープン性の度合いをよりよく反映していることがわかります。ここでの違いは、クラウド サービスがすでに備えているものを強調しており、クラウド サービス自体に備わっていないサービスは含まれません。顧客が利用できる機能とクラウドサービスが提供できる機能のギャップが大きいほど、多くの機能が予約プログラムとして隠蔽されるため、クラウド製品のオープン性が低下し、顧客やサードパーティのサービスプロバイダーはクラウドベンダーに近いサービスを享受できず、最終的にはエコシステムを拡大できなくなります。クラウド サービス プロバイダーが API を通じて利用できる機能を、顧客も OpenAPI を通じて利用できるようにして、内部と外部に見えるものの一貫性を保つことが理想的です。

しかし、特定の API を公開するかどうかについては、実際には次のような考慮事項が考慮されています。

• API はリリースされたばかりで、まだ完全に洗練されていません。軽率に開けると危険が潜んでいる可能性があり、調整するには遅すぎるため、まだ開けないことにします。
• API 自体はアトミックではなく、複数のビジネス シナリオをカプセル化します。その主な目的は、パフォーマンスを最適化したり、特定の顧客にサービスを提供したりすることです。すべてのユーザーに公開する必要はありません。さらに、ビジネスシナリオが変化すると調整が難しく、開業には適していません。
• 特定の業種向けのAPIなど、すべてのユーザーに公開するには適しておらず、部分的にしか公開できないAPIもあります。
• API は特定のシナリオまたはプライベートなシナリオでのみ使用され、外部からアクセス可能である必要がありますが、ユーザーに公開することはできません。

これらの問題に対処するには、API 管理メカニズムに取り組み、さまざまなシナリオを区別し、メタデータを適切に管理する必要があります。すべてのオープン API がオープンであること、および内部および外部の顧客が見る機能セットが基本的に一貫していることを保証するために、API がオープンであるかどうかに関する明確な仕様と測定メカニズムが必要です。これにより、クラウド サービスの統合が強化され、顧客のビジネスにおいてより大きな役割を果たすことができるようになります。

課題7: APIシステムを接続する方法

クラウド サービスのシナリオでは、API は単独では存在しません。

まず、API が公開された後、ユーザーがスムーズに API を利用するためには、サポート体制が不可欠です。 SDK、ドキュメント、ツール チェーンの統合をすべて考慮する必要があります。ここでの焦点は、正確性、適時性、一貫性をどのように確保するかです。開発エンジニアは一般的にドキュメントを書くのが好きではなく、専門的にドキュメントを書く人は技術をあまりよく理解していない可能性があります。国際化の問題を考慮すると、非常に困難になります。 SDK に関しては、API を複数の言語で実装する必要があり、各言語で専門性と使いやすさを確保する必要があります。これは、開発者のプログラミング言語の習熟度と API の理解度をテストするのに最適です。業界でよく使用される SDK の自動生成方法では、複数の言語との互換性もテストされます。 Alibaba Cloud の API Explorer、CloudShell などのツール チェーンも、API の最新ステータスとタイムリーに同期する必要があります。

第二に、クラウドサービスには多くの製品ラインがあるため、ユーザーがAPIや関連ツールの使い方を素早く習得できるようにするには、チュートリアル、ケース、ランタイム環境など、多くの面での構築を強化する必要があります。クラウド サービスを中心に、terraform/ansible/spinnaker などのオープン ソース ソフトウェアなど、多くの上位レベルのエコロジカル ツールが開発されてきました。これらはクラウド サービスをより良く利用するのに役立ちますので、サポートを提供する必要があります。それをいかに早くカバーするかが、プラットフォーム開発能力の試金石にもなります。

さらに、API自体の品質保証も非常に重要です。一般的に、パフォーマンス、安定性、セキュリティなどの観点から保証システムを考慮し、ストレステスト、監視、保護ソフトウェアの導入を通じて、サービス中に API が失敗しないようにする必要があります。従来の方法はシステムの問題を解決するのに非常に効果的ですが、特定のビジネス上の問題に関しては無力です。たとえば、サーバーを作成するための API では、通常、べき等性が求められます。 API が実際に冪等性を実現しているかどうかをどのように検出できますか?さらに、他のビジネス プロセスの正確性をどのように保証できるでしょうか? API が公開された後で問題を修正するのは遅すぎます。当然のことながら、このような問題はオンラインになる前にテストを通じて発見される必要があります。しかし、ビジネスが発展するにつれて、そのような問題に対する統一された解決策があり、リスクをタイムリーに検出して損失を回避するために長期的にフォローアップできるようにするにはどうすればよいでしょうか?

Alibaba Cloud API システムの簡単な図

諺にあるように、量的変化は質的変化をもたらします。上記の問題は、単一の API であれば簡単に解決できますが、API の規模が数万に達すると、プラットフォームベースかつ体系的な手段で解決する必要があります。たとえば、API サービスの信頼性 SLA 指標が 4 つの 9 に到達するには、明確な基準を確立する必要があり、すべての API の動作結果を監視し、成功率を分析して期待レベルに到達したかどうかを判断する手段が必要です。これにより、クラウド サービス自体の基盤となるシステム構築に高い要求が課せられます。

そのため、API を中心とした関連システムを改善し、ユーザー エクスペリエンスの一貫性、適時性、安定性、使いやすさを確保することは非常に困難です。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

https://tools.ietf.org/html/rfc7231#section-4

https://www.cnblogs.com/sparkdev/p/10052310.html

https://www.grpc.io/docs/guides/

https://www.terraform.io/docs/index.html

http://www.grabsun.com/article/2015/1135807.html