みなさん、こんにちは、今日我々は、単一のサービスアーキテクチャとマイクロアーキテクチャのサービスを比較します。
あなたは、Webアプリケーションの開発プロセスをやっている場合は、単一のサービスまたはマイクロアーキテクチャのサービスアーキテクチャで終了する際に考慮しなければなりません。一般的には、使用しているアーキテクチャの種類に関係なく、あなたがネットワークに最適なアプリケーションを書くことができます。
1が優れている最後に、これらの二つのアーキテクチャそう？この質問に答える前に、まず自分のネットワークアプリケーションの機能要件を見てください。
[高速]単一のサービスのアーキテクチャ開発
単一のサービス・アーキテクチャは、従来のサーバアーキテクチャは、常にされている、それはサーバー上で実行して、単一のプログラムによって提供されます。
このサービスアーキテクチャのメリット、開発スピード、高動作効率。最初はあなたが実行する最も基本的な業務プロセスを記述することができ、その後、将来の拡張に機能を追加し続けました。
[シングル]より高速なサービスアーキテクチャを実行します
なぜ単一のサービスは、より高速なマイクロアーキテクチャのサービスアーキテクチャよりもですか？冗長サービスの間に単一のサービスアーキテクチャの通信が存在しないからです。マイクロサービスアーキテクチャと同様に、多くのマイクロサービスがあり、それらの間の通信は、あなたはマイクロサービス・システムを使用している場合、それは避けられない、HTTPを介して行われます。追加のパフォーマンスを必要としない単一のサービス・アーキテクチャは、部分的に消費されます。
簡単に言えば、単一のサービス・アーキテクチャ・プログラムは、スペース内には、宇宙プログラム内で行われるデータ共有プログラムのプログラム上で実行されています。非常に迅速にスピードもちろん。
具体的には、データベースの単一の統合サービスアーキテクチャは、等ユーザ認証、注文管理、製品管理、などの各機能モジュールがある、データベースにアクセスします。
それは共有データベースであるため、それらはサーバーオペレーティングシステムにインストールされ、ファイルシステムを共有します。
[特徴]マイクロサービスアーキテクチャシステム
マイクロアーキテクチャサービスシステムで次の表情。
マイクロサービスアーキテクチャ・システムは、各サービスは、製品の管理はまた、別のプログラムの空間である、注文管理はまた、別のプログラムの空間であり、そのようなユーザ管理などの別のプログラムの空間は、別のプログラムの空間です。プログラム空間は、独自のデータベースを持つことができ、あるいはスペースは、各プログラムは、別のサーバ上で実行することができます。
それでは、どのようにこれらのサービスは仕事ですか？たとえば、サイトに入る前に、ユーザーは、ユーザーが最初の管理サービス、ログインが成功したかどうかのチェックを呼び出す必要があります。あなたが手に入れることができるかどうトークンログインが成功した後、あなたがあなた自身の注文を得ることができるので、受注はまた次の操作を待つことができ、注文管理データを取るためにあそこに行きます。これらのサービス間の相互作用は、HTTP通信を介して実行されています。
キャリア通信モードは、一般的に統一フォーマットJSONデータとして使用されます。
[フォールトトレラントアーキテクチャの単一のサービスシステムの欠点]
問題になるその後、我々は、単一のサービスアーキテクチャを見て？主な問題は、サーバー上の宇宙プログラムRANとしてその単一のサービス・アーキテクチャでは、すべてのプログラムモジュールは、正常な動作を確保できることを確認するために、完全なテストを通じて時間の一部を変更する必要があります。あなたのプログラムが書き込みの特定の部分が非常に良いではありませんしている場合、それは全体的な動作に影響を与える可能性があります。
場合は特に、あなたのサービス・フレームワークは、あなたの言葉の非常に大規模な、非常に大規模なプログラムです。ほとんど変化は、あなたがすべてのプログラムを再コンパイルすることもできますし、すべてのプログラムを再展開し、我々は全体の宇宙計画の単一のサービス・アーキテクチャは、プロセス内で実行されている知っています。
[マイクロサービスの利点のフォールトトレラントシステムアーキテクチャ]
そして、マイクロサービスアーキテクチャは、それを行う方法ですか？単一サービスシステムアーキテクチャ、すべての部品が独立したプロセスである別のプログラム領域に分割されているからです。従って、各部分は、別個のサーバ上に配備することができます。
この方法では、時間の一部を変更し、唯一の唯一の他の部分には影響しません。このスペースのあなたの現在のプログラムに影響します。この部分を展開する必要があります。
テスト、個別にテストすることができ、個々のサービスのマイクロサービスアーキテクチャ。
それが失敗した場合の動作時には、サービスのマイクロサービスアーキテクチャ、あなたはまた、選択肢を持つことができます。だから、サービス全体が失敗しないこと。何の代替サービスが存在しない場合は、直接返され、現在のページがそれに存在しません。
一部に障害が発生した場合でも、単一のサービスアーキテクチャのシステムでは、それは全体のサービスプログラムを実行することはできませんが発生します。シングルサービスのシステムアーキテクチャが唯一のプロセスなので、プロセスのダイは、もちろん、すべてのサービスが実行されていません。
[再利用のマイクロサービスアーキテクチャとシステムのスケーラビリティの利点]
マイクロサービスの最大の利点を使用すると、無制限のサービスを、あなたのプログラムの無限の拡張の多様性を追加できるということです。
もう一つの利点は、マイクロサービスの再利用ということです。既存のサービスモジュールは、再組み立て、その後、プログラムに新しいアプリケーションを作るために、いくつかの新しいモジュールを追加することができます。
そのマイクロサービスアーキテクチャのプログラム、それを再利用し、既存のコードに簡単に、ほとんど変化なし。
[別の]開発モデル
それはプログラムがあるので、あなたがプロジェクトの品質には問題ないことを確認するために迅速にタスクを完了するのに十分なマンパワーを持って取り組まなければならない場合、開発モデルは、単一のサービスのシステムアーキテクチャは、我々は唯一、開発する一つの技術を選択することができます良い相乗効果が働きます。
マイクロサービスアーキテクチャ、各サービスは比較的独立しているため、開発者はあなたが開発に異なる技術を使用することができ、特別なサービスをキャプチャすることができます。もちろん、サービスのために、それが唯一の技術でできます。このモデルは、互いに独立して動作する複数の同時のプログラマを実装することができます。各プログラマはそれだけでサービスの品質に責任にする必要があります。
要約するので、アーキテクチャ選択の種類に関して、いくつかの要因に依存します。
どのようにあなたのプロジェクトの大きさはどうですか？
プロジェクトの進捗状況は非常に急いではないでしょうか？
どのくらいの時間を行うには、このプロジェクトを望んでいましたか？
予算プロジェクトどのくらいのお金？
どのレベルの開発者に？
スケーラビリティは、どのように後半要件ですか？