SOAとマイクロサービスの実際の違い

免責事項

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

バックグラウンド

私は明確な答えを見つけることなく、サービス指向アーキテクチャとマイクロサービスの真の違いを探していました。

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

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

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

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

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

質問

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

注：箇条書きで意見を探すのではなく、難しい事実を探しています。

参考文献

• ソフトウェア工学の質問
• マーティン・ファウラーのサイト（彼はそれが大いに嫌いだと思う）
• 情報の世界
• マイケル・フェザースのウェブサイト
• スタックオーバーフローの質問

更新

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

SOの質問からの結論：

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

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

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

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

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

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

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

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

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

ここではボトムラインは、間に1つの明らかな違いであるSOAとMicroservicesはの概念であります

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

SOAとは異なり、それは気付かないサービスのコンシューマーとプロデューサーに依存し、トラフィック管理、メッセージ形式の変換、サービスのオーケストレーションを外部システム（ESB、サービスオーケストレーター、メッセージブローカーなど）に委任します。