（3）拡張性を高めるデザインパターン
サービスは1環境に1つとして独立させる： Service Instance per Host / VM / Container（1環境1サービス）
1つの環境（まずは物理的なマシン1台にそのままサービスを配置している状態をイメージしてください）に複数のサービスを載せることは、マイクロサービスの持つ多くのメリットを犠牲にします。それぞれのサービスが全体の実行環境に影響を及ぼすため、CPU使用状況の監視が難しくなったり、あるサービスのデプロイ（配置作業）が他のサービスに影響してしまいかねない、といった点がそれです。中でも課題となるのは、サービスごとのスケーリングができなくなるということでしょう。個々のサービスごとに適切なハードウェア構成をとることができず、システム全体に合わせた構成をとらざるを得なくなります。
補足
この1つの環境に複数サービスを載せるサービス配置はMultiple Service Instances per Host（=1つのマシンに複数のサービス）と呼ばれるパターンの1つであり、必ずしも取りえない構成というわけではありませんが、上記のような課題があるということをここでは理解してください
Service Instance per Host（=1つの環境に1つのサービスのみ配置）パターンを適用することで、サービス間の独立性が保たれ、上記の問題を解決できます。監視対象やデプロイは干渉しなくなり、スケーリングもそのサービスに特化した対応ができるようになるため、拡張性が向上します。
さらに、仮想マシン[11]技術を用いれば、リソースをより無駄なく活用できます（Service Instance per VM）。そして、仮想化をより小さい単位で実現するコンテナ型仮想化[12]技術なら、より一層リソース効率を高めることができるでしょう（Service Instance per Container）。
[11] 仮想マシン：1台の物理マシンに複数のOSを配置し、仮想的に複数のマシンとして扱えるようにする技術
[12] コンテナ型仮想化：仮想マシンと異なりOSは1つで、その上にコンテナと呼ばれるアプリケーションごとの個別領域を作る技術。仮想マシンに比べ処理負荷が少なく可搬性に優れるなどのメリットがある。Docker社が開発する同名のプラットフォームが代表格
各サービスへの接続に振り分けを挟むことで、自由な拡張を実現する：Service Registry（サービスレジストリ）とService Discovery（サービス検出）
各サービスはその接続先を特定できるIPアドレスなどの情報を持っており、呼び出し元はその値によって対象のサービスにアクセスします。しかし、その値を呼び出し元が直接保持してしまうと、接続先が変わるたびに呼び出し元の修正が必要になってしまいます。また、負荷分散のために同一のサービスを複数コピー配置して使用する場合や、さらには仮想化技術によりアクセス量にあわせて動的にその数を増減するケースもあるため、接続先の特定には柔軟性を持たせる必要があります。
そこで、各サービスの接続先の台帳（=Registry）を管理する機能を配置し、呼び出し元はそれを経由して相手先のサービスを検出（=Discovery）する手法がとられます。これにより、接続先情報が変わっても呼び出し元に影響することはなく、また各サービスの配置状況にあわせて適切な接続先が使用されることとなります。
