web-dev-qa-db-ja.com

APIとマイクロサービスの本当の違いは何ですか？

マイクロサービスについて学んでいますが、REST APIとmicroservices？を作成しますか？
Goで作業していますが、私の質問はすべての言語に当てはまります。

restapiarchitecturemicroservices
13
fm433403

Microservicesのアプローチは、システム（「コードの山」）を多くの小さなサービスに分割することです。通常、それぞれに独自のサービスがあります。

  • 明確なビジネス関連の責任
  • 実行中のプロセス
  • データベース
  • コードバージョン管理（Gitなど）リポジトリ
  • [〜＃〜] api [〜＃〜]（他のサービス/クライアントがマイクロサービスに接続するプロトコル）
  • UI

サービス自体は保持されますsmall。システムが成長するにつれて、より大きなサービスではなく、より多くのサービスがあります。

マイクロサービスは、REST、RPC、または他の方法を使用して相互に通信できるため、RESTまたはAPIはマイクロサービスのトピックに実際に直交しています...

参照： APIとは？英語でお願いします。

12
Lior Bar-On

API = アプリケーションプログラミングインターフェイス

マイクロサービス= アーキテクチャ

要するに

  • マイクロサービスは、明確に定義されたAPIを公開する必要があります。
  • マイクロサービスは、ソリューションを設計する方法です。
  • APIは消費者が見るものです。
  • バックエンドでマイクロサービスを使用せずにAPIを公開できます（実際、トレーニング以外のほとんどのシナリオではマイクロサービスは不要です）。

マイクロサービスの使用を決定する前に、 http://samnewman.io/books/building_microservices/ を読むことをお勧めします（トレーニング目的でない場合）。

7
Lech Migdal

回答の大部分は、APIをプログラムインターフェイスとして古くから理解していることに基づいています。現在、この意味は溶けており、一部の開発者が（単純または誤って）アプリケーションのAPIをアプリケーション自体として解釈するため、人々を混乱させ始めています。そのような場合、最新のAPIとマイクロサービスを区別することはできません。それにもかかわらず、APIアプリケーションは多くのマイクロサービスで構成でき、そのほとんどはマイクロサービスのAPIを介してアプリケーション内で対話し、他のAPIはアプリケーションのAPIとしてAPIを公開することができます。また、（サービスとしての）マイクロサービスには、他のマイクロサービス（サービス）を含めることはできませんが、APIベースの呼び出しを介してマイクロサービスの構成を調整することができます。アプリケーションにはマイクロサービスが含まれる場合がありますが、ベストプラクティスでは、他のアプリケーションが含まれない場合があります。

2
Michael Poulin

マイクロサービスは、次の場合に明確に定義されますSOC-懸念の分離エンティティ/ドメインレベルで、各エンティティ/ドメインは他のサービスから独立しています。

例ユーザーサービスは、ユーザー関連情報の保存、更新、削除のみを担当します。

マイクロサービスバックエンドとフロントエンドマイクロサービスはさらに2つの部分に分割できます

  1. Web APIのような残りのエンドポイントを公開するフロントエンドマイクロサービス
  2. 実際にすべての操作を実行するバックエンドマイクロサービス。

REST APIは、外界に公開されるエンドポイントの多くであり、上記で説明したように、マイクロサービスでも使用できます。

2
Vijay Parmar

マイクロサービス

マイクロサービスアーキテクチャ は、アプリケーションロジックを小さな断片または「コンポーネント」にスライスし、それらの間で動作したり、APIを介して公開したりすることです。

API

（Web）アプリケーションは、オブジェクトエンティティ（モデル）のすべてのセットとそれらに対する可能な操作を使用してビジネスロジックを設計する必要があります。 （アプリケーションプログラミングインターフェース）[- https://en.wikipedia.org/wiki/Application_programming_interface ）は、呼び出しを担当する特定のエントリポイントを公開することにより、アプリケーションにリクエストを行う方法です。適切なアプリケーション操作。

REST（ful）API （Representational State Transferの「REST」）は、少なくともこれらに準拠するAPIです 5制約 ：

  • ユーザーインターフェイスは、データの保存および操作とは異なります（クライアントサーバーアーキテクチャ）
  • クライアントコンテキストはサーバーに保存されません（「ステートレス」）
  • サーバーの応答は、暗黙的または明示的に、自身をキャッシュ可能かどうか定義する必要があります
  • クライアントは、自分とサーバーの間のレイヤーを意識する必要はありません。
  • 応答/要求メッセージは、次のとおりである必要があります。リソースを識別できるようにします。リソースを操作できる表現を使用します。利用可能なアクションとリソースをアナウンスします（「統一インターフェース」）。

「本当の違い」

したがって、これらの概念は明らかに関連していますが、明確に異なる概念です。

  • RESTfulであるかどうかにかかわらず、[〜＃〜] api [〜＃〜]は、サーバーによって提供される操作を公開します。より小さなコンポーネントに（microservices）。

  • また、一般的なWeb（REST）APIはクライアントとサーバー間でHTTPプロトコルを使用しますが、マイクロサービスアーキテクチャ内のコンポーネントは他のプロトコルを使用して通信する場合があります（例 [〜＃〜] wamp [〜＃〜 ] 、 [〜＃〜] amqp [〜＃〜] 、 JSON-RPC 、 XML-RPC 、 [〜＃〜] soap [〜＃〜] 、...）

0
Cédric Françoys

素人の言葉では、web APIサーバーがあり、それらを複数の独立したミニサーバーに分割する場合、プロキシサーバーとロードバランサーを使用してそれらをクラスター化し、（オプションで、それぞれ個別のデータベースを指定しますエンティティ）、つまりマイクロサービスアーキテクチャです。

0
LEMUEL ADANE