配布中の地域的な問題により、300ラウンドの戦いに至った

[[404321]]

この記事はWeChatの公開アカウント「Su San Talks Technology」から転載したもので、著者はSu San Talks Technologyです。この記事を転載する場合は、Su San Shuo Technology Public Account までご連絡ください。

序文

私は最近、会社の新しいプロジェクトに参加しました。このプロジェクトでは、企業、注文、契約、物流などのアクセス パーティのデータを、OpenAPI インターフェイスを介して当社のプラットフォームに同期する必要があり、その後、当社のプラットフォームが彼らに金融機能を提供しました。

当社と相手方は同じ市内にいないため、作業効率を上げるために、双方で複数回のオンラインビデオ通信を実施しました。当初はすべて順調に進みましたが、企業情報をアップロードするためのインターフェースについてやり取りしていたときに、インターフェース ドキュメントに非常に目立たない企業登録場所 ID フィールドが見つかり、行き詰まってしまいました。

何が起こっているのか？

1. 地域問題

当社のプラットフォームの企業テーブルには、必須の企業登録場所 ID のフィールドがあります。ユーザーは、企業登録ページで企業登録場所として地域を選択する必要があります。実際、データベースはリージョン ID を保存します。

ビジネスが正常に登録されると、ビジネスの詳細ページに地域名が表示されます。もちろん、私たちのシステムのバックグラウンド ロジックは、まずリージョン ID を使用してリージョン テーブルからリージョン名を取得し、それをユーザー インターフェイスに表示することです。

エンタープライズ テーブルとの一貫性を保つために、インターフェイス ドキュメントを定義するときにエンタープライズ登録場所 ID フィールドも必須にしました。

当時の状況は次のようでした。当社の地域テーブルには、ID、地域名、国家標準コード、グレードなどのフィールドが含まれていましたが、ここでのIDは当社のデータベースの主キーであり、ドッキングパーティのシステムでは絶対に利用できませんでした。ドッキング パーティのシステムにも地域テーブルのセットがありますが、ID はデータベース ID であり、テーブルには地域名、国家標準コード、グレードなどのフィールドもあります。

したがって、必要な地域 ID を私たちに渡す前に、そのシステムで何らかの変換を行う必要があります。

1.1 永続的なローカルリージョンテーブル

実は、私はこのプロジェクトに途中から参加しました。その前に他のことに取り組んでいました。私が参加した時点では、インターフェース ドキュメントはすでに定義されていました。

相手方との 2 回目のオンライン通信では、インターフェースの機能、各パラメータの意味、渡される値の有無など、インターフェース ドキュメントの詳細について両者で話し合いました。

企業情報アップロードインターフェースを使用する場合、インターフェースドキュメントに会社登録アドレス ID フィールドがあり、相手側がその値を渡すことができません。この問題を解決するための最初のソリューションは次のとおりです。

1. 相手側は当社の地域クエリ インターフェイスを呼び出し、複数のページング クエリを通じて最終的にすべての地域データを取得し、それをローカル地域テーブルに保存することができます。
2. エンタープライズ情報アップロード インターフェイスを呼び出す前に、まずローカル リージョン テーブルを照会し、必要なリージョン ID に変換します。

話し合いの中で、相手側も自分たちもプラットフォームであり、こうした余計なことをすべきではないと感じました。そのため、その会議ではどちらの側もこの問題に関して相手を説得することができず、最終的に合意に達することができませんでした。

後になって考えてみると、この計画は実に理想的すぎることに気づきました。ユーザーの視点から問題をあまり考慮しておらず、多くの詳細が無視されていました。これは、ドキュメント設計者がリージョン テーブルに精通していないことに関係している可能性があります。

1.2 地域クエリインターフェースを名前で呼び出す

その会議中に、私たちの同僚数名が短い議論を交わしました。相手側がリージョン テーブルのローカルでの永続性を受け入れたくないため、次善策として、相手側に永続性を要求しないことにします。この時点で、同僚は、リージョン ID を見つけるために、リージョン クエリ インターフェイスを名前で呼び出すことを提案しました。具体的な解決策は次のとおりです。

この解決策は表面的には問題ないように思えますが、私は以前に地域機能を担当していたことがあり、次のような状況を恐れていることがわかっています。

1. 相手側が送信した地域名が不完全である場合、例えば、元の名前は成都だが、実際にアップロードされた名前は成都であるなど。このように、地域クエリ インターフェースではファジー マッチングを行う必要があり、インターフェースが同時に呼び出されると、インターフェースのパフォーマンスに影響する可能性があります。
2. キーワード「北京」を入力すると、地域テーブルに 2 つのデータが表示されます。1 つは省レベルと同じデータで、もう 1 つは市レベルと同じです。どのデータに対応していますか?

そのため、私は当時これら 2 つの質問を提起し、地域名クエリの使用は推奨しませんでした。

1.3 国家標準コードによる地域クエリインターフェースの呼び出し

これを聞いた同僚も、地域名を使って検索するのは少し信頼性が低いと感じました。彼はすぐに計画を修正し、地域 ID を照会するために地域の国家標準コードを使用するように変更しました。具体的な計画は以下の通りです。

議論の時間が非常に短かったため、あまり考える時間がなく、当面はこの解決策を採用することにしました。

1.4 企業アップロードインターフェース入力パラメータ伝送国家標準コード

しばらくして、双方はインターフェース文書の検討を継続し、企業情報アップロードインターフェースにおける企業登録場所IDフィールドの値の伝送問題について再協議しました。

企業情報アップロード インターフェイスを呼び出す前に、まず地域クエリ インターフェイスを呼び出して地域 ID を調べます。入力パラメータは国家標準コードです。次に、この地域 ID をエンタープライズ情報アップロード インターフェイスに渡します。

相手方は私たちの提案を注意深く聞いて、一瞬躊躇しました。地域クエリインターフェースを再度調整する必要はないと感じました。双方が国家標準規格を使用すれば十分ではないでしょうか?

彼らのアイデアは、企業情報アップロードインターフェースにおいて、入力パラメータを企業登録場所IDから企業登録場所国家標準コードに変更するというものです。国家標準コードは国内で唯一の統一コードであるため、両側が同じである必要があり、データの一貫性を確保できます。

2. 質問を思い出しました

正直に言うと、地域機能に触れたことがなければ、ほとんどの人はおそらくこの解決策に同意するでしょう。

しかし、偶然にも、私は以前にも同様の機能に遭遇したことがあり、そのとき突然、「両者間のデータの一貫性を確保するにはどうすればよいのか」という疑問が浮かびました。

国の発展により、一部の都市の名前が変わることがあることは誰もが知っています。たとえば、襄樊は襄陽に変更されました。また、複数の地級市が一つの市に合併されることがあり、その場合、国標準コードが変更になります。そのため、国家統計ネットワークでは毎年、地域名と国家標準コードを調整しています。

私たちの地域テーブルは 2 年前に作成され、初期化されてからデータは更新されていません。

しかし、相手側は私たちと同時にデータを初期化せず、地域データを定期的に更新するため、双方のデータが不一致になります。取引先のビジネス フォームで新しく追加された都市名と国家標準コードが使用されており、この情報が地域テーブルに存在しない場合、必要な地域 ID を照会することはできません。

このような状況ではどうすればいいでしょうか?

2.1 双方が同時にリージョンテーブルを更新する

明らかに、上記の問題は非常に難しい問題です。このとき、一部の友人はこう言うかもしれません。「両者がジョブを使用して同時にリージョン テーブルを更新すれば、問題は解決するのではないでしょうか?」

私は以下の理由からこの解決策に同意しません。

このパートナーと同期して実行されるジョブは 1 つだけなので、問題はありません。しかし、エンタープライズ情報アップロード インターフェイスを呼び出す必要がある他のドッキング パーティがある場合、それらもジョブを完了する必要がありますか?さらに、全員が同時に実行する必要があり、結合されすぎています。

私たちとドッキングパーティが同時にジョブを実行しても、どちらかが実行に失敗すると、データの不整合が発生します。このとき、相手側がたまたま企業情報アップロードインターフェースを呼び出していた場合、何か問題はありますか?

2.2 どちらの当事者の地域データが優先されますか?

両者が同時に地域テーブルを更新するという上記の解決策は確かに少し信頼性に欠けますが、読者の中には、一方の地域データに基づいてもう一方の地域データを同期するだけで十分ではないのかと疑問に思う人もいるかもしれません。具体的な計画は以下の通りです。

この計画は、実は以前私たちが提案した最初の計画と非常によく似ていますが、相手方によって拒否されました。彼らの観点からすると、ビジネス情報をアップロードするためだけに地域データを保存する必要はまったくありません。

正直に言うと、たとえ合意したとしても、企業やシステム間でデータの一貫性を保証することは困難です。なぜなら、ドッキング側が当社の地域インターフェイスを呼び出せなかった場合、そしてこの時点で企業情報をアップロードする場合、問題が発生するのでしょうか?

3. その他の解決策

実際、私たちは問題を解決するためにこれらの解決策について話し合いました。

3.1 アップロードされたデータはスナップショットとして保存されます

当時私は、ドッキングパーティのデータは保存しているのに、なぜスナップショットを保存できないのかと尋ねました。シンプルで効率的なデータ形式である JSON を使用して、データを MongoDB に書き込むことができます。私の解決策は次のとおりです:

自社の業務データはMySQLの業務テーブルに保存され、相手方のデータはMongoDBに保存されるため、相互に干渉することはありません。

問題はないようです。

しかし、当時、この製品には次のように書かれていました。「銀行では、データを確認する際には、MySQL ビジネス テーブルのみを確認し、他のデータ ソースは確認しないことを規定しています。」

まあ、銀行を軽視すべきではないことは認めざるを得ません。

3.2 手動データ更新

別の同僚のアイデアは、最初にエンタープライズ情報アップロード インターフェイスを呼び出させることです。地域的な問題が見つかった場合は、地域テーブルのデータを手動で調整できるよう支援します。

具体的な計画は以下の通りです。

企業情報アップロードインターフェースを呼び出したときにリージョンが存在しない場合は、指定された担当者にアラームメールが送信されます。次に、指定された担当者が関連する地域データを手動で追加または変更します。

この解決策は問題ないように思えますが、問題が 1 つあります。仕事が終わった後や週末に何か問題が発生するのではないかと心配です。とにかく、私はこれをやるつもりはありません。これをやる気はありますか？

3.3 更新インターフェースを提供する

さらに、次のような解決策もあります。エンタープライズ情報アップロード インターフェイスを呼び出す前に、ドッキング パーティはまず地域クエリ インターフェイスを呼び出して、データが存在するかどうかを確認する必要があります。そうでない場合は、地域インターフェイスを保存します (保存には追加と変更が含まれます)。存在する場合は、通常どおりデータをアップロードします。

具体的な計画は以下の通りです。

このソリューションは簡略化できます。

リージョンのクエリと保存のロジックは、エンタープライズ情報アップロード インターフェイスに配置できます。これにより、相手側にとって透明性が高まり、地域的な問題がなくなるため、相手側は非常に満足するでしょう。

しかし、製品ではリージョンが基本データであると認識しており、セキュリティ上の理由から、それを変更するためのエントリを提供することはできません。そうしないと、将来的に混乱が生じる可能性があります。

これもうまくいかないし、あれもうまくいかない。突然困った状況になりましたが、全体の進行に影響を与えないように、まずは問題を記録し、それをスキップして他の分野の議論を続けるしかありませんでした。

4. この問題を解決するにはどうすればいいでしょうか?

その夜、私は長い間それについて考えました。そして翌朝、私の考えが上司の考えと一致していることに気づきました。結論としては、差別化は存在し、避けることはできないため、システム設計において差別化を受け入れなければならないということです。企業情報アップロードインターフェースに、企業登録場所の国家標準コードと地域名の 2 つのフィールドを追加します。ドッキングパーティは、これら 2 つのフィールドを通過するように変更されます。具体的な計画は以下の通りです。

1. オプションの地域名フィールドを会社テーブルに追加し、以前の地域 ID フィールドをオプションに変更します。
2. 相手側が当社の企業情報アップロードインターフェースを呼び出す際、地域国家標準コードと地域名を同時に渡す必要があります。
3. 当社の企業情報アップロードインターフェースでは、国家標準コードを通じて地域 ID が見つかった場合、その地域 ID が DB に書き込まれます。見つからない場合は、地域名が DB に書き込まれます。

影響範囲を評価したところ、エンタープライズ テーブルの地域フィールドは表示のみで、変更エントリがないため、上記の解決策は実行可能であることがわかりました。

その後、再度オンラインで相手方とコミュニケーションを取った際に、私たちの計画を伝えたところ、相手方も非常に同意してくれました。

5 結論

この地域の問題は、多くの技術的な問題の中では言及する価値がありません。しかし、よく考えてみると、要約する価値のある貴重な経験がまだいくつかあり、困っている友人への参考として使えると思います。

5.1 ユーザーの視点からインターフェースを設計する

インターフェース ドキュメントを設計するときは、必ずユーザーの視点から始める必要があります。

特にこのような openapi インターフェースの場合、定義されたパラメータは、リージョン ID などのカスタマイズされたパラメータを避け、可能な限り普遍的で認識可能なものにする必要があります。

ユーザーにとっての複雑さを軽減し、インターフェースの呼び出しを容易にするようにしてください。

5.2 技術的解決策は包括的であるべきである

技術的な解決策は、白か黒かではなく、包括的なものでなければならず、柔軟な思考が求められます。分散環境では、データの強い一貫性を盲目的に追求すると、あまり良い結果は得られません。同時実行性の高い商品のフラッシュセール システムと同様に、同期ソリューションを使用して実装する必要がある場合、システムは最終的にクラッシュする可能性があります。より良い解決策は、非同期キュー処理に変更することです。

当社と取引相手はともに地域テーブルを保有しており、データが完全に一貫していることを保証することは困難です。一貫性のために一貫性を求めるべきではありません。それは逆効果になります。仕事を円滑に進めるためには、どちらかが妥協しなければなりません。私の提案は、この技術的ソリューションが十分に普遍的になるように、OpenAPI インターフェース パーティが妥協する必要があるということです。

5.3 最善の解決策はなく、最も適切な解決策があるだけである

最終的な解決策では、リージョン ID が見つからないという問題は完全には解決されませんでしたが、ビジネスの観点からは、リージョン ID がなくてもリージョン名があれば同じです。明らかに、最終的なソリューションは実際のビジネス シナリオに非常に適しています。

したがって、最適なソリューションというものはなく、ビジネス シナリオに最適なソリューションのみがあることになります。

5.4 効果的なコミュニケーション

オンラインで相手とコミュニケーションをとるとき、何らかの問題で行き詰まらないようにしましょう。その時点で適切な技術的解決策がない場合は、この問題を一時的にスキップして、他のコンテンツを伝えることを選択できます。その後、私たちは二人きりでしばらく時間を過ごして、当時の問題について慎重に考え、より合理的な解決策を見つけ出しました。

5.5 テクノロジーはビジネスに役立つ

一見すると、この記事の地域問題は比較的単純に思えます。よく考えてみると、そこに何かがあることがわかるでしょう。さまざまな外部要因の制限と相まって、分散環境で地域データの一貫性を確保することはそれほど簡単ではないことがわかります。

プロセス全体を通して、私たちは多くの技術的ソリューションを提案しました。いくつかは問題を完璧に解決できそうでしたが、実際のビジネス シナリオではどれも却下されました。

テクノロジーはビジネスに役立ちます。テクノロジーは非常に重要ですが、ビジネスから切り離されれば単なる話になってしまいます。