Dockerベースのマイクロサービスアーキテクチャに基づいてローカル開発環境を適切に作成するにはどうすればよいですか？
そのため、現在私が作業しているのは、できるだけ本番環境に近い本番環境を模倣することです。私たちのマイクロサービス（API、リスナー、データストア）は、他のものとは異なる責任（データモデルまで）を実行する場合、独自のコンテナに値する方法で編成されています。
現在、私たちのローカル開発環境では、Docker Composeファイルのメッシュと、これらすべてを絡み合わせるNodeJSコードがありますが、20％の時間しか機能しないため、持続不可能であることが証明されています。 MongoDB/MySQLなどのデータベースシステムが下位層でこれらの問題を解決したことが証明されたため、データストアを1つのデータベースに圧縮するために入力を受け入れることができた（モデルごとの）各APIマイクロサービス。
現在、コンテナは約48のインスタンスに出てきます。これは私にとってはクレイジーですが、これは新しい方法として説明されています。これらのコンテナはランダムにクラッシュします（一部にはメモリ制限があるため、おそらくこれが原因です）。開発環境を複雑な本番環境に適合させずに生産性を維持する方法はありますか？
マイクロサービスは互いに比較的独立している必要があります。開発者のテスト中は、作業しているものと、通常はストレージ、メッセージング、または認証に関連する2つまたは3つの他のものだけを開始できる必要があります。できない場合は、アーキテクチャの改善に取り組む必要があります。
アプリケーション全体が開発者のマシンに適切に適合しない場合は、開発者の統合テスト用に別のクラスターを用意してください。多くの組織では、運用クラウドプロバイダーに余分な時間を費やしているだけですが、OpenStackなどを使用して社内クラスターを構築することもできます。
このクラスターは、すべての開発者が100％の時間でそれを必要としないため、過剰にスケジュールされる可能性があります。私は、マイクロサービス開発の約85％を単体テストだけで、約10％を自分のマシンの単一マイクロサービス環境で、残りの5％を共有クラスターで行っていると思います。
また、より優れた監視とオーケストレーションに投資したいと考えているため、マイクロサービスがクラッシュする理由を正確に把握し、マイクロサービスがクラッシュしたときに自動的に再起動させることができます。おそらく、PrometheusやKubernetesのようなものでしょう。 Kubernetesは、利用可能なノードが処理できるよりも多くのリソースを必要とする場合、そもそもマイクロサービスのスケジュールを拒否します。