伝伝における仮想番号の実践と応用

1. はじめに

仮想番号は、インターネット技術に基づいた電話番号サービスです。電話番号をユーザーの携帯電話やその他の通信デバイスにバインドすることで、さまざまなデバイスで通話に応答したり発信したりすることが便利になり、ユーザーの番号のプライバシーが保護され、通話の内容と情報が記録されます。仮想番号の主な機能は次のとおりです。

プライバシー保護: 仮想番号は、ユーザーの実際の電話番号を隠すための中間番号として使用できます。ユーザーが電話番号を提供する必要がある場合、個人のプライバシーを保護するために代わりに仮想番号を使用できます。
柔軟性: 仮想番号はユーザーのニーズに応じて設定および調整できます。ユーザーはさまざまな市外局番や国際番号を選択できるため、電話番号の柔軟性と適応性が向上します。
汎用性: 仮想番号は、通話の受信や発信に使用できるだけでなく、さまざまな付加価値サービスも提供できます。たとえば、ユーザーはさまざまな通信ニーズに合わせて、通話転送、ボイスメール、SMS 転送などの機能を設定できます。
エンタープライズアプリケーション: 仮想番号は、エンタープライズ通信で広く使用されています。企業は仮想番号を使用して、カスタマーサービスホットラインやコールセンターなどを設置し、顧客満足度とビジネス効率を向上させるなど、顧客に優れたサービスエクスペリエンスを提供できます。

つまり、革新的な電話番号サービスとしての仮想番号は、ユーザーに、より柔軟で安全かつ便利な通信手段を提供します。個人および企業のコミュニケーションの両方において、幅広い応用シナリオがあります。

2. 実践と応用

店舗ビジネスのシナリオでは、店員/ユーザーは販売/購入などの情報相談のために番号をダイヤルする必要があります。双方の携帯電話番号は、サードパーティのサービスが提供する仮想番号を通じて結び付けられ、仮想番号を使用して通話に応答/発信することで、ユーザー番号のプライバシー保護の問題を効果的に解決し、店舗が店員の音声監視と管理データ分析を管理するのに役立ちます。

中古取引仮想番号バインディング図

2.1 名前の説明

A : ユーザーの携帯電話番号
X : 仮想番号/仲介アカウント
B : 店員の携帯電話番号
第三者: 仮想番号サービスプロバイダー
通信事業者：中国電信、中国聯通、中国移動、その他主要プラットフォーム

2.2 仮想アカウントのXBモード

XBモード：B（店員の携帯電話番号）をX（仮想番号）にバインドできることを意味します。それ以降の X (仮想番号) への通話は、現在の担当者 B の携帯電話番号で応答されます。

2.3 仮想番号のAXBモード

AXB モード: 仮想番号 X にバインドされたユーザーの携帯電話番号 A と店員の携帯電話番号 B を指します。A が X に電話をかけると、B は発信番号が X であることを認識します。同様に、B が X に電話をかけると、A は X が電話をかけてきた番号であることがわかります。

2.4 仮想番号通話フローチャート

コールフロー図

3. 第三者とのやりとりのバージョン進化

第三者とのやり取りの過程では、時間が経過し、ビジネスが発展し続けるにつれて、サービスプロバイダーと第三者間のやり取りのプロセスも常に改訂されます。以下では、履歴バージョンとサードパーティ間の相互作用におけるいくつかの問題について説明します。

3.1 初期バージョンのバインディングプロセス

写真

初期バージョンでは、基本的なバインドとアンバインドの操作のみを含む、インタラクションプロセスは比較的単純でした。通常の状況では、この単純なやり取りは問題になりません。ただし、オンラインで最も一般的な状況は、タイムアウト、タイムアウト、タイムアウトです。これは、サードパーティとのすべてのやり取りが HTTP に基づいており、サードパーティの応答時間が制御できないためです。応答が APP の要求時間を超えると、要求は融合され、要求は失敗します。

3.2 最新バージョンのインタラクションプロセス

サービスの信頼性を確保するため、最新バージョンでは以下の最適化措置が講じられています。

写真

最適化概念モデル図

タイムアウト処理メカニズム: バインディングステータスを照会するためのインターフェイスを提供し、APP は継続的にポーリングしてバインディングステータスを取得します。事前検証コードは同期され、サードパーティのバインド/アンバインドインターフェイスを使用して非同期処理が実行されます。

 //开启异步线程,执行重试方法,进行与第三方接口绑定。 ThreadUtil.executor.submit(() -> { try { log.info("act=AppOperationHandler type=retryBindXb_retryBindAxb_start"); pstnRetryService.retryBindXb(appOpnParam); } catch (Exception e) { log.error("act=AppOperationHandler type=retryBindXb_retryBindAxb_fail", e); } });

同時処理メカニズム: 同時処理の問題を回避するために、ロックは楽観的ロックに基づいて実装されます。バインディング状態は、操作の中間状態として追加されます。

 NOT_BIND(1, "未绑定"), BIND(2, "已绑定"), OPERATION(3, "操作中");

例外処理メカニズム: バインディングプロセス中に、サードパーティインターフェイスの呼び出しのタイムアウト、サーバーエラー例外などの例外をタイムリーにキャプチャして処理し、再試行を通じて操作の整合性と一貫性を確保します。再試行はアノテーション AOP インターセプションに基づいており、再試行は MQ メッセージを通じて実装されます。

 @Override @ZZMQRetry(errorHandler = "onErrorMsgPcBindXb", firstSyncCall = true) public void retryBindXb(PstnBindParam pstnBindParam) { //调用第三方接口进行绑定String bindId = bindVirtualNumber(pstnBindParam); Boolean executeResult = transactionTemplate.execute(status -> { try { //创建绑定记录pstnBindRecordService.insertBindRecord(bindId, pstnBindParam); //状态流转至已绑定return this.xbOpnStateToBind(pstnBindParam.getAssignVirtualNum()); } catch (Exception e) { status.setRollbackOnly(); return Boolean.FALSE; } }); if (Objects.isNull(executeResult) || !executeResult) { throw new BusinessException("修改状态异常进行重试"); } }

アラーム処理メカニズム: 重大な例外が発生した場合、または一定回数の再試行後に試行が失敗した場合は、アラームが送信されて通知されます。

 public void onErrorMsgPcBindXb(PstnBindParam param) { int retryCount = RetryContext.getRetryCount(); log.info("act=PcOperationHandler type=onErrorMsgPcBindXb retryCount={} ", retryCount); if (retryCount >= RETRY_MAX_NUM) { WxMsgUtil.sendMsg(GROUP, "绑定XB重试"+ retryCount + "次,仍未成功请排查,虚拟号:"+ param.getVirtualNum()); } }

上記の最適化措置により、インタラクションプロセスの安定性と信頼性が向上し、ビジネスパーティとサービスパーティ間の例外、タイムアウト、および不一致なバインド状態が削減され、仮想番号の正常な使用が保証され、システムの安定性と店舗スタッフのユーザーエクスペリエンスが向上します。

axb バインディングプロセス

上記の最適化された店員が電話をかけるプロセスでは、AXB バインディングにより、第三者と対話する際にタスクを処理するための新しいスレッドが開かれ、このスレッドでエラーや例外が発生した場合は、スレッドエントリに戻って再度実行されます。第三者との時間のかかるやり取りの問題は、非同期および周期的なクエリステータスによって解決され、プロセスとユーザーエクスペリエンスが効果的に向上します。同時に、再試行によってプロセスの一貫性と整合性が確保され、ネットワークの変動やその他の異常な状況によって生じるステータスデータの不一致が回避されます。さらに、監視アラームを使用することで、システムアプリケーションの動作状況をリアルタイムに監視し、異常や障害が発生したときに迅速にアラーム通知を発行できるため、店舗スタッフがタイムリーに問題に対処し、プロセス全体の信頼性と安定性を向上させることができます。

このプロセスはビジネスの一部にすぎません。 xb と axb を同時にバインドするなど、オンラインでの使用にはより複雑なシナリオがあります。両方が成功すること、タイムアウトがないこと、ステータスが一貫していることをどのように確認できるでしょうか?

プロセスの成功を確実にし、タイムアウトを回避し、一貫した状態を維持するには、次の手順に従ってプロセスを最適化できます。

ステータス値の追加: ライブラリテーブルに 2 つのステータス値を追加します。1 つは XB のバインディングステータス用、もう 1 つは AXB のバインディングステータス用です。
楽観的ロックを使用する: ビジネスチェックが完了したら、楽観的ロックを使用して 2 つのステータス値を同時に更新します。
スレッドを作成する: 2 つのプロセスが相互に影響を与えないように、XB と AXB のバインディングプロセスを処理する 2 つのスレッドを作成します。
状態転送: プロセスが完了すると、2 つの状態値がバインドされた状態に転送されます。
ポーリングインターフェイス: 店員のユーザーエクスペリエンスを最適化するために、エンドサイドポーリングクエリのバインディングステータスを取得するための別のインターフェイスを提供します。

上記の手順に従うことで、プロセスを効果的に最適化し、プロセスの成功を確実にし、タイムアウトを回避し、一貫した状態を維持できます。

4. オンラインプラン

バージョンを最適化するときは、エントリポイントを変更せずに、基礎となるレイヤーを変更するようにしてください。これにより、グレースケールのテストが容易になります。エントリポイントを同じに保つことで、ユーザーがバージョンをアップグレードするときに新たな障害や問題に遭遇することがなくなります。

 /** * 是否为灰度虚拟号码* * @param grayVirtualNumber * @return */ public boolean isGrayVirtualNumber(String grayVirtualNumber) { return flag || grayVirtualNumberList.contains(grayVirtualNumber); }

Apollo の設定に従って、オンライングレースケールテストとして特定の都市の仮想番号を設定しました。その他の仮想番号では、引き続き古いバージョンのサービスインターフェイスが使用されます。テストが成功したら、全容量を直接有効にすることができます。

5. 再試行コンポーネント

@ZZMQRetry を追加して、関数に AOP インターセプションを追加しました。リクエストは実際には再試行機能を同期的に実行しませんが、MQ メッセージを送信します。同時に、コンシューマーグループが自動的に開始され、コンシューマー関数は @ZZMQRetry 関数になります。

写真

6. まとめ

サードパーティのサービスとのインターフェースの相互作用では、制御できない要素が避けられません。システムの安定性と信頼性を確保するには、予防措置を講じることが重要です。一般的には、例外処理、タイムアウト設定、再試行メカニズム、サーキットブレーカー、監視、アラームなどの対策を設計し、実装する必要があります。これらの対策により、制御できない要因によって引き起こされる障害や不安定性からシステムを効果的に保護できます。