web-dev-qa-db-ja.com

SOAとマイクロサービスの実際の違いは何ですか

免責事項

私は誰かのつま先を踏んだり、どちらかのコンセプトの愛好家を怒らせたりしていないことを願っています

バックグラウンド

realサービス指向アーキテクチャとマイクロサービスの違いを探していましたが、明確な答えは見つかりませんでした。

私は次のようなものを読みます：

  • sOAの副作用
  • SOAはアンチパターン
  • マイクロサービスはSOAの障害を修正するようになりました
  • ESBは実際にはESBではなく、EAIです
  • メッセージブローカーへの過度の依存
  • ベンダーはSOA）の概念を悪用し、自社製品の販売を試みています
  • SOAが制御不能に成長する

しかし、それでも、サービス指向アーキテクチャ（概念として）とマイクロサービス（概念として）のアーキテクチャの違いを明確に定義しているものはありません。

私が理解したことによると、彼らは両方とも持っています：

  • サービスプロバイダー、1つのことだけを行う
  • これらのサービスをコンシューマーに公開するService Gateway/ESB
  • ESB/Service Gatewayを介してサービスにアクセスするサービスコンシューマー

質問

したがって、SOA= Microservicesに再ラベル付けすること以外に何か違いはありますか？それは、Microservicesがマクロになることを制限するために配置されたテクノロジーの制約ですか？

注：私は意見を探しているのではなく、難しい事実のみを説明します

参考文献

更新

同様の議論が スタックオーバーフローの質問 でも発生したようですが、マイクロサービスがサービス指向アーキテクチャであるかどうかにかかわらず、意見は分かれています。

SO質問からの結論：

  • MSは特別な場合 SOAの
  • MSは、サービスをホストするアプリケーションのより小さいサイズを推奨します
  • MSはテクノロジーに依存します（オープンプロトコルオプションではなくHTTPの使用）
  • MSはテクノロジーに依存して規律を強制します（サービスの自動展開）
  • MSはESB（悪）を考慮しますが、APIゲートウェイを使用しますIMHOはESBの一種です

次の条件に当てはまる場合、MSはSOAであると結論付けます。

  • MSはオーケストレーションの概念をサポートしていますか？ワークフローを管理する1つ以上のマスタープロセス
  • MSにメッセージブローカーレイヤーはありますか？メッセージフォーマットをサービスプロデューサーのメッセージスペースからサービスコンシューマーに変換する一連のアダプター
  • マイクロサービスはモノリシックエンタープライズアプリケーションからデータを読み取ることができますか？モノリシックアプリケーションのAPIにすることはできますか？それとも独立して動作できるスタンドアロンの自己完結型アプリケーションでなければなりませんか？

最後の質問に対する答えが「いいえ」であることが判明した場合、マイクロサービスは複雑なワークフローシステムを処理することができません。クレジットカード管理システム、または調整システム

microservicesenterprise-architecturesoa
10
A.Rashad

これが最終的な結果です[〜＃〜] soa [〜＃〜]との明らかな違いマイクロサービスは、

スマートエンドポイントダムパイプ

[〜＃〜] soa [〜＃〜]とは異なり、トラフィックの管理、メッセージ形式の変換、およびサービスの委任に気づかないサービスのコンシューマーとプロデューサーに依存します外部システムへのオーケストレーション、例えばESB、サービスオーケストレーター、メッセージブローカー。

2
A.Rashad

サービスプロバイダー、1つのことだけを行う

プロジェクトの結果が広範囲に及ぶ主な違いは、マイクロサービスではこれらのサービスプロバイダーが独立して展開およびスケーラブルであることです。

俊敏性を高めることができるので、これは素晴らしいことです。サービスを変更する必要がある場合は、そのサービスを変更するだけで、種類は変更されません。新しいフレームワークまたは言語を試してみたい場合は、その1つのサービスをドロップインで置き換えてください。突然100倍の容量が必要になった場合は、その流入を処理するために、そのサービスで新しいマシンを起動してください。何かをバージョン管理したい場合は、wholeアプリに触れずにバージョン管理を行ってください。 And監視、計測、チーム間での分割、廃止...

しかし、それはいくつかの重大な影響を伴います：

  • いくつかのサービスをデプロイすることは、数十のサービスをデプロイすることとはかなり異なるため、リリースプロセスを変更する必要があります。
  • 1台のマシンへのサービスのデプロイは数十台のマシンへのデプロイとは方法が異なるため、リリースプロセスを変更する必要があります。
  • この大きな共有DBを機能させる（他のすべてのサービスを壊す）ために展開する必要がある場合、サービスを展開することは意味がないので、データベースの設計、使用、および展開を変更する必要があります。
  • この共有ライブラリを更新する必要がある場合（他のすべてのサービスを壊す必要がある場合）は、サービスをデプロイしても意味がないため、ライブラリの設計と使用方法を変更する必要があります。
  • ロギング、承認、セッション管理などは、サービスが1つの場合は非常に簡単に共有できますが、製品を構成する独立した小さなサービスがたくさんある場合は異なるため、変更する必要があります-going何かを共有したい。ああ、そしてそのすべての共有されたものは、異なるバージョンにある可能性があることに対処する必要があります。
  • コミュニケーションを変える必要があります。いくつかのサービスを使用すると、通信が頻繁に発生しない、または通信速度が遅くなる可能性がある場所で物事を中断できます。マイクロサービスを使用すると、彼らはお互いに多くのことを話し合うでしょう、そして高い待ち時間はそれをカットするつもりはありません。
12
Telastyn