元のリンク：https：//blog.csdn.net/zpoison/article/details/80729052
1.
SOAアーキテクチャとマイクロサービスアーキテクチャの違いまず、SOAとマイクロサービスアーキテクチャは1つのレベルにありますが、ESBとマイクロサービスゲートウェイの場合は同じレベルです。1つはアーキテクチャのスタイルと方法について説明し、もう1つは実装ツールまたはコンポーネント。
1. SOA（サービス指向アーキテクチャー）「サービス指向アーキテクチャー」：これは複数のサービスを含む設計手法であり、サービスは最終的に相互依存を通じて一連の機能を提供します。サービスは通常、オペレーティングシステムプロセスとは独立した形式で存在します。さまざまなサービスがネットワークを介して呼び出されます。
2.マイクロサービスアーキテクチャ：実際、SOAアーキテクチャと同様に、マイクロサービスはSOAに昇華します。マイクロサービスアーキテクチャの重要なポイントは、「ビジネスを完全にコンポーネント化してサービス指向にする必要がある」ということです。元の単一のビジネスシステムは解体されます。 。独立して開発、設計、実行できる複数の小さなアプリケーションに分割されます。これらの小さなアプリケーションは、サービスを介した相互作用と統合を完了します。
マイクロサービスアーキテクチャ= 80％のSOAサービスアーキテクチャのアイデア+ 100％のコンポーネント化されたアーキテクチャのアイデア+ 80％のドメインモデリングのアイデア
2.ESBおよびマイクロサービスAPIゲートウェイ。
1. ESB（エンタープライズサービスバス）。簡単に言えば、ESBはさまざまなサービスノードを接続するパイプラインです。さまざまなシステムとさまざまなプロトコルのサービスを統合するために、ESBはメッセージの変換、解釈、ルーティングを行っており、さまざまなサービスを相互接続できます。
2. APIゲートウェイ：APIゲートウェイはサーバーであり、システムへの唯一の入り口です。オブジェクト指向設計の観点からは、外観モードに似ています。APIゲートウェイは、システムの内部アーキテクチャをカプセル化し、クライアントごとにカスタマイズされたAPIを提供します。また、認証、監視、負荷分散、キャッシング、要求の断片化と管理、静的応答処理などの他の責任もあります。APIゲートウェイ方式のコアポイントは、すべてのクライアントとコンシューマーが統合ゲートウェイを介してマイクロサービスにアクセスし、すべての非ビジネス機能がゲートウェイレイヤーで処理されることです。通常、ゲートウェイはREST / HTTPアクセスAPIも提供します。サーバーは、API-GWを介してサービスを登録および管理します。
3. SOAアーキテクチャーの機能：
システム統合：システムの観点から、エンタープライズシステム間の通信の問題を解決し、当初散在していた計画外のシステムのメッシュ構造を、システム間の通常の管理可能なスター構造に編成します。このステップでは、多くの場合、いくつかの製品の導入が必要です。 ESB、技術仕様、サービス管理仕様など。このステップで解決される主要な問題は[整然とした]
システムのサービス化：機能の観点から、ビジネスロジックは再利用可能で組み立て可能なサービスに抽象化され、サービスオーケストレーションによって迅速なビジネス再生が実現されます。目的：元の固有のビジネス機能を一般的なビジネスサービスに変換します。ビジネスロジック;このステップで解決される中心的な問題は[再利用]です
サービス指向ビジネス：企業の観点から、企業機能を再利用可能で組み立て可能なサービスに抽象化します。元の機能的な企業アーキテクチャをサービス指向の企業アーキテクチャに変換して、企業の外部サービス機能をさらに強化します。どちらのステップも問題を解決することです。技術レベルからのシステム呼び出しとシステム機能の再利用について」3番目のステップは、ビジネスドライブに基づいてビジネスユニットをサービスにカプセル化することです。このステップで解決される中心的な問題は[効率的]です
4.マイクロサービスアーキテクチャの機能：
1。サービスによるコンポーネント化
開発者は、このサービスに対する他のサービス展開の影響を調整する必要がなくなりました。
2.ビジネス能力に応じてサービスチームと開発チームを分割します
開発者は開発技術を自由に選択してAPIサービスを提供できます
3.分散化
各マイクロサービスには、ビジネスデータを永続化するための独自のプライベートデータベースがあります。
各マイクロサービスは、独自のデータベースにのみアクセスでき、他のサービスのデータベースにはアクセスできません。
一部のビジネスシナリオでは、1つのトランザクションで複数のデータベースを更新する必要があります。この場合、他のマイクロサービスのデータベースに直接アクセスすることはできませんが、マイクロサービスを操作します。
データの分散化により、マイクロサービス間の結合がさらに減少します。サービスごとに異なるデータベーステクノロジー（SQL、NoSQLなど）を使用できます。複雑なビジネスシナリオでは、複数のマイクロサービスが含まれている場合、それらは通常、クライアント側または中間層（ゲートウェイ）で処理されます。
4.インフラストラクチャの自動化（devops、自動展開）
Java EEデプロイメントアーキテクチャは、プレゼンテーションレイヤーを使用してWARをパッケージ化し、ビジネスレイヤーはJARに分割され、最終的にEARの大きなパッケージとしてデプロイされます。マイクロサービスはこのブラックボックスを開き、アプリケーションを単一のサービスに分割し、Dockerテクノロジーを適用します。サーバーやデータモデルに依存しません。自動化によって個別にデプロイできるフルスタックアプリケーションです。各サービスは独自のプロセスで実行され、多くの場合HTTPリソースAPIに基づく軽量の通信メカニズムを介して接続されます。これらのサービス容量の構築は集中管理を実現できます（サービスが多すぎるため、集中管理なしではDevOpsを実現できません）。
5.主な違い：
機能
SOA
マイクロサービス
コンポーネントサイズ
ビッグビジネスロジック
個々のタスクまたはビジネスロジックの小さな部分
カップリング
通常、疎結合
常に疎結合
会社の構造
いかなるタイプ
小規模で機能的なクロスファンクショナルチーム
管理
中央管理に焦点を当てる
分散型管理に焦点を当てる
目的
アプリケーションが相互運用できることを確認します
新しい機能を実装し、開発チームを迅速に拡大する
6.ダボサービスの
下請けのベストプラクティス
サービスインターフェイス、リクエストサービスモデル、および例外情報はすべてapiに配置されます。これは、再利用とリリースの同等性の原則に準拠しており、共通の再利用の原則
はapiのスプリングリファレンス構成に配置されます。モジュールのパッケージディレクトリに配置することもできます。
粒度
インターフェイスを可能な限り粗く設定します。各サービスメソッドは、関数ステップではなく、独立した関数を表します。それ以外の場合は、分散トランザクションが含まれます。
サービスインターフェイスは、ビジネスシナリオに分割することをお勧めします。また、インターフェイスの急増を防ぐために同様のビジネスを抽象化します。
過度に抽象化された一般的なインターフェイスT T <generic>を使用することはお勧めしません。インターフェイスには明確なセマンティクスがないため、後のメンテナンス
バージョンが提供されます。
各インターフェイスには、後続の互換性について将来を見据えた考慮事項を提供するようにバージョンを定義する必要があります。バージョン（maven -snapshot）
では、2桁のバージョン番号を使用することをお勧めします。互換性がありません。サービスバージョン
インターフェイスが互換性なくアップグレードされた場合、最初に半分または1つのプロバイダーを新しいバージョンにアップグレードし、次にすべての消費を新しいバージョンにアップグレードしてから、プロバイダーの残りの半分を新しいバージョンにアップグレードします。
プレリリース環境
推奨される使用法
管理者情報
を
構成するために、タイムアウト、リタイア、スレッドプールサイズ、LoadBalanceなど、プロバイダー側でコンシューマーの属性を可能な限り構成します。
アプリケーションで構成された所有者と所有者には、2人以上を構成することをお勧めします。所有者はモニタリングセンターで
設定ダボキャッシュファイルを見ることができるため
登録センターのリスト
サービスプロバイダーのリスト
————————————————
著作権表示：この記事は、CSDNブロガー「zpoison」の元の記事であり、CC 4.0BY-SAに準拠しています。著作権表示。再印刷してください。元のソースとこのステートメントへのリンクを添付してください。
元のリンク：https：//blog.csdn.net/zpoison/article/details/80729052