By Marco Fioretti
以前に公開した マイクロサービスの概要 ますます多くの企業のソフトウェアインフラストラクチャで彼らが果たす重要な役割について概説しました。その記事では、マイクロサービスはアプリケーションプログラミングインターフェイス（API）ではなく、他のほとんどのソフトウェアと同様に、それらを使用する必要があることも指摘しました。今回は、マイクロサービス用のAPIの主な特徴と、それに対応するベストプラクティスを紹介します。
マイクロサービスのAPIは特別です
パブリックAPIは、多国籍企業から単一のプログラマーまで、誰もが使用でき、アクセスできる汎用インターフェース（IPネットワーキングなど）です。代わりに、プライベートAPIまたは内部APIは、1つの会社またはソフトウェア製品によってのみ使用および使用できるものになります。
システム内の場所によっては、マイクロサービスはこれら2つのカテゴリのAPIの任意の組み合わせを使用する必要がある場合があります。ただし、どちらの場合も、これらのAPIは、過小評価してはならない特定の課題に直面します。
最初の問題はセキュリティです。マイクロサービスは、クラウドベースの高度に分散された高度に異種の環境内に存在し、多くのホストに分散しています。このような状況では、「外部」の脅威がいたるところに現れる可能性があります。同じアプリケーションのモノリシック実装では、完全に内部的である、つまり（理論的には）外部からの攻撃から安全であるAPIを介しても、同じプロセス内の関数間で呼び出されます。
マイクロサービスのこの性質と、ビジネスの需要に応じて急速に拡張するという一般的な期待は、全体的なパフォーマンスに深い影響を及ぼします。モノリシックプログラムのコンポーネントは、通常、1つまたはいくつかのプロセスの一部として実行され、すべて同じホスト内で実行されます。最も遅い場合は、同じLAN上で実行されます。 APIを自由に使用して、わずか数ミリ秒で何百回も情報やデータを交換できます。同じアプリケーションのマイクロサービス実装では、これらの同じ内部呼び出しの多くは、他のマイクロサービスへの数十のAPIリクエストになり、多くの場合インターネットを介して、完了するのに時間がかかりすぎます。
マイクロサービスAPIのベストプラクティス
結論は明らかです。マイクロサービスAPIは、これらの特定の制約から始めて、モノリシックプラットフォームで十分なものよりも注意を払って設計する必要があります。
まず、設定を回避することが重要です。一部のプラットフォームのマイクロサービスのAPIを、それらのマイクロサービスの1つまたは2つだけのニーズと機能から始めて設計しないでください。代わりに、 全体 適度に完全でありながら、将来の改善にオープンなプラットフォーム。
このアプローチは、全体的なパフォーマンスを最適化するだけでなく、リスクを最小限に抑えます。現代のビジネスでは、特定のプラットフォームのすべてのマイクロサービスが並行して開発されることを期待することがよくありますが、そのように作業することは、モノリシックアプリケーションで行う場合よりもリスクが高く、長期的には問題が発生する可能性が高くなります。
次に、API設計では、マイクロサービスがAPIを介して実行するトランザクションの数（各トランザクションを閉じるために必要なメッセージの量と平均サイズ）を実際に最小限に抑える必要があります。同じことがAPIにも当てはまります 再設計 既存のモノリシックプラットフォームから移行する場合。
第三に、マイクロサービスを提供します フレキシブル さまざまな種類のメッセージを送受信できる通信ポイント。そして、これらのメッセージ、より正確にはAPI全体に、新しいバージョンは機能を追加するだけで、機能を変更または却下することはめったにないため、すべての下位互換性を維持する明示的なバージョン番号を付けます。
これは古き良きです 「ロバストネス原則」、マイクロサービスの次のレベルは、APIの作成で構成されています 「ハイパーメディア主導」。この用語は、Webリンク、メニュー、およびフォームに相当するマシン間を含むAPIを示します。これにより、どのアクション、つまり「APIアフォーダンス」が可能かを説明するメタデータを交換できます。このようにして、「サーバー」マイクロサービスがメッセージ内の何かを変更することを余儀なくされた場合、その「クライアント」は、書き直されることなく、変更を検出してそれに適応できます。
それらすべてにサービスを提供する1つのゲートウェイ
これまでに説明したすべてのプラクティスに加えて、マイクロサービスプラットフォームを大幅に支援できる別のツールは 「APIゲートウェイ」、これは、特定のプラットフォームのすべてのマイクロサービスへのすべての外部リクエストに対する単一のエントリポイントです。これらのリクエストが到着すると、ゲートウェイはそれらをさまざまなマイクロサービスに対するより単純なリクエストに分割したり、すべての回答を1つのメッセージに集約して元の発信者にのみ転送したりできるため、関係するすべての関係者にとって大きなメリットがあります。
まず、API Gatewayは、プラットフォームの攻撃対象領域を減らし、認証とアクセス許可をさまざまな場所に複製するのではなく、一元化することでセキュリティを向上させることができます。すべてのマイクロサービスへの適切な接続があれば、ゲートウェイは 増加 特にモバイルクライアントでの全体的なパフォーマンス。ゲートウェイを使用すると、そのようなクライアントは、潜在的に異なるホスト上で、毎回複数のマイクロサービスを要求するのではなく、1つの場所に対して1つの遅い要求のみを行うことができます。
同様に重要なのは、必要に応じてマイクロサービスを自由に進化させるAPIゲートウェイの機能です。多くのマイクロサービスで構成されたプラットフォームは、開発者に利点をもたらします 前回の記事で説明しました。ただし、クライアントにとっては、同じ断片化が問題になる可能性があります。 彼ら 単一のAPIであった可能性のあるものを多くの小さなインターフェースに分割する方法を知っている必要があります。
外部クライアントと内部マイクロサービスの間にAPIGatewayを配置すると、現在と将来の両方でこの問題が解決されます。マイクロサービスを使用することの全体的なポイントは、構成、内部通信チャネル、またはプライベートクラウドまたはパブリッククラウド全体での物理的な分散でさえ、可能な限り問題なくいつでも自由に変更できると説明できます。
しかし、これは、舞台裏で何が起こっても、常に同じインターフェースとサービスを公開するゲートウェイが中央にある場合にのみ可能であり、少なくともはるかに簡単です。
