Phoenixフレームワークは、ゼロからイチまでビジネス並行フレームワークの設計方法とフレームワークの組織化について説明します。

上記のテキストを日本語に翻訳します：

前回の記事では、Phoenix フレームワークの設計に取り組む前に直面した問題とフレームワークの設計アプローチについて説明しました《 Phoenix フレームワーク 0 から 1 のビジネス並行フレームワークの設計小米商城製品サイト革新の道》、この記事ではフレームワークの設計方法について説明します。

Phoenix フレームワークは、有向グラフを自動的に構築し、深さ優先で並列グループを構築し、並列呼び出しの結果を実行するフレームワークです。

製品サイトのビジネススタティックインターフェースとダイナミックインターフェースは、データを取得し、ビジネスの編成を行うために大量のバックエンドサービスを呼び出す必要があります。そして、各並列呼び出しは相互に依存しています。依存関係を解消するために並列グループの設計を採用し、同時に並列呼び出しを制御し、BO から DTO への変換は統一された Transfer レイヤーを使用して設計され、開発者は各呼び出しイベントのタスクと Transfer コードロジックの定義にのみ注意を払い、ビジネスデータを直接返します。

レイヤー設計

用語の説明#

PhoenixFramework フェニックス（不死鳥）フレームワーク、このビジネス並行フレームワークの名前；
Task ビジネス並行での 1 回の呼び出しを定義し、HTTP、DUBBO、または Redis の取得、MySQL の読み取り操作などができます；
Transfer ビジネス定義では、BO データを DTO データに変換するサブビジネスモジュールの変換ロジックです；

Task と Trans の注釈#

Task の定義方法#

フレームワークの設計初期段階では、2 つの方法がありました。1 つは抽象クラスを継承して実装する方法で、Task は PhoenixTask クラスを継承して Task を定義します。もう 1 つは注釈の方法を採用し、各 Task を強制的に制約付きの Task として定義し、注釈で詳細な説明情報を定義し、開発者に明確な設計思想を提供します。

内部での議論の結果、私たちは Java の優れた言語機能である注釈の方法を選びました。このような定義により、コードが簡潔で明確になり、Spring Bean の収集ツールを使用して定義を収集することが容易になります。

/**  
 * PhoenixTask 
 * タスクの注釈  
 *  
 * @author debuginn
 */
@Retention(RetentionPolicy.RUNTIME)  
@Target(ElementType.TYPE)  
public @interface PhoenixTask {  
    String taskName();                     // タスク名  
    String[] beforeTaskName() default {};  // 前のタスク  
    String[] filterPlatform() default {};  // チャネルフィルタ、ブラックリスト  
    String[] taskBoName();                 // タスク生成のBOデータ、競合を検証するために使用  
}

PhoenixTask注釈の定義は非常にシンプルです：

taskNameはタスク名を示すために使用され、一意の命名を強制します；
beforeTaskNameは前のタスクであり、各タスクがイベントであることを前提としています。前のタスクを区別するために、並列呼び出しの際に結果の返却を待つ必要があります。その後、このタスクの呼び出しの前提パラメータとして使用されます；
filterPlatformはチャネルフィルタ、つまりブラックリストの機能です。タスクでリクエストチャネルを宣言し、並列実行時に自動的に実行をブロックします；
taskBoNameはタスクを BO データに変換し、インターフェース呼び出しまたはミドルウェアからデータを取得し、Transfer レイヤーで使用するデータに変換し、フレームワークレベルでデータパラメータの検証を行います；

Trans の定義方法#

Trans は Transfer の略称であり、Task と同様に注釈の方法で定義されます：

/**  
 * PhoenixTrans 
 * ビジネス編成の注釈  
 *  
 * @author debuginn 
 */
@Retention(RetentionPolicy.RUNTIME)  
@Target(ElementType.TYPE)  
public @interface PhoenixTrans {  
    String transName();             // ビジネス編成ブロック名  
    String apiName();               // 実行に使用する並列API  
    String[] tasks() default {};    // 依存するタスク  
}

PhoenixTrans注釈の定義も非常にシンプルです：

transNameはビジネス編成ブロック名を示します；
apiNameは、この Transfer ビジネス編成がどの並列 API に属するかを区別するために使用されます；
tasksは依存するタスクがどれかを定義します。ビジネス編成では、n 個のタスクの BO データを使用して編成を行うことがあります；

皆さんはここで疑問に思うかもしれません。なぜ Task に apiName を定義せず、Transfer で定義するのかということですが、設計上、Task が n 個の並列 API で共有されることを容易にするためです。そのため、Transfer で apiName を定義し、その後、tasks で依存する Task を定義することで、この Task が現在どの並列 API で使用されているかを推測することができます。

Task と Trans の収集方法#

PhoenixTaskとPhoenixTransの注釈をカスタマイズし、AnnotationProcessorを宣言してBeanPostProcessorを継承して注釈の定義を収集します。

まず、注釈クラスに基づいて対応する Task と Trans を収集します。
異なる Trans を異なる API に分割し、依存する Task を収集します。
Trans によって使用される Task に依存関係のフィルタリングを行います。
Task 間の相互依存関係に基づいて、Task をグループ化します。

これにより、フレームワークのレイヤー分割と自動構築の設計が完了しました。フレームワークの設計は、実際のビジネスで使用されるモジュールの抽象化設計を考えることが主な目的です。また、フレームワークの拡張性と強制性を考慮する必要があります。

結論#

この記事では、ビジネスと呼び出しの関係を Trans と Task に抽象化する方法について説明しました。次回は、並列フレームワークの並列スレッドプールのコア設計、構成思考、監視設計、自動構築アルゴリズムなどについて説明します。

興味がある場合は、公式アカウントをフォローするか、サイトに登録してください。お互いに強くなりましょう～

WeChat