Phoenixフレームワークは、0から1までのビジネス並行フレームワークの設計と、Xiaomiストアの製品サイトの革新の道を提供します。

序文#

小米ショッピングモールの製品サイトは、過去の理由から多くの問題と不便があります。技術の急速な変化に伴い、技術部門の「ミドルウェア化」の構築は、現在の急速なイテレーションのビジネス要件には適用されなくなってきました。次に、私は技術の視点から、私たちが直面している課題とそれらの課題を解決するアプローチ、つまり Phoenix フレームワークの誕生の物語を説明します。

なぜフレームワークを設計する必要があるのか、実際にはビジネスの発展によるものです。設計を行わない場合、次のような問題に直面することになります：

新しい製品の要件計画では、「大規模なプロジェクトを受け入れることができない」ため、小規模な修正しか行えません。
最初の小米ウェブサイトでは、「各プラットフォームには独自のコードロジックがあり、スタイルが異なります」。
長い歴史の中で、1 つのインターフェース関数には「2000 行以上」のコードがあり、コードロジックの理解にかかるコストがますます高くなっています。
隔離性が低く、サービスの「可用性が下流に厳しく依存している」ため、下流のインターフェースの揺れがインターフェースにパニックを引き起こす可能性があります。
技術的な全体的なミドルウェア化の構築により、呼び出すインターフェースが増えるにつれて、「インターフェースがますます遅くなる」。
コードが解耦されておらず、特に新しい同僚にとっては、新しいプロジェクトの「オンラインリスクが高い」です。
下流インターフェースのリアルタイムモニタリングができないため、Go の基本コンポーネントのメンテナンスが不足しています。

考察#

私たちは技術的にリファクタリングを計画していますが、既存のディスパッチロジックを抽象化して、安定性、開発の便利さ、メンテナンス性、および監視可能性を兼ね備えたフレームワークモデルをどのように作成するかが最初の問題です。

私はいくつかのオープンソースの並行フレームワークを調査しましたが、伝統的な並行ディスパッチモデルには一般的に依存関係、タイムアウト制御、スレッドプールの割り当てとスケジューリング、サーキットブレーカーとフロー制御、インターフェースのモニタリングなどの機能があります。

なぜ私たちはオープンソースの並行フレームワークを直接使用しないのでしょうか？

私の調査によると、業界で最も人気があり評価の高いフレームワークは LiteFlow フレームワークであることがわかりました。したがって、GitHub でフレームワークの内部実装の詳細を理解するために調査しました。ソースコードを詳しく読むにつれて、このフレームワークの設計は本当に優れていることがわかりましたが、同時に非常に大きく、複雑であり、特に EL ルールの記述方法は、一定の学習コストがかかります。

それでは、私は考えました。私はビジネス開発者として、このように複雑な依存関係について心配したくありません。自分の製品サイトのビジネスが中台のインターフェースとその依存関係に関与しているだけです。特に大規模なインターフェースが数十の下流インターフェースのロジックを束ねている場合、各インターフェースの設計の詳細を理解することはほぼ不可能です。依存関係が非常に複雑な場合、EL ルールは非常に複雑でメンテナンスコストが非常に高くなります。

では、軽量で高速で効率的で、開発者が依存関係を手動で管理することを根本的に解決する並行フレームワークをどのように設計すればよいでしょうか？

依存関係が存在するのであれば、アルゴリズムを使用して自動的に依存関係を構築できるのではないでしょうか？

設計#

タスクの分割

製品サイトの実際のシナリオに基づいて、複数の下流インターフェースを呼び出し、異なるリクエストプロトコルとミドルウェアが存在することがわかりました。

単方向の依存関係

さらに重要なことは、インターフェースには依存関係があり、インターフェース呼び出しを整理すると、インターフェースの依存関係は有向依存グラフの構造になっていることがわかります。したがって、依存関係をトラバースして並行グループをスケジュールすることができます。

並行呼び出しグループ

これにより、依存関係の問題が解決され、各並行グループのタスクを順番に並行して実行することができます。これにより、すべてのインターフェースまたは依存関係の結果を取得することができます。

結果を取得した後、結果をどのようにビジネスロジックに組み込み、下流インターフェースをどのように隔離するかは、実際には非常に簡単です。タスクを階層的に分割できるのであれば、ビジネス呼び出し、ビジネススケジューリング、防腐層も階層的な設計を行うことができます。

Transfer 層はビジネスロジック層であり、BO データをクライアントに提供するためのものです。
Task タスク層は並行実行の中核設計層であり、ここでは並行グループごとのサブタスクをスケジュールして実行し、タイムアウト制御、処理時間の統計などを行います。
Infrastructure 層は防腐層の設計として、下流インターフェースの呼び出しを隔離するために使用されます。この設計により、インターフェースの安定性が向上します。

最後に#

以上が私たちが説明した「自動的に構築される並行呼び出しグラフのビジネスフレームワーク」、つまり Phoenix フレームワークです。

Phoenix は、最初に周志明先生のウェブサイト「Phoenix Architecture」で言及され、一方で周先生のアーキテクチャデザインの理解と Java 関連の知識学習への敬意を表しています。また、フェニックスは不死鳥であり、ソフトウェアのライフサイクルも同様です。ビジネスの急速な発展に伴って生まれ、ビジネスの縮小に伴って消滅し、絶えず生まれ変わります。

最後に、このフレームワークが直面する問題と解決策についてシリーズで説明し、皆さんの読者に感謝します。興味がある場合は、公式アカウントをフォローすることをお勧めします。一緒により強くなりましょう〜