マイクロサービスとは何ですか？
このためのマイクロサービス、そのためのマイクロサービスですが、単純な人にマイクロサービスとは何かを説明してください。私は、理論的な背景がほとんどない単純なプログラマーです。しかし、私が行うことを実行するために用語マイクロサービスは必要ありません。誰かがマイクロサービスとは何か簡単な言葉で説明してくれませんか？ Amazon AWS =マイクロサービス？
私はこれを読みます： https://en.wikipedia.org/wiki/Microservices しかし、どうやら私はこれが何であるかを理解するには愚かです。
私自身のマイクロサービス、うまくいけば単純な言葉
モノリス
従来、Webアプリケーションは大きいものでした。サーバー上で実行され、HTML、XML、またはJSONの形式でリクエストに応答するソフトウェアを1つ作成します。 Webアプリケーションで何か新しいことを実行したい場合は、その機能を既存のアプリケーションに追加します。このような大きなシステムは「モノリシック」と呼ばれます（モノリスは非常に大きな岩です）。
モノリスは、通常、時間の経過とともにサイズと複雑さが大きくなるため、問題があります。これは、チームで何かを開発するときの問題です。開発者はシステムに新しいコードを追加しており、既存のコードを変更または再利用することはできません。これは、コード間に多くの依存関係があるためです。また、どこかで使用される可能性があるため、古いコードを削除することをあまりにも恐れています。
そのようなコードをクライアントに配信するとき。それをインターネット上に置くことによって、私たちはそれを「配備」と呼びます。大きなシステム内には、壊れる可能性のあるものがたくさんあるため、デプロイとデプロイ後の通常のテストは困難です。何が問題になっており、誰が修正すべきかを見つけることは非常に困難であり、人々がすべてを知る必要があります。
もう1つの欠点はスケーラビリティです。つまり、「より多くのユーザーに同時にサービスを提供するにはどうすればよいのか」ということです。単一のWebサーバーコンピューターは、並行してアクセスする特定の量のユーザーしか処理できません。そのコンピューターをより良いハードウェアにアップグレードすると、より多くのユーザーにサービスを提供できますが、すぐにハードウェアで可能なことの境界にぶつかることになります。このアップグレードは垂直スケーリングと呼ばれます。 Webアプリケーションを2つ以上のサーバーに配置して、より多くのユーザーを処理できるようにすることもできます。これは水平スケーリングと呼ばれます。モノリシックアプリケーションは従来、垂直スケーリングのみを考慮して作成されています。
マイクロサービス
大きなアプリケーションでワークフローを簡素化するために、ワークフローを小さな部分に分割できます。各部分は1つの特定の目的を果たします。それを「（ウェブ）サービス」と呼んでいます。これらのWebサービスは非常に柔軟に使用できます。サーバー部分またはクライアント部分で、既存のモノリシックアプリケーション内から使用できます。他のWebサービスを使用するWebサービスを持つこともできます。
単一のWebサービスに分割すると、アプリケーションを疎結合できます。これは、サービスのユーザーとして、サービスが稼働中であり、利用可能であり、機能していることだけに依存していることを意味します。依存関係、コンパイル、展開、テストを行う必要がなくなりました。
その責任を別の開発者やチームに与えることができます。ソースコードからアクセスしないため、Webサービスを壊すことはできません。彼らは異なるプログラミング言語を使用することもでき、あなたはまだ彼らのサービスを利用することができます。
この独立性は、共通のフォーマットと共通の protocols を使用することを決定することによって可能になります（プロトコルは通信の方法です）。 Webサービスの最も一般的な形式は [〜＃〜] json [〜＃〜] および [〜＃〜] xml [〜＃〜] です。最も使用されているプロトコルは [〜＃〜] http [〜＃〜] です。これは、プロトコルがシンプルで、既存のすべてのソフトウェアによって十分にサポートされており、ブラウザーもそれを使用しているためです。
「マイクロサービス」の「マイクロ」という言葉は、これらのWebサービスをできるだけ小さくするというアイデアを強調しています。より複雑なサービスが必要な場合は、通常、1つ以上の他のサービスに依存する新しいサービスを作成することをお勧めします。
いつ使用するのですか？
次の場合はマイクロサービスを使用します。
- 多くの人が長期的にシステムで作業することを期待します（疎結合）
- 数百万の同時ユーザーにスケールする必要がある（水平方向にスケール）
- 冗長性（モジュール化）を備えた高可用性システムが必要
モノリシックアプリケーションは古いものでも古くなったものでもありません。特定のシナリオでは、マイクロサービスよりも多くの利点があります。次の場合に使用します。
- システムは一人または小さなチーム（単一のコードベース）によって開発されます
- システムは、非常にスケーラブルである必要はありません。それは、企業内または限られた顧客のサークル内で数百または数千の人々によってのみ使用されます（垂直方向にスケーリングされます）
- 理解、保守、展開、監視が簡単なシンプルなアーキテクチャ（シンプルなインフラストラクチャ）が必要
マイクロサービスで構築されたシステムの例
ユーザーが仮想ポストカードを作成できるアプリケーションがあるとします。
以下は、モノリシックスタイルで構築されたこのようなアプリケーションの必須コンポーネントを示す図です。 
（ほとんどの場合、ブラウザーを使用してアプリケーション内で生成されたHTMLをレンダリングするため、ユーザーインターフェイスコンポーネントはシステムの境界を越えています。）
これは、マイクロサービスアーキテクチャを使用してこのようなアプリケーションを実現する方法です。 
各コンポーネントが独立していて、UIからのみアドレス指定されることに注意してください。
詳細に：
- HTML、CSS、JavaScriptのみで構成される薄い静的Webページ
- 寸法と意図を含むカードテンプレートのリストを提供するマイクロサービスカードライブラリ。
- カードテンプレート名を指定すると、カードの小さなプレビューを提供するマイクロサービスサムネイル。
- テンプレートとテキストが入力されることを期待するマイクロサービスrenderer。次に、カードイメージをレンダリングし、それを返します。
配線方法：
- Webページには、カードライブラリとレンダラーへのURLがあります。ユーザーのブラウザが、JavaScriptコードによって発行されたこれらのサービスを呼び出しています。
- ライブラリはサムネイルを使用して、サムネイルを含むカードのリストを返します
- ユーザーがテンプレートを選択すると、ブラウザはそのテンプレートをユーザー入力とともにレンダラーに送信し、ブラウザは返された画像を表示します。
このアプローチでは、最終的に3つのマイクロサービスと共有Web GUIができます。他のサービスに手を加えることなく、各サービスを独自の開発者またはチームに提供し、個別にテストし、いつでもデプロイして、まったく新しいものと交換することができます。同時に、サービスがすべて相互に互換性があることを確認する必要があります。これには、APIバージョン管理、動的サービス検出（たとえば、他のすべてのサービスに接続する追加の高可用性サービス）、およびその他のより高度な手法が必要になる場合があります。
共有UIは1つのアプローチにすぎないことに注意してください（もっとも一般的です）。また、サービスごとに1つのUIを持つことも、複数のバックエンドサービスに異なるフロントエンドを提供するための専用のサービスを持つこともできます。また、データストア（データベース、キューなど）について、また複数のサービスで使用する必要があるのか、各サービスがデータを所有するのかについて、多くの議論と論争があります。これは、パラダイムがかなり大まかに定義されている場所です。
マイクロサービスに適切な言葉は、適切なサイズのサービスです。マイクロサービスの範囲とサイズは以下に基づく必要があります
- SRP-マイクロサービスには、変更の単一の理由が必要です。それは一つのことをし、うまくやるべきです。
- ビジネス機能-本質的に比較的自律的であり、他の機能との相互作用を最小限に抑えてチームが実行できるビジネス機能を表す必要があります
- BC/UL BCおよびUL に基づく必要があります。これらはDDDの概念です。詳細はリンク先をご覧ください。