マイクロサービス-独立してデプロイおよびアップグレードするとはどういう意味ですか？
この記事 で言及されています（私の強調）：
...マイクロサービスのアーキテクチャスタイルは、単一のアプリケーションを小さなサービスのスイートとして開発するアプローチであり、それぞれが独自のプロセスで実行され、軽量のメカニズム（多くの場合、HTTPリソースAPI）と通信します。これらのサービスは、ビジネス機能を中心に構築されており、完全に自動化された展開機構によって独立して展開可能です。
私の理解では、マイクロサービス1がビルド時のマイクロサービス2に依存している場合、それはマイクロサービスではありません。
マイクロサービス1とマイクロサービス2を考慮すると、マイクロサービス2の次のバージョンに、特定のHTTP API呼び出しでマイクロサービス1の次のバージョンによって消費される新機能がある場合、独立してアップグレードされるマイクロサービス1は何を意味しますか？マイクロサービス1の次のバージョンには、マイクロサービス2の次のバージョンへの依存関係（Javaでのmaven deploy（not build）依存関係）があるためです。
この特性はモノリスとは対照的であり、2つのサービスを連続してデプロイする必要がないことを意味します。
モノリスの場合、1つの部分に変更をデプロイする場合は、モノリス全体をデプロイする必要があります。これは、本質的に3つの問題があることを意味します。
変更をデプロイする準備ができているが、モノリスの別の部分に取り組んでいる他のチームが機能の1つに大きな変更を加えており、それらのコードを現在の状態でデプロイできないとします。そのため、変更を本番環境にデプロイすることはできません今すぐ。
その場合、リリースにはチーム間のコミュニケーションが必要です。クロスチームコミュニケーションは、マイクロサービスが回避しようとするものです。
モノリスの展開はかなり複雑です。複雑さが増すと、本番環境で何かを壊すリスクが高くなります。つまり、チームはデプロイの頻度を減らす傾向があります。
独立したサービスの場合、他のチームと通信することなく、単一のサービスを今すぐ展開できます。彼らは大規模なリファクタリングを行っている場合もあれば、本番環境にいくつかの変更をデプロイしている場合もあれば、次の4週間休暇を取る場合もあります。サービスは独立してデプロイ可能なので、あなたはそれを気にしません。
これらのサービスは、さまざまな企業によって開発されていると考えてください。たとえば、Amazon AWSを使用できます。 Amazonが新機能をリリースするとき、（1）それを行うための許可を求めません、（2）それと同時にアプリケーションの新しいバージョンをリリースすることを強制しません新しい機能をリリースします。 Amazonはリリースをそのペースで行い、あなたはあなたのペースでリリースします。
注：この回答は、Eberhard WolffによるMicroservicesに基づいています。詳細に興味がある場合は、本を読むことに興味があるかもしれません。
完全に独立した展開とは、いずれかのサービスを任意の順序でアップグレードして、稼働状態を維持できることを意味します。明らかに、依存関係をまったく持たないことが理想的ですが、やや実用的ではありません。マイクロサービス間に依存関係がある場合でも、それらを個別にデプロイできます。
あなたの例では、microservice 2は下位互換性を維持していれば、いつでもアップグレードできます。
マイクロサービス1は、マイクロサービス2の互換性をチェックし、新しい機能を無効にするか、新しい依存関係がまだ利用できない場合は適切にフォールバックすることを条件に、いつでもアップグレードできます。
その2番目の方法は少し…不要なようです。面倒を省いて、マイクロサービス2を最初にアップグレードしないのはなぜですか？それは通常私がやろうとしていることだと認めますが、最初にマイクロサービス1をアップグレードすることには、いくつかの予期しない利点があります。
まず第一に、マイクロサービス2に問題が発生し、ロールバックする必要がある場合のエラー処理とトラブルシューティングが改善されます。第二に、その新しいインターフェースがどのように見えるべきかについてより良い考えを持っているのはしばしばクライアントです。最初にクライアントを実行すると、インターフェイスを正しく設定することの前後を最小限にできる場合があることを発見しました。 3番目に、缶詰またはプロトタイプのマイクロサービス2を備えたテストシステムにデプロイして、マイクロサービス2の新機能の開発にリソースを投入しすぎる前に早期のフィードバックを得ることができます。
つまり、スイッチを切り替えて相互依存するすべてのサービスを同時にアップグレードしなければならない状況に陥らないようにするために、余分な労力を費やしています。これらのビッグバンのアップグレードにはリスクが伴います。
私にとって、これは重要です。小さなバッチで変更をリリースし、統合回帰をはるかに簡単に管理できるからです。
モノリスを使用すると、いくつかの機能領域に変更を加え、すべてをビルドしてデプロイし、うまくいくことを願っています。独立したサービスを使用すると、小さなチャンクを展開して、引き続き適切に機能することを確認するのがはるかに簡単になります。
何かを処理するサービスAがあり、v1は現在本番環境にあるとします。すべてのコンシューマーはv1 APIを使用します。 v2 APIで更新された機能をいくつか紹介します。 v1 APIの下位互換性を維持し、v2 APIを「サイレント」にリリースできます。また、使用しているサービスのいずれも、知識や注意を必要としません。サービスAはv1およびv2 APIをサポートするようになり、他のコンシューマーはS1.v2呼び出しへの移行を開始できます。
複雑なモノリスでは、これは非常に困難で危険なプロセスです。特に、エンタープライズ設定の共有コードベースで複数の異なるアプリケーションを実行している場合はそうです。マイクロサービスは多くの分野でかなり多くの規律を必要としましたが、「大きなシステム変更」を小さな部分で行うことができ、複雑なモノリス更新を本当の意味にするすべての外部要因なしに行うことができます。
コードのリファクタリングにたとえることができます...コードをリファクタリングするときは、一度に細かく分割し、それらが機能することを確認してから、パッケージ化します。マイクロサービスの実用的な使い方も似ていますが、コンポーネントレベルで代わりに何も壊さずにさまざまなコンポーネントに小さな更新を加えることができ、すべてが確実にうまく機能している場合は、古いAPIとその実装を廃止できます。
外部知識を必要としない、サービスチームが完全にサービスを所有している、サービス間の依存関係がないなどのよく知られた利点に加えて、独立性のために小さな段階で複雑なリリースを実行できるこの機能は、作業の重要な実用的な利点ですマイクロサービスアーキテクチャ。