4

SOA の原則の 1 つは、「サービスは自律的である」です。私は2つのサービスを持っています。サービス A はサービス B に依存します。サービス A は、サービス B が稼働していない限り、クライアントにサービスを提供できません。ここで教義に違反しますか？

または、自律が「分離」を意味する必要がある場合、フェイルセーフがある場合 (プライマリ インスタンスがダウンしている場合に接続されている別の場所で実行されているサービス B の別のインスタンスなど)、信条を満たしますか? これで可用性の要件は満たされるかもしれませんが、依存関係をどのように減らすことができるかはわかりません。はい、フェールセーフはサードパーティのサービス C である可能性もあります。この場合、自律性を向上させます。

それとも、データの入出力用に明確に定義されたインターフェイスを備えた「fifedoms」としてサービスを設計する必要があることを意味するだけですか。ただし、一部の専門家は、依存関係を減らして自律性を維持するために、受け取ったこのデータを内部に保存する必要さえあると考えているようです...

サービスをメッセージ付きのコンポーネントとして扱うのは間違いですか? :)

考え？

4

2 に答える 2

7

SOA Tenetsに関するこの投稿を参照してください。自律型サービスのフラクタル星座も参照してください。

「サービスは、それらに依存する他のサービスやアプリケーションとは独立して展開、管理、およびバージョン管理する必要があります。」

自律性とは、孤立した、または完全に独立していることを意味するものではありません。

代わりに、2 つのサービスの "コンステレーション" が存在する場合があります。はい、お互いに依存しています。いいえ、B が移動またはアップグレードされても、A は壊れません。B の非インターフェース内部が変更されても、A は壊れません。

同様に、B の観点からすると、A の内部構造へのアップグレードは、B のインターフェースと内部構造の変更に波及しません。

API は独立して進化します。スキーマ、メッセージ、および実装は独立しています。彼らはたまたまお互いを参照しています。

「サービス B が稼働していない限り、サービス A はクライアントにサービスを提供できません」 -- 心配しないでください。サービス A もダウンしている場合、クライアントにサービスを提供できません。サービスダウンが問題です。それが B (A が依存している) または A であるかどうかは関係ありません。依存関係は、A または B が信頼できるか、または利用可能であるとは関係ありません。

はい、サービスには明確に定義された独立したインターフェースがあります。Aの実装は B に依存しますが、インターフェイスは依存しません。

編集。

「一部の専門家は、依存を減らして自律性を維持するために、受け取ったデータを内部に保存する必要さえあると考えているようです...」

ポイントが見えません。A が B に依存し、B のアルゴリズムが変更された場合、B のデータの A のコピーは古いものになります。 依存関係とは、通常、ライブで機能し、トランザクションまでの関係を意味します。

問題は、B が遅く、A が遅くなり、A を使用するアプリケーションが遅くなる可能性があることです。それは残念です。しかし、だからといって、自律性のルールを破って、A が B からの古いデータの秘密のキャッシュを保持する必要はありません。

于 2008-10-31T18:54:04.850 に答える
1

あなたの自律性は、バックアップ サービスを持つことによってのみ改善されます。サービス B と C の両方がダウンした場合はどうなりますか? その後、サービスがダウンします。外部サービスからの結果をキャッシュすることで、自律性 (およびパフォーマンス) をさらに向上させることができます。そうすれば、B と C がダウンしても、キャッシュされた結果を使用して一部のクライアントにサービスを提供できます。ただし、サード パーティのサービスに依存している限り、100% の自律性を実現することはできません。

于 2008-10-31T18:41:01.833 に答える