High-speed Service Framework (HSF) では、Groovy スクリプトを使用してサービスルーティングルールを構成できます。
ルーティングルールの構成方法の詳細については、「Routing Rule Wiki」をご参照ください。ルーティングルールを構成した後、ルーティングルールが有効にならない場合があります。このような障害は通常、呼び出しが予期されたインスタンスにルーティングされない場合に発生します。ただし、この場合、障害は、不適切なルーティングルールや、ルーティングルール内の IP アドレスへのサービス提供の失敗など、他の要因によって発生する可能性があります。
ルーティングルールの障害のトラブルシューティング方法を以下に示します。手順は次のとおりです。
1. コンシューマーがローカルコールまたはジェネリックコールを使用しているかどうかを確認する
コンシューマーがローカルコールまたはジェネリックコールを使用してサービスを消費する場合、ルーティングルールロジックは使用されず、当然、ルーティングルールは有効になりません。
- ローカルコールモードでは、プロセスはサービスプロバイダーとサービスコンシューマーの両方です。デフォルトでは、HSF はリモートプロシージャコール (RPC) ではなく、プロセス内の Java コール、つまりローカルコールを使用します。この場合、ルーティングルールロジックは使用されません。
- ジェネリックコールモードでは、サービスのセカンドパーティパッケージに依存せずに、GenericService を呼び出してサービスを記述することにより、サービスが直接消費されます。この場合、HSF にはサービスクラスがなく、ルーティングルール内のサービスロジックを実行できないため、ルーティングルールロジックは使用されません。
HSFOPS のサービステスト機能はジェネリックコールを使用するため、ルーティングルールは有効になりません。
2. コンシューマーがルーティングルールを受信するかどうかを確認する
HSF ルーティングルールは Diamond に保存されます。コンシューマーが起動すると、サービスの対応するルーティングルールが Diamond からプルされます。
hsf.log (デフォルトパスは ${user.home}/logs/hsf/hsf-config.log (HSF 2.2 の場合) または ${user.home}/logs/hsf/hsf.log (HSF 2.1 の場合)) で、サービス名を検索します。ルーティングルールが正しく受信された場合は、次のようなログが存在します。
01 2015-10-09 13:20:06.402 WARN [com.taobao.diamond.client.Worker.default:t.hsf] [] [] [] [Metadata Component] Received rule for service [com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily]: Groovy_v200907@package hqm.test.groovy
// ルーティングルールマップを返します
public class RoutingRule{
Map<String, List<String>> routingRuleMap(){
return [
"G1":["100.69.161.201:*"]
]
}
// インターフェースルーティングルールを返します
String interfaceRoutingRule(){
return "G1";
}
}
ルーティングルールが受信されない場合は、次の項目を確認してください。
- ルーティングルール名がサービス名に対応しているかどうかを確認します。詳細については、「Routing Rule Wiki」をご参照ください。
- Diamond で構成されているルーティングルールの環境がコンシューマーの環境と一致しているかどうかを確認します。
3. ルーティングルールが正しく解析されているかどうかを確認する
hsf.log で、サービス名を検索します。HSF ルーティングルールが正しく解析された場合は、次のようなログが存在します。
01 2015-10-09 13:20:06.761 INFO [com.taobao.diamond.client.Worker.default:t.hsf] [] [] [] Parse route rule successed, RouteRule:com.taobao.hsf.route.service.RouteRule@4441ec5a{
keyedRules={G1=[100.69.161.201:*]},
interfaceRule=G1,
methodRule={},
argsRule={}
}
HSF ルーティングルールの解析に失敗した場合は、エラーメッセージが表示されます。ログと Routing Rule Wiki を参照して、ルーティングルールを確認してください。
4. ルーティングルールが正しいかどうかを確認する
ルーティングルールが正しく受信および解析された場合は、次の項目を順番に確認してください。
ルートの宛先インスタンスが実際にこのサービスを提供しているかどうかを確認します。
対応する環境の HSF サービスガバナンスプラットフォームでサービスをクエリし、ルートの宛先 IP アドレスがプロバイダーリストにあるかどうかを確認します。
- 以前のバージョンの HSF では、ルーティングルールで指定された IP アドレスがサービスを提供していない場合、IP アドレスが見つからないことを示すエラーメッセージが返されます。
HSF 2.1.0.7 以降では、ルーティングルールで指定された IP アドレスがサービスを提供していない場合、システムは空の保護を有効にするように促します。この場合、ルーティングルールは有効にならず、HSF は Config Server に保存されているプロバイダーリストからサービスを呼び出すために使用可能な IP アドレスをコンシューマーに選択します。メソッドベースのルートを使用する場合、計算されたアドレスが空の場合は、
hsf.logでサービス名を検索します。次のようなログが存在します。最後から 2 行目のEmptyProtection trigger [true]は、空の保護が有効になっていることを示します。01 2015-10-09 13:20:06.761 WARN [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [Address Component] isEmptyProtection: true 01 2015-10-09 13:20:06.761 WARN [HSF-AddressAndRule-1-thread-1:t.hsf] [] [] [] [Address Component] isEmptyProtection: true 01 2015-10-09 13:20:06.761 WARN [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [Address Component] newAllAvailableAddresses is empty for service : com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily 01 2015-10-09 13:20:06.761 INFO [HSF-AddressAndRule-2-thread-1:t.hsf] [] [] [] [AddressBucket-com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily] Refresh: all amount [0], available amount [0], local preferred switch [off].Unit=UNIT 01 2015-10-09 13:20:06.761 INFO [HSF-AddressAndRule-1-thread-1:t.hsf] [] [] [] [Address Component] route result com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily, addresses remain[1], EmptyProtection triggered [true] 01 2015-10-09 13:20:06.762 INFO [HSF-AddressAndRule-1-thread-1:t.hsf] [] [] [] [AddressBucket-com.alibaba.dt.op.authclient.api.ResourceAPI:1.0.0.daily] Refresh: all amount [1], available amount [1], local preferred switch [off].
ルーティングルールが正しいかどうかを確認します。
インターフェースルート、メソッドルート、およびパラメータールートが正しいかどうかを確認します。
アドレス計算の優先順位
同一インターネットデータセンター (IDC) アドレス計算ルールが使用されている場合、同一 IDC のアドレスはルーティングルールのアドレスよりも優先され、ルーティングルールのアドレスは同一 IDC のルールのアドレスセットで計算されます。
ルーティングルールは、インターフェースルーティングルール、メソッドルーティングルール、およびパラメータールーティングルールに分類され、優先順位は降順です。特定のレベルのルーティングルールが存在しない場合、返されるキーは null または
RoutingRuleMapに対応する値が含まれていない場合、このレベルにはルーティングアドレスの制限がなく、上位レベルのすべてのアドレスが使用されます。計算プロセス全体は次のとおりです。
- インターフェースレベルのルーティングルール (正規表現) の最終アドレスリストは、同一 IDC ルールの結果アドレスのリストと交差します。
- メソッドレベルのルーティングルール (正規表現) の最終アドレスリストは、インターフェースレベルのルーティングルールのアドレスリストと交差します。
- パラメーターレベルのルーティングルール (正規表現) の最終アドレスリストは、メソッドレベルのルーティングルールのアドレスリストと交差します。
5. ルーティングルールが実際に呼び出されているかどうかを確認する
上記のトラブルシューティング後も問題が解決しない場合は、ルーティングルールで指定されたサービスまたはメソッドが実際に呼び出されているかどうかを確認します。対応するメソッドが呼び出されない場合、宛先インスタンスで呼び出しログを見つけることができません。
ルーティングルールで System.out.println() を使用してログを出力できます。返されるコンテンツはクロージャである必要があることに注意してください。次に例を示します。
ovy_v200907@package hqm.test.groovy
// ルーティングルールクラス
public class RoutingRule {
// ルーティングルールマップを返します
Map<String, List<String>> routingRuleMap() {
return [
"BSeller_address_filter_Key":["10.177.75.54:*"],
"ASeller_address_filter_Key":["10.97.94.33:*"]
]
}
// 引数ルーティングルール
Object argsRoutingRule(String methodName, String[] paramTypeStrs) {
if (methodName.startsWith("checkUrlPermission")) {
System.out.println("checkUrlPermissionメソッドと一致します。");
return {
Object[] args ->
if(args[1] % 2 == 1 ) {
System.out.println("BSeller_address_filter_Keyにルーティングします");
return "BSeller_address_filter_Key.";
} else {
System.out.println("ASeller_address_filter_Keyにルーティングします");
return "ASeller_address_filter_Key." ;
}
}
}
}
}