目次
ミドルウェアの目的
ミドルウェア技術
再利用可能なソフトウェアのカテゴリに属します
ミドルウェアの特徴
ミドルウェアの 10 の利点
エンタープライズアプリケーションの統合
軽量アーキテクチャ
Strutsフレームワーク
作業過程：
春
エンタープライズアプリケーション向けのワンストップソリューション
休止状態
開発は面倒な JDBC コードを取り除き、データ表現とビジネス ロジックの作成に集中できます。
Struts、Spring、Hibernate を使用して軽量の WEB フレームワークを構築します。
実際のプロジェクト例
製品ロジックの全体像
コア機能サービス: 多数の機能モジュールが関係しているため、150 以上の http インターフェイスがページにデータを提供します。
ミドルウェア テクノロジー: プラットフォーム全体は、次のような多くのミドルウェア テクノロジーに依存しています。
- カフカのメッセージ。Kafka メッセージを使用して、金融決済データを金融システムに同期したり、広告データをサードパーティの基本プラットフォーム システムに同期したりするなど、サードパーティ システムとの非同期対話を実現します。
- ハイブデータ。ビッグ データ処理ビジネスでは、サードパーティのハイブ テーブルからデータを取得して、処理、クリーニング、処理などを行ったり、MySQL、キャッシュなどの複数のデータ ソースからデータを転送したりするなど、多くのビッグ データ処理シナリオがあります。 、ハイブ、およびサードパーティのインターフェイス フェッチされたデータは均一に処理され、その後のビジネス ロジックで使用できるようにハイブ テーブルに書き込まれます。Hive テーブルのデータ処理では、通常、1 時間ごと、2 時間ごと、または 1 日に 1 回処理されるタイミング タスク処理などのオフライン データ処理方法が採用されます。また、処理されるデータの規模も、数十または数百の小さなバッチなど、さまざまです。複数の周波数の処理、または数千万レベルの毎日の増分データ処理など。Hive はバッチデータの統計分析に適しています。
- 時間制限のあるタスク。名前が示すように、スケジュールされたタスクはさまざまな頻度で実行されるようにスケジュールされており、通常はオフラインでデータを処理するために使用されます。ビジネス システムには 100 以上のタイミング タスクが含まれており、これらのタスクはさまざまなデータ ソース、さまざまな規模、さまざまなビジネス シナリオからのデータを処理するために使用されます。
- HDFS ファイル。これは、特に読み取りが多く書き込みが少ないシナリオで、大規模データの分散読み取りおよび書き込みに使用されます。
非常に大きなファイルを遅延要件なしで保存します。HDFS ファイルは、サードパーティ システム (ダウンストリーム ビジネス システム エンジンなど) による読み取りのために大量のデータを書き込むためにビジネス システムで使用されます。ビジネス シナリオでは、まず大量のクリエイティブ データがサード パーティから取得され、次にシステムがフィルタ、入力、選別を行ってから、サード パーティのインターフェイスを呼び出してクリエイティブ データを確認します。ビジネス要件を満たす監査済みのクリエイティブ データを、スケジュールされたタスクを通じて HDFS ファイルに一度に書き込みます。書き込まれるフィールドには、マテリアル ID、トラフィック パッケージ ID、監査ステータスなどの情報が含まれます。 - ClickHouse: 以下、CH テーブル、列指向のストレージ データベース、OLAP 指向のデータベースと呼ばれる ClickHouse は、SQL に似た言語をサポートし、従来のリレーショナル データの利便性を提供します。実際の運用においては、CHテーブルの上流テーブルがハイブテーブルとなり、企業が一律に提供するIDPタスクを設定することで、ビジネス要件に応じてハイブテーブルのデータをCHテーブルに自動同期することができます。CH テーブル内のデータは、ダウンストリーム レポート エンジンのデータ ソースになります。
- データベース。ビジネスではマスター/スレーブの MySQL データベースを使用し、ミドルウェアでは mybatis を使用します。この業務では、複数のテーブルの追加、削除、変更、クエリが行われ、特定のテーブルに列やフィールドを追加する可能性があるため、業務コードには統合パッケージが採用されており、SQL インジェクションのリスクを防ぐだけでなく、SQL インジェクションのリスクを軽減することも容易になります。プログラムの拡大。
- Redisをキャッシュします。ビジネスでは、キャッシュ Redis クラスターは、下流ビジネスのコア ビジネス データを保存するために使用されます。ビジネス実装では、まずMySQLデータベース内のアプリケーションデータ、広告スペースデータ、コンテンツスペースデータ、マスキングルールデータ、メディアデータなどのビジネスデータが、スケジュールされたタスクを通じてRedisキャッシュに書き込まれます。ビジネス データの量が数百万に達し、ビジネス データがリアルタイムで変更される可能性があるため、データを 1 回同期するにはタイミング タスクを 40 分以上実行する必要があり、その後のロジックに影響を与える可能性があります。キャッシュの同期を高速化するために、ビジネス内で全体的なキャッシュ同期の最適化が実行され、スケジュールされたタスクの実行時間が 40 分以上から 20 分未満に短縮されました。具体的な方法としては、非同期マルチスレッドの利用、アプリケーションデータ、広告枠データ、コンテンツビットデータ、マスキングルールデータ、メディアデータ等の並列処理、redisの書き込み方式をパイプラインパイプライン書き込み方式に変更するなどが挙げられます。
- レポートエンジン。レポート エンジンは、企業アーキテクチャ グループによって提供される一連の基礎となるサービスであり、ビジネス パーティとして直接アクセスして呼び出すことができます。レポート エンジンに対応するインターフェイスの場合、呼び出しパラメータには主に必要なデータの次元、終了時刻、昇順、逆順などが含まれます。
- GRPC。rpc リモート プロシージャ コールは、基礎となるネットワーク テクノロジのプロトコルを理解する必要はありません。簡単に理解すると、あるノードが別のノードによって提供されるサービスを要求することになります。RPC は単なるプロトコルの集合であり、このプロトコル仕様に基づいて実装されたフレームワークを RPC フレームワークと呼ぶことができ、代表的なものとしては Dubbo、Thrift、gRPC があります。GRPC は、最新のオープンソースの高性能 RPC フレームワークです。
gRPCのインターフェース仕様
a. gRPC サービスを作成する場合、通常、最初のステップは .proto ファイルでインターフェイスを定義することです。この .proto ファイルを使用して、protoc コンパイラーでクライアントおよびサーバーのコードを生成します。サーバーとクライアントは .proto ファイルを共有します。クライアント側のコードを作成せずにクライアント側のコードを生成すると、多くのサービスを備えたアプリケーションの開発時間を大幅に節約できます。
b. インターフェースの入出力パラメータを.protoファイルに明確に記述し、これを基に各言語と通信可能なインターフェースを生成することで、異言語間の通信を実現します。
c. protoc によって生成されたコードは、クライアントまたはサーバーによって送信されたデータが仕様に準拠し、プラットフォームと実装間で一貫していることを保証します。
gRPC の利点には、効率的なバイナリ エンコード メカニズム、明確なインターフェイス仕様、ストリームのサポートが含まれます。
実際のビジネス シナリオでは、grpc の使用には次の 2 つの側面があります。
1. サーバーとして grpc サービスを作成し、proto ファイルを通じてインターフェイス、入力パラメーター、および出力パラメーターを定義し、grpc インターフェイスのロジックを実現します。同時に、インターフェース、つまりプロトファイルがサードパーティの呼び出しに提供されます。
2. クライアントとして、proto ファイルを通じてクライアント コードを生成し、サードパーティ サービスが提供する grpc インターフェイスを呼び出してデータを取得します。
私が担当している業務システムには、シナリオや次元の異なるデータを提供する grpc インターフェースが複数存在しており、同時にサードパーティが提供する grpc インターフェースを呼び出してデータを取得するクライアントとしても機能します。
- kconf. 企業が提供する設定プラットフォーム。さまざまな k/v 構成を実行でき、プログラム コード内で kconf パッケージを参照でき、kconf 内の構成を追加、削除、変更、確認できます。ブール、int、float/double、ハッシュマップ/ハッシュセット、リストリンクリスト、カスタムオブジェクトなど、さまざまなデータ形式がサポートされています。実際のビジネス開発では、通常、いくつかの主な用途があります。
1. スイッチとして。たとえば、構成値が TRUE の場合、新しく追加されたロジックが有効になり、構成値が FALSE の場合、新しいロジックはスキップされます。
2. 音量スイッチを徐々に上げていきます。たとえば、構成値が 20% の場合、トラフィック/ユーザーの 20% に新しいビジネス機能が表示され、構成値が 50% の場合、トラフィック/ユーザーの 50% に新しいビジネス機能が表示されます。一定期間、新しい機能は正常です。値は 100% まで徐々に増加します。これにより、すべての新しいビジネス機能が有効になり、システムのリリースが完了します。
3. 構成定数データとして。たとえば、一部の比較的固定されたビジネス データがビジネスで使用され、これらのビジネス データを簡単に変更する必要があり (コードを変更することなく、公開や起動などの一連の複雑な操作を実行する必要があります)、変更後に変更を有効にすることができます。これらのビジネス定数データをリアルタイムで kconf に設定し、ビジネス コードで使用します。
ストレージ層: MySQL、ハイブ テーブル、キャッシュ、画像/ビデオ ストレージなど、多くのストレージ ミドルウェアが関係しています。多くのテーブルが関係しており、MySQL データベースには 100 以上のテーブルがあり、50 以上のハイブ テーブルが関係しています。データソースは同時に処理されます。
MySQL データベース全体はマスター/スレーブ構造を採用しており、コアロジックやリアルタイム性の要求が高いロジックはマスターデータベース上で直接動作します。
ハイブ テーブルはビッグ データ ストレージとして使用され、ビッグ データを処理するオフライン タスクと組み合わせて、基盤となるストレージとして使用されます。企業レベルでは、ハイブに対応するパブリック プラットフォームとインターフェイスも提供されます。これにより、ハイブ テーブル データを MySQL テーブルにインポートしたり、MySQL テーブル データをハイブ テーブルにインポートしたり、ハイブ テーブル データを ClickHouse テーブルにインポートしたりするなど、他のデータ ソースとの移行が容易になります。 。異なるビジネスラインには同様の操作要件があるため、アーキテクチャチームはそのような操作を統一された方法でパッケージ化し、統一されたパブリックプラットフォームを提供します。これを必要とするビジネスラインは、その上にオフラインデータタスクIDPを構成するだけで済みます。
主要なミドルウェア相互作用
全体的なアーキテクチャ設計
ビッグデータ素材の下処理
重要なポイントと困難:
- 材料のフィルタリング。上流のサードパーティビジネスシステムの素材数は非常に多く（1日あたり数百万、数千万）、素材は本格的な素材であるため、ビジネスニーズに応じて全量をフィルタリングおよびスクリーニングするには複数の条件が必要ですビジネス ニーズを満たすマテリアルをフィルタリングするためのマテリアルの選択。審査条件はさまざまであり、事業展開に応じて変更される場合があります。したがって、ビジネスフィルタリングはビジネスニーズを満たす必要がある一方で、その後の拡張を容易にするためにさまざまな素材に適応する必要もあります。マテリアル フィルタリング ロジック処理全体では、複数の if/else ステートメントを記述してビジネス ロジックが結合しすぎることを避けるために、実装ではストラテジ モードを採用しています。実際のフィルタ条件は多数ありますが、ここでは説明と議論の便宜上、A、B、C、D の 4 つのフィルタ条件に簡略化しています。
戦略設計パターンの特徴:
1. 戦略インターフェースを提供する
2. 複数の戦略インターフェースの実装クラスを提供する
3. ポリシーコンテキストを提供する
戦略設計パターンの利点:
1. アルゴリズムを自由に切り替え可能（具体的な実装）
2. 複数の条件の判定を避ける(else if else)
3. 優れた拡張性 新しいアルゴリズムを定義してユーザーに提供可能（新しい機能を追加する場合、コードを修正することなくコードを追加するだけで済みます）
したがって、４つのフィルタ条件は、４つのポリシーインタフェースの実装クラスとして実現できる。2 つのフィルター条件の追加など、後で要件が変更された場合は、戦略インターフェイスの 2 つの実装クラスを追加するだけで済みます。これは元の実装に影響を与えず、以前のビジネス ロジックの変更を回避し、新しいビジネス ロジックを簡単に追加できます。
- 素材加工。第三者からオリジナル素材を入手する場合、写真素材であればサイズや縦横などをさらにカットしたり、タイトルやタイトル、写真などの詳細な情報が必要になるなど、ビジネスに必要な情報が不足することがよくあります。説明などを追加する必要があります。したがって、マテリアル処理ロジックでは、画像をさらにトリミングするために最初にサードパーティのトリミング インターフェイスが呼び出され、次にエンジン側のインターフェイスが呼び出されて、タイトル、タイトル、画像の説明、および元のマテリアルを埋めるその他の情報を取得します。情報。充填後、処理されたマテリアルは、その後の論理的な使用のためにバッチで MySQL マテリアル ライブラリに書き込まれます。
写真や動画だけでなく、サードパーティから入手する資料の種類も多いため、さまざまなビジネスシーンをカバーする必要があり、さまざまなビジネスシーンの資料にさらにさまざまな情報を詰め込む必要があります。したがって、材料処理ロジックでは、さまざまな材料を正しく処理することに重点を置く必要があります。
- 素材のレビュー。素材審査とはその名の通り、加工した素材をメディアに提出して審査を受け、審査を通過した素材のみが最終的に端末に表示されるものです。ビジネス シナリオでは、マテリアル レビューには 2 種類あります。1 つはページ上でレビューするもの、もう 1 つはレビューのためにマテリアルを第三者に送信するものです。
ページ上のレビューシーンでは、加工されたマテリアルがMySQLマテリアルライブラリに保存されます。レビュー ロジックはレビュー対象の資料を取得し、メディア関係者がレビューできるようにページに表示します。マテリアルが承認または拒否されると、レビューの結果がリアルタイムで MySQL マテリアル データベースに更新されます。
別の資料レビュー方法は、資料をレビューのために第三者に送信すること、すなわち、第三者が提供するインターフェースメソッドを呼び出すことによって、レビュー対象の資料を第三者に送信することである。次に、スケジュールされたタスクが実装され、サードパーティのレビュー ステータス インターフェイスがオフラインで呼び出され、最終的なマテリアル レビュー ステータスが取得されます。同様に、マテリアルが承認または拒否された後、レビューの結果はリアルタイムで MySQL マテリアル ライブラリに更新されます。
- マテリアルは HDFS に書き込まれます。素材データが膨大であり、すべてをサードパーティエンジン側に同期する必要があるため、ここではオフラインライティングを実現するために時間指定タスクが使用されます。つまり、スケジュールされたタスクが時々実行され、承認されたすべてのマテリアルが hdfs ファイルに書き込まれます。書き込まれるコア フィールドには、マテリアル ID、監査ステータス、マテリアルが属するトラフィック パッケージなどが含まれます。
ビジネス交流の全体像
ボトムデータマテリアル処理の全体像
