マイクロサービスのコンセプトは、いくつかの時間のために普及しているが、任意の技術は、その長所と短所がありますが。悪役を再生しながら、まともなとミクロのサービスを見た後、ThoughtFocusテクニカルアーキテクトAibinジョン（Ebinジョン）は、最高のデフォルトのサービスの建築家やデザイナーとしてマイクロアーキテクチャを起こしやすい場合、ドキュメントは、開発を提案発行しました以下の質問を自問してください。
1.お使いのアプリケーションに十分な大きさはマイクロサービスに細分化されますか？
マイクロサービスは、スモールサービスの多くは、その職務を遂行され、理想的なケースでは、各サービス自体は完全なアプリケーションです。
人材とコスト計算の面でマイクロサービスは、最小限のリソースを必要とするので、それはそれは軽量マイクロサービスであっても、高いコストを必要とします。そして、あなたのコードベースは、将来的に成長され、コードベース自体は、新しいフィールドを追加することができます。しかし、あなたは常に忘れてはならない：あなたがしきい値の近くにあるときは、うまく設計されたコードベースは、常にマイクロサービスに切り替えることができます。
2.あなたは本当にアプリケーションのさまざまなコンポーネントを拡張する必要がありますか？
仮に。製品の所有者は、あなたは何千人もの人組織のニーズを満たすためにアプリケーションを人事管理システム（HRMS）を使用するアイデアを提案しました。マイクロサービスアーキテクチャ：技術の愛好家として、あなたはすぐに解決策を持っています。
マイクロサービスアーキテクチャを使用することの主な利点の一つは、簡単にスケーラブルな単一成分です。あなたは個別に拡張する必要があるが、あなたのアプリケーションが実際にそれを行うために必要なアプリケーションコンポーネントの多数を見つけることができますか？
3.あなたの取引は、多くのサービス間で？
さて、これは作るために最も困難な戦略的選択の一つであってもよいです。全体構造の複数のサービス負担間取引。クロスサービストランザクション手段を解決するには、次のサービス間のインターロックは追跡不可能な行き詰まりのシリーズにつながる、と保健サービス、時には競合状態エンジニアの健康を危険にさらすだろう。
定義上、RESTサービスはステートレスです。彼らは、サービス事業に限定されるものではなく、境界に参加してはなりません。高パフォーマンスの環境では、二相は、2PCが不要トラブルでコミット。SAGAモードのみ、あなたが準備ができていない複雑さの別の層を追加します。
分散データ管理とマイクロサービングスティックので、それが最終的な整合性の問題をもたらします。モノリシックアプリケーションの場合は、単一のトランザクションで一緒に原料の束を更新することができます。マイクロサービスは不人気更新に多くのリソース、および分散トランザクションを必要とする（これは正当な理由で）。そのため、開発者は認識して一貫している必要があります。
4.サービスとの間の定期的な接触が必要なのでしょうか？
従来のモノリシックなサービスでは、各サービスインスタンスミクロは、システム内のモジュールによって表されます。ゼロへのメモリレイテンシの近くにあるモジュール間のリンク。メモリトランザクションによる接触がネットワークを介して中継コマンドになっていることをマイクロサービス手段の導入。
そこ実証済みのソリューションの数がありますが、それらは、すべての価格を持っている：遅延が。メモリトランザクションの代わりに、ネットワークベースのコンタクトからナノ秒からマイクロ秒の遅延となります。お互いに連絡することを、ネットワークを介して三つの異なるサービスを想像してみてください。各サービスコールは、（負荷の下では珍しいことではありません）100マイクロ秒かかると仮定すると、最終的には、ネットワーク上でのみ300マイクロ秒の費用がかかります。
アプリケーションの性質にしながら、しっかりとコンポーネントやサービスと統合されています。通信層は、アプリケーションの悲惨な結果を処理し、リアルタイムのデータを追加している可能性があります。
：マイクロ・サービスを使用する前に、これらの4つの質問に加えて、のようなその他の欠点のいくつかを検討する必要があります
1.複雑
けれども、もともと複雑さを軽減するために、小さなコンポーネントに分割することによってマイクロサービスアプリケーションに設計されていますが、アーキテクチャ自体が展開し、維持することは非常に複雑です。
2.物流コスト
マイクロサービスは、モジュール性と分散システムであるが、同じ分布が実際に支払うの価格です。あなたのモノリシックサービスは、選択した大規模な仮想マシンまたはコンテナに配備されます。それはマイクロサービスである場合でも、複数の仮想マシンまたはコンテナに加えて、サービスは独立した理想的な環境に配備する必要があります。もちろん、サービスは小さいかもしれないが、あなたは、総コストを計算することができます。
3.適応DevOpsチーム
あなたは中小企業のメンバーである場合、これは、有益または有害であり、DevOpsチームチームの設立は、良いよりも害になります。しかし、一つのことには、特定のDevOpsチームのチームが存在しない場合、あなたはマイクロサービスを維持し、監視することができません特定の秋です。
4.統合密接に
一部のアプリケーションは、自然に密結合されています。災害につながる「適応」の枠組みからそれらを区別します。
5.経験不足します
それは、新しい技術の両方の重要な考慮事項のために使用しています。それは害の抽象定義では、マイクロサービスに来るときしかし、特に発生します。
6.紛らわしいデータコントラクト
データ契約や契約の非常に異なるチーム間で共有データへのチームの設定で。あなたはマイクロサービスと接触している、あなたのチームは、チームメンバーが同じプログラミング言語を使用はもちろんのこと、同じ領域に配置することはできません。データコントラクトは、特定の要件にあなたの時間と空間を開発する費用がかかります。
7.デバッグ
各サービスは、より多くのサービスがより多くのログファイルを意味し、検討するために、ログファイルの独自のセットを持っています。
これらはマイクロサービスの前に熟考するいくつかの質問です、あなたはコメントエリアで独自のものを残すために歓迎されています