マイクロサービスのデザイン・ノート（10） - バージョン管理

インタフェースが変更されないことが難しいサービス、どのように我々はこの変化に対応できますか？ここではいくつかの対処戦略は以下のとおりです。

1つの読みフォールトトレランス

最善の戦略は、破壊的なインターフェイスを変更することはありません。しかし、これはほとんど不可能です。クライアント・アプリケーションは、（また、堅牢性原理として知られている）ポステルの法則インターフェースが発生し、サーバーの変化に対応するための柔軟性が必要があります。強固な堅牢、堅牢で強力な意味で音訳、です。これは、異常や危険な状態にあるシステムの実行可能性を指します。例えば、入力エラー、ディスク障害、ネットワークの過負荷や意図的な攻撃の場合におけるコンピュータソフトウェア、クラッシュしていない、クラッシュすることはできません、ソフトウェアの堅牢性です。クライアントは、彼が厳格であることを送信したもので、ある厳格な出口である必要がありますが、受信の内容は寛容でなければならないでしょう。

次のようにクライアントがサーバーへの基本的な情報へのクライアントのリターンのクライアントIDを送信し、サーバー、応答メッセージ：メールサーバーを仮定します。

<customer>
    <firstname>Sam</firstname>
    <lastname>Newman</lastname>
    <email>sam@magpiebraincom</email>
    <telephoneNumber>555- 1234 -5678</telephoneNumber>
</customer>

その後、サーバーは、顧客の電話番号を送信する必要はありませんので、これは、メールサービスだと思います。が、また新しいノードに顧客関連の名前を統合したいです。再構成された応答メッセージは次の通り：

<customer>
    <naming>
        <firstname>Sam</firstname>
        <lastname>Newman</lastname>
    </naming>
    <email>sam@magpiebraincom</email>
</customer>

クライアントが直接バインドされたフィールドをバインドするための技術を使用している場合、エラーは、堅牢で十分ではないが発生します。ここでは、クライアントは、マーティン・ファウラーが読み言われますが、フォールトトレランスを実現したいデータを取得するために、XPathの技術を使用することができます。

XPathは、XMLパスXML文書の位置の部分を決定するための言語である言語（XML PathLanguage）、です。

シナリオ要求/応答では、フォールトトレランスは、原則として、サーバーの変更、修正最小化クライアントを読んで実現することができます。

2早期発見

サーバーの更新サービスは、クライアントが問題の書かれた、早期発見の前に再び完全なテストケースを実行する必要があります。

セマンティックの3バージョン

クライアントは、バージョン番号でサービスを表示することができ、あなたがそれらと統合するかどうかを知ることができますバージョンセマンティック手段。バージョン形式：主版本号.次版本号.修订号バージョン番号はインクリメントされたルールとして、以下のとおりです。

メジャーバージョン番号：APIが下方互換性がありません、修正しました。
マイナーバージョン番号は：機能、および後方互換性を追加します。
リビジョン番号：問題を修正し、下位互換性。
バージョン番号とコンパイラ第1のメタデータのバージョンが追加されてもよい「メジャーバージョン番号。マイナーバージョン番号。リビジョン番号を、」後者を、拡張機能として。

また、下位互換性（下位互換性）として知られている下位互換性（下位互換性）。新しいバージョンに更新されたプログラムやライブラリの後、プログラムの古いバージョンで作成した文書やシステムがまだプログラム上のライブラリの古いバージョンに基づいて、通常の操作または使用、または開発することができ、まだ機能が正しくケースをコンパイルすることができます。つまり、古いプログラムがまだコンパイルしに上で実行します。

4つのインターフェースが混在

インターフェイスにプライマリサーバた後生まれ変わっに再設計されましたが、元のインターフェイスを変更しなかったが、新しいインターフェイスの実現、そして新旧のインターフェイスが存在します。

このように、我々はできるだけ早くマイクロサービスの新バージョンをリリースすることができます。古いものと新しいインターフェイスが存在するため、クライアントは、新しいインターフェースへの移行を移行するための時間を持っています。すべてのクライアントは、もはや古いインタフェースを使用すると、あなたは、このインターフェイスから削除することはできません。

これは、実際には古いから新しいインターフェイスへの円滑な移行にクライアント・インターフェースを可能にする拡張/収縮モデルです。まず、古いものと新しいインターフェイスのためのサービス機能、およびサポートを拡張しました。などの新しいインターフェイスに、すべてのクライアントの移行後、その後、APIから古いインターフェースを除去することができるサービスを契約することもできます。

システムの相互作用のモデルとして使用するHTTPのために、私たちは要求にバージョン情報を追加することができ、それはまたのような、URIで添加することができるvl/customer/とv2/customer/。

deniro_li

公開された603元の記事・ウォンの賞賛670 ・ビュー880 000 +

彼のメッセージボードの懸念