CreditEase オープンソース |分散タスクスケジューリングプラットフォームSIA-TASKのアーキテクチャ設計と運用プロセス

1. 分散タスクスケジューリングの背景

インターネットアプリケーションであっても、エンタープライズレベルのアプリケーションであっても、多数のバッチ処理タスクが満載です。問題を解決するために、タスクスケジューリングシステムが必要になることがよくあります。マイクロサービスアーキテクチャが徐々に進化するにつれ、モノリシックアーキテクチャは徐々に分散型のマイクロサービスアーキテクチャへと進化してきました。このような状況の中で、元のタスクスケジューリングプラットフォームの多くはビジネスシステムのニーズを満たすことができなくなり、いくつかの分散タスクスケジューリングプラットフォームが登場しました。

1.1 分散タスクスケジューリングの進化

実際のビジネス開発プロセスでは、問題を解決するために、スケジュールされたタスクを使用しなければならないことがよくあります。通常、解決策は複数あります。Crontab または SpringCron を使用します (もちろん、マシンの数が少なく、タスクが単純で数が少ない場合にも、これが当てはまる場合があります)。ただし、アプリケーションの複雑さが増し、スケジュールされたタスクの数が増え、タスク間に依存関係が生じると、Crontab を使用したスケジュールされたタスクの管理と構成が非常に複雑になり、作業効率に重大な影響を及ぼします。これにより、一連の疑問が生じます。

タスク管理が混乱しており、ライフサイクルを統一的かつ調整された方法で管理することができません。
タスク間に依存関係がある場合、それらを整理することは困難です。

インターネットの発展に伴い、分散サービスアーキテクチャがますます普及しています。同様に、分散アーキテクチャでスケジュールされたタスクを管理するには、分散タスクスケジューリングシステムも必要です。

1.2 分散タスクスケジューリングアーキテクチャ

垂直アプリケーションがますます多く出現するにつれて、アプリケーション間の相互作用はますます複雑になります。通常、コアビジネスを抽出し、別のサービスを形成するために、分散型またはマイクロサービスアーキテクチャを採用します。独立したマイクロサービスグループが徐々に安定したサービスセンターを形成し、ビジネスアプリケーションが変化する市場の需要に迅速に対応できるようになります。

この時点で、ビジネスの再利用と統合を改善するための分散サービスフレームワークが鍵となります。同時に、サービスの独立性により、スケジュールされたタスクは一般に独立しており、タスクの変更がシステム全体に及ぼす影響はほとんどありません。通常は、タスクとスケジュールを分離する方法を採用します（上図参照）。タスクの実行ロジックでは、スケジュールとオーケストレーションに注意を払う必要はありません。同時に、エグゼキュータとスケジューリングの高可用性を確保でき、開発と保守も容易です。

1.3 分散タスクスケジューリングの利点

分散サービスアーキテクチャでは、独立した業務の数が多くなる可能性があるため、スケジュールされたタスクをサービス内に個別に実装すると、管理が困難になる可能性があり、スケジュールされたタスクの変更による業務の再開は避けられません。したがって、スケジュールされたすべてのタスクをグローバルに調整および管理するために使用できる、独立した分散タスクスケジューリングシステムが必要です。同時に、分散タスクスケジューリングシステムの機能としてタスク構成を個別に抽出することで、ビジネスやシステム全体に影響を与えることなく、スケジュールされたタスクに変更を加えることができます。

管理はスケジュールとタスクごとに分離されており、開発および保守コストが大幅に削減されます。
分散展開により、システムの高可用性、スケーラビリティ、負荷分散、および耐障害性の向上が保証されます。
スケジュールされたタスクはコンソールを通じて展開および管理できるため、便利で柔軟性があり、効率的です。
すべてのタスクをデータベースに保存できるため、ダウンタイムやデータ損失などの潜在的な危険を回避できます。同時に、完全なタスク失敗やり直しメカニズムと詳細なタスク追跡およびアラーム戦略があります。

2. 分散タスクスケジューリング技術の選択

2.1 分散タスクスケジューリングの考慮事項

タスクのスケジュール設定: 複数のビジネス間でスケジュールされたタスクの処理順序があります。
タスクのシャーディング: 大規模なタスクの場合は、シャーディングして並列実行する必要があります。
クロスプラットフォーム: Java テクノロジースタック (SpringBoot、Spring など) を使用するプロジェクトに加えて、他の言語を使用するアプリケーションもあります。
非侵入的: ビジネスはスケジュールと密接に結びつくことを望まず、ビジネスの実行ロジックのみに焦点を当てます。
障害転送: タスク実行中に問題が発生した場合、手動介入を減らすための補償手段があります。
高可用性: スケジューリングシステム自体が高可用性を確保する必要があります。
リアルタイム監視: タスクの実行ステータスをリアルタイムで取得します。
視覚化: タスクスケジューリング操作では、使いやすい視覚化ページが提供されます。
動的編集: ビジネスのタスククロックパラメータが変更される場合があり、デプロイメントをシャットダウンしたくない場合があります。

2.2 SIA-TASKと他の分散タスクスケジューリング技術の比較

SIA は、CreditEase の基本開発プラットフォームである Simple is Awesome の略です。 SIA-TASK（マイクロサービスタスクスケジューリングプラットフォーム）は、その重要な製品の1つです。 SIA-TASK は現在のマイクロサービスアーキテクチャモデルに適合し、クロスプラットフォーム、オーケストレーション、高可用性、非侵入、一貫性、非同期並列処理、動的拡張、リアルタイム監視などの特性を備えています。

オープンソースアドレス: https://github.com/siaorg/sia-task

まず、市場で主流のオープンソース分散タスクスケジューリングフレームワークを比較し、その長所と短所を分析してから、当社のテクノロジの選択を紹介します。

Quartz: Quartz は、タスクスケジューリングの分野における OpenSymphony オープンソース組織のオープンソースプロジェクトであり、完全に Java ベースで実装されています。このプロジェクトは2009年にTerracottaに買収され、現在はTerracottaの傘下のプロジェクトとなっています。 JDK や Spring が提供するスケジュールされたタスクと比較すると、Quartz は基本的に単一のタスクに対する究極の制御を実現しています。強力な機能とアプリケーションの柔軟性により、エンタープライズアプリケーションで大きな役割を果たしてきました。ただし、Quartz はタスクのスケジューリング (タスク間に依存関係がある) をサポートしておらず、タスクのスライスもサポートしていません。
TBSchedule: TBSchedule は、バッチタスクまたは常に変化するタスクを複数のホストの JVM に動的に割り当て、異なるスレッドグループで並列に実行できるようにする分散スケジューリングフレームワークです。 Alibaba によってオープンソース化された ZooKeeper に基づく純粋な Java 実装。 TBSchedule はタスクの分散に重点を置いており、タスクのスライスをサポートしていますが、タスクのスケジュール設定はなく、クロスプラットフォームではありません。
Elastic-Job: Elastic-Job は、Dangdang のオープンソースの分散スケジューリングソリューションであり、Elastic-Job-Lite と Elastic-Job-Cloud という 2 つの独立したサブプロジェクトで構成されています。 Elastic-Job はタスクシャーディング (ジョブシャーディングの一貫性) をサポートしていますが、タスクオーケストレーションはなく、クロスプラットフォームではありません。
Saturn: Saturn は、Vipshop のオープンソースの分散型高可用性スケジューリングサービスです。 Saturn は Elastic-Job の二次開発であり、監視、タスクシャーディング、クロスプラットフォームをサポートしていますが、タスクオーケストレーションはサポートしていません。
Antares: Antares は Quartz をベースにした分散スケジューリングであり、シャーディングとツリー型のタスク依存関係をサポートしていますが、クロスプラットフォームではありません。
Uncode-Schedule: Uncode-Schedule は、Zookeeper をベースにした分散タスクスケジューリングコンポーネントです。重複や省略なくクラスター内のすべてのタスクの実行をサポートします。タスクの動的な追加と削除をサポートします。ただし、タスクのスライスやタスクのスケジュール設定はサポートされておらず、クロスプラットフォームではありません。
XXL-JOB: XXL-JOB は軽量の分散タスクスケジューリングプラットフォームです。その中心的な設計目標は、開発が速く、習得しやすく、軽量で、拡張しやすいことです。 XXL-JOB はシャーディング、タスク依存関係のシンプルなサポート、サブタスク依存関係のサポートをサポートしており、クロスプラットフォームではありません。

以下では、SIA-TASK とこれらのタスクスケジューリングフレームワークを簡単に比較します。

	タスクのスケジュール	タスクシャーディング	クロスプラットフォーム	高可用性	フェイルオーバー	リアルタイム監視
SIAタスク	√	√	√	√	√	√
石英	×	×	。ネット	√	×	API モニタリング
TBSchedule	×	√	×	√	√	√
エラスティックジョブ	×	√	×	√	√	√
土星	×	√	√	√	√	√
アンタレス	√	√	×	√	√	√
アンコードスケジュール	×	×	×	√	√	√
XXLジョブ	サブタスクの依存関係	√	×	√	√	√

これらのスケジューリングフレームワークは基本的に高可用性、フェイルオーバー、リアルタイム監視などの機能をサポートしていますが、タスクオーケストレーション、タスクスライシング、クロスプラットフォームなどの機能のサポートに重点を置いていることがわかります。 SIA-TASK はこれらの機能を完全にサポートします。

3. SIA-TASKの紹介

3.1 SIA-TASK技術の選択

R EST: ソフトウェアアーキテクチャスタイル。クロスプラットフォームの目的を達成するには、実行者が HTTP 呼び出しインターフェースを公開する必要があります。
AOP: アスペクトプログラミングテクノロジー。 Spring プロジェクト拡張パッケージ Hunter で使用され、Task がシリアルに呼び出されることを保証します (シングルトンシングルスレッド)。
Quartz: 強力な機能と柔軟なアプリケーションを備えています。基本的に単一のタスクに対する究極の制御を実現でき、スケジューリングセンターのクロックコンポーネントとして使用されます。
MySQL: メタデータの保存と (一時的な) ログアクセスに使用されます。
Elastic: ログの保存とクエリのための分散型マルチユーザー全文検索エンジンを提供する、Lucene ベースの検索サーバー。
SpringCloud: 活発なコミュニティサポートを備えた開発フレームワークであり、会社指定の統合開発フレームワークでもあります。迅速な開発と迅速な反復に使用されます。
MyBatis: カスタマイズされた SQL、ストアドプロシージャ、高度なマッピングをサポートする優れた永続化レイヤーフレームワーク。永続層の開発を簡素化するために使用されます。
Zookeeper: 実績のあるレジストリ。ディスパッチセンターの高可用性や分散一貫性などの問題を解決するために使用されます。

3.2 SIA-TASK設計コンセプト

SIA-TASK は、マイクロサービスの設計概念を活用して、各エグゼキュータノードに分散されたタスクのメタデータを取得し、報告して、登録センターにアップロードします。オンラインで編集可能な方法を使用して、オンラインでのタスクのスケジュール設定とタスククロックの動的な変更をサポートします。対話型伝送プロトコルとして Http プロトコルを使用します。データ交換形式は統一的にJsonを使用します。ユーザーはオーケストレーター (以下で説明) を介して操作し、イベントをトリガーします。スケジューラはイベントを受信し、スケジューリングセンターはクロック分析を実行し、タスクフローを実行して、タスク通知を発行します。

3.3 SIA-TASKの基本概念

SIA-TASKはタスクとスケジューリングを分離する方式を採用しており、業務の実行タスクロジックとスケジューリングロジックが完全に分離されています。システム構成には、次のコアコンセプトが含まれます。

タスク: 基本的な実行単位。エグゼキュータによって公開される HTTP 呼び出しインターフェイス。
ジョブ: 相互に論理的な関係(シリアル/パラレル)を持つ 1 つ以上のタスクで構成され、タスクスケジューリングセンターによってスケジュールされる最小単位です。
プラン: 順番に実行される複数のジョブで構成されます。各ジョブには独自の実行サイクルがありますが、プランには実行サイクルがありません。
タスクスケジューリングセンター (スケジューラ): 各ジョブの実行サイクルに従ってタスクをスケジュールします。つまり、プラン、ジョブ、タスクのロジックに従って HTTP 要求を実行します。
タスクオーケストレーションセンター (構成): オーケストレーションセンターはタスクを使用してプランとジョブを作成します。
タスク実行者: HTTP リクエストを受信し、ビジネスロジックを実行します。
Hunter: Executor でタスクをキャプチャし、登録センターにアップロードする役割を担う Spring プロジェクト拡張パッケージ。企業はこのコンポーネントを利用してタスクを記述できます。

3.4 SIA-TASKシステムアーキテクチャ

SIA-TASK は、3 つのモジュール (スケジューリングセンター、オーケストレーションセンター、エグゼキュータ) と 2 つのコンポーネント (永続ストレージと登録センター) に分けられます。これら 3 つのモジュールと 2 つのコンポーネントの機能は次のとおりです。

タスクスケジューリングセンター: ジョブのプリエンプション、タスクのスケジューリング、タスクの移行などを担当します。SIA-TASK のコア機能モジュールです。
タスクオーケストレーションセンター: オンラインタスクの論理オーケストレーションを担当し、ログ表示およびリアルタイム監視機能を提供します。
タスク実行者: スケジュール要求を受信し、タスクロジックを実行する役割を担います。
タスク登録センター (ZK): ジョブ、タスク、スケジューラなどのワークフローを調整します。
永続ストレージ (DB): プロジェクトのジョブとタスクのデータを記録し、ログストレージを提供します。

SIA-TASKは、SpringBootシステムをアーキテクチャ選択として使用し、QuartzとZookeeperに基づいて二次開発を行い、対応する機能をサポートします。 SIA-TASK の論理アーキテクチャ図を次の図に示します。

3.5 SIA-TASKモジュールの説明

3.5.1 タスクスケジュールセンター

タスクスケジューリングセンターは、タスクのスケジューリング、スケジューリング情報の管理、およびスケジューリング構成に従ったスケジューリング要求の発行を担当します。それ自体にはビジネスコードは存在しません。スケジューリングシステムはタスクから分離されているため、システムの可用性と安定性が向上します。同時に、スケジューリングシステムのパフォーマンスはタスクモジュールによって制限されなくなりました。タスクの作成、更新、削除、タスクアラームなどのスケジュール情報の視覚的、シンプル、動的な管理をサポートします。上記の操作はすべてリアルタイムで有効になります。また、スケジューリング結果や実行ログの監視、エグゼキュータ障害回復もサポートします。

3.5.2 タスクスケジューリングセンター

タスクオーケストレーションセンターは、オンラインタスクモデルオーケストレーションをサポートする分散スケジューリングセンターのコンポーネントです。 UI に基づいて Web 側のタスクオーケストレーションを実行できます。

上記の基本モデルを使用して、次のような複雑なスケジューリングモデルを調整できます。

SIA-TASK UIレイアウトインターフェース:

オーケストレーションが完了したら、次の図に示すように、タスクのオーケストレーション情報を確認します。

同時に、オーケストレーションセンターは、ホームページの統計表示、スケジュール監視、ジョブ管理、タスク管理、ログ管理機能も提供します。

3.5.3 タスク実行者

スケジュール要求を受信し、タスクロジックを実行する責任があります。タスクモジュールは、タスク実行などの操作に重点を置いており、開発と保守をよりシンプルかつ効率的にします。

サポートされているアクチュエータには 2 つのタイプがあります。

（1）sia-task-hunterを使用すると、SpringBootプロジェクトとSpringプロジェクトがサポートされます。 sia-task-hunter とタスクキャプチャクライアントを紹介します。準拠した HTTP インターフェイス (タスクと呼ばれる) タスクは自動的にキャプチャされ、登録センターにアップロードされます。

（２）sia-task-hunterを使用しない場合は、タスクが呼び出すことができるHTTPインターフェースのみを提供する必要があります。この場合、ビジネス側は手動で入力し、タスクの同時呼び出しを自ら制御する必要があります。

3.5.4 タスク登録センター（Zookeeper）

分散フレームワークは、登録センターとして Zookeeper を使用します。

（１）タスク登録

スケジューリングセンターと実行クラスターはどちらも、登録センターとして Zookeeper を使用します。すべてのデータはノードとノードコンテンツの形式で登録され、ホストのステータスを定期的に報告することで Zookeeper 上で維持されます。

（２）メタデータ保存

登録センターは登録サービスを提供するだけでなく、各エグゼキュータに関する情報（エグゼキュータインスタンス情報、エグゼキュータによってアップロードされたタスクメタデータ、タスク実行時の一時的なステータスデータなど）も保存します。

（３）イベントリリース

タスクは Zookeeper イベントプッシュメカニズムに基づいて公開され、バランスアルゴリズムを使用してスケジューラタスクのプリエンプションのバランスの取れた分散が保証されます。

（4）負荷分散

単一ノードへの負荷を回避するために、スケジューラがバランスの取れた実行ジョブ数を取得するようにします。

3.5.5 永続ストレージ（DB）

ここでは、データ永続化ソリューションとして MySQL が使用されます。

登録センターに保存されるタスクの動的メタデータに加えて、手動で入力されたタスク、構成されたジョブ情報、スケジュールされたタスクの依存関係情報、スケジュールログ、ビジネス担当者の操作ログ、タスク実行ログなど、その他の関連メタデータも MySQL に保存されます。

3.6 SIA-TASKキー操作プロセス

3.6.1 タスクリリースプロセス

（１）ユーザーはUIを通じてジョブを作成することができます。ジョブの種類を選択したり、警告のメールアドレスを設定したり、ジョブの説明を設定したりできます。次に、作成したジョブのタスクを配置します。

（２）ジョブが作成され、タスクのスケジュール関係が設定されると、タスクを公開し、対応するジョブをUI（アクティブ化、1回実行、停止、削除操作）を介して操作できるようになります。

（3）ユーザーのタスクはクローラーを通じてキャプチャすることも、UIを使用して手動で作成することもできます。

3.6.2 実行プロセス

（1）ジョブが作成された後、トリガースケジュールタスクをアクティブ化することを選択できます。

（２）ジョブがスケジュールされた時間に到着すると、スケジューリングセンターはジョブをトリガーし、HTTPを介してタスク実行者に通知して、事前に決定されたタスクスケジューリングロジックに従って実行し、タスク実行結果を非同期的に監視します。

（３）実行結果が成功であれば、後続タスクがあるかどうかを判定する。そうであれば、次のスケジュールに進みます。そうでない場合は、ジョブが実行され、通話が終了したことを意味します。実行結果が失敗した場合、障害回復戦略がトリガーされます。つまり、すぐに停止するか、障害を無視するか、複数回試行するか、実行のために他のエグゼキュータに切り替えます。

3.6.3 状態遷移

ジョブのライフサイクル全体にわたって、停止 (NULL)、準備中 (READY)、実行中 (RUNNING)、異常停止 (STOP) の 4 つの状態があります。状態フローとフロー条件を次の図に示します。

3.7 SIA-TASKモジュール設計

SIA-TASK の物理ネットワークトポロジを以下に示します。

SIA-TASK のモジュール間インタラクション設計のアイデア:

（１）オーケストレーションセンターを通じてタスクを作成するか、ハンターを通じて自動的にタスクをキャプチャし、タスク情報を非同期でDBに保存します。ジョブを作成してアクティブ化し、Zookeeper に JobKey を作成します。

（２）スケジューリングセンターはZookeeperのJobKey作成イベントを監視し、作成されたジョブをプリエンプトします。プリエンプションが成功すると、Quartz のスケジュールされたタスクに追加され、時間が来るとジョブが実行されるようにトリガーされます。ディスパッチセンターは、ジョブ内のタスク (タスク失敗戦略に従って複数のタスクが存在する場合があります) を実行するためにエグゼキュータサービスを非同期的に呼び出し、結果をディスパッチセンターに返します。

（３）ジョブ実行ステータスはZooKeeper上でいつでも変更でき、オーケストレーションセンターのクエリインターフェースを通じて照会することができます。

（４）ジョブ実行後、次回の実行を待ちます。

3.7.1 タスクスケジューリングセンターの設計

オーケストレーションセンターは、データに関して DB および Zookeeper と対話できます。その主な機能は、次の 3 つの側面に分けられます。

データ永続性インターフェースサービス。
Zookeeper のメタデータの変更。
データの視覚化: さまざまなシステム統計などを表示します。

オーケストレーションセンターのホームページの監視表示は次のとおりです。

3.7.2 タスクスケジューリングセンターの設計

ディスパッチセンターは主に DB、ZK、エグゼキュータとやり取りします。その主な機能は、次の側面に分けられます。

ジョブ実行ログ
ZK でのジョブステータスの変更
ジョブを実行するにはエグゼキュータサービスを呼び出す
ディスパッチセンターの高可用性
ジョブスケジューリングスレッドプール

3.7.3 タスク実行者の設計

実行者は ZK およびスケジュールセンターと対話できます。その主な機能は 2 つの側面に分けられます。

ディスパッチセンターのディスパッチを受け入れ、スケジュールされたタスクを実行し、結果をディスパッチセンターに返します。
Executor 上のタスクを自動的に取得し、ZK に送信します。

実行タスクの例:

 @OnlineTask (description = "オンラインタスクの例" 、enableSerial = true )
 @RequestMapping (値 = "/example" 、メソッド = { RequestMethod.POST }、結果 = "application/json;charset=UTF-8" )
 @CrossOrigin (メソッド = { RequestMethod.POST }、オリジン = "*" )
 @レスポンス本文 
パブリック文字列の例( @RequestBody String json) {
 /**
     * TODO: クライアントのビジネスロジック処理
     */  
    Map<String, String> info =新しいHashMap<String, String>();
    info.put( "ステータス" , "成功" );
    info.put( "結果" , "必要に応じて" );
 JSONHelper.toString(info)を返します。
 }

タスクの書き方は非常に簡単であることがわかります。

3.8 SIA-TASK高可用性設計

分散サービスでは通常、高可用性ソリューションを考慮する必要があります。同様に、高可用性を確保するために、SIA-TASK はさまざまな側面でさまざまなサービスコンポーネントを強化しました。

3.8.1 タスクオーケストレーションセンターの高可用性

SIA-TASK は、フロントエンドとバックエンドの分離、サービスの分割などの対策を通じて、オーケストレーションセンターの高可用性を実現します。クラスター内のインスタンスに障害が発生しても、クラスター内の他のインスタンスには影響がないため、特別な操作を行わずにクラスター内の他の利用可能なオーケストレーションセンターを使用できます。

3.8.2 タスクスケジューリングセンターの高可用性

3.8.2.1 異常転送

スケジューリングセンタークラスター内のインスタンスノードサービスがダウンした場合、スケジュールされたタスクが失われることなく、このインスタンスノード上のすべてのジョブがクラスター内の使用可能なインスタンスにスムーズに移行されます。同時に、クラッシュしたインスタンスが正常に修復され、クラスターに再接続されると、ジョブをプリエンプトしてサービスを提供し続けます。

3.8.2.2 スレッドプールの設定

スケジューリングは、単一スレッドのブロックによって発生するタスクスケジューリングの遅延を回避するために、スレッドプールを使用して実装されます。スレッドプール内のスレッドの数。デフォルト値は 10 です。タスクを同時に実行する場合は、ビジネス特性に基づいてスレッドプールのサイズを選択する必要があります。

 org.quartz.threadPool です。クラス= org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 60  
 org.quartz.threadPool.threadPriority = 5  
 org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

SIA-TASK は、Quartz 自体が提供する threadPool に基づいて、スレッドプールを再度使用します。スレッドプールを再定義し、各ジョブに一意のスレッドプールを割り当てます。スレッドプールのサイズは、ジョブ自体によってスケジュールされたタスクの数に応じて動的にスケーリングできるため、各ジョブのスケジュールスレッドが完全に独立し、スケジュールされたタスクの数の急増によってスレッドリソースが枯渇することがなくなります。同時に、ジョブが永久に終了したときに割り当てられたスレッドプールリソースをリサイクルするためのスレッドプールリソースリサイクルロジックも提供します。

公共 静的エグゼキュータサービス getExecutorService(String JobKey) {
 ExecutorService exec = executorPool.get(JobKey);
実行 == nullの場合
LOGGER.info(Constants.LOG_PREFIX + "ジョブを実行するためのスレッド プールを初期化します。ジョブは {} です" ,JobKey);
 exec = Executors.newCachedThreadPool();
 executorPool.putIfAbsent(JobKey、exec);
 exec = executorPool.get(ジョブキー);
 }
実行を返します。
 }

3.8.2.3 完全なログ追跡

SIA-TASK は、ジョブのスケジュールライフサイクル全体を包括的に追跡し、ログ拡張に AOP を使用します。スケジューリングセンターは、ジョブスケジューリングがトリガーされるたびにログに記録します。同時に、ジョブによってスケジュールされたタスク実行のタスクログも記録されます。

ログはジョブログとタスクログに分かれています。

ジョブログ: スケジューラ情報、スケジュール時間、スケジュールステータス、およびその他の追加属性が含まれます。
タスクログ: 実行者情報、実行時間、実行ステータス、戻り情報、およびその他の追加属性が含まれます。

3.8.2.4 非同期カプセル化

SIA-TASK は、リモートタスク呼び出しによってスケジューリングセンターで同時スレッドリソースが失われることを考慮して最初から設計されました。ジョブにカプセル化されたタスクのリモートスケジューリングでは、すべての非同期呼び出しが使用され、各タスク要求ロジックの時間消費は非常に軽量です。 http リクエストは 1 回のみ表示されます。
タスクのユーザー定義のタイムアウト設定をサポートし、connecttimeout と readtimeout の 2 つのタイムアウトモードをサポートします。ビジネスの特定の実行サイクルに基づいてユーザーがタイムアウトを設定できるようにサポートします。

公共 インターフェースRestTemplate {
 /**
 * 非同期Postメソッド * @param request
 * @param レスポンスタイプ
* @param uri変数
* @param <T>
 * @戻る
*/  
 <T> ListenableFuture<ResponseEntity<T>> postAsyncForEntity(リクエスト request、クラス<T> responseType、オブジェクト... uriVariables); }

3.8.2.5 カスタムスケジューラリソースプール

SIA-TASK は、物理リソースの観点からスケジューリングリソースプールを設計します。特別な考慮のためにスケジューラをプールします。スケジューラはさまざまな操作を通じて状態を変更し、それによって機能を変換することができます。

ワークスケジューラリソースプール: タスクを取得する機能があり、実際にタスクを取得できるスケジューラリソースを管理します。
オフラインスケジューラリソースプール: タスクを取得する機能があるが、実際にはタスクを取得することが許可されていないスケジューラリソースを管理します。
オフラインスケジューラリソースプール: オフラインスケジューラリソースプール内のダウンタイムスケジューラリソースを管理します。

3.8.3 タスクエグゼキュータの高可用性

ネットワークの不安定性を考慮して、SIA-TASK は、ノード接続テストのサポートや、タスク実行インスタンスノードの健全性の事前認識など、ネットワークの不安定性に対する非常に重要な設計も行っており、タスクインスタンスノードの健全性を事前に認識し、スケジュールされたタスクの可用性を高めることができます。
同時に、ネットワークによる接続中断の問題からエグゼキュータインスタンスを保護することも保証されます。 SIA-TASK は、ネットワークの問題により接続が失われた後でもタスク実行インスタンスノードを復元して再試行できるように、Zookeeper の再接続メカニズムを再設計し、正常に復元された後も実行プールに組み込んでタスクのスケジュールを正常に受信できるようにしました。
一般的に、エグゼキュータもクラスターにデプロイされます。タスクの実行単位として、エグゼキュータクラスタ内のマシンで実行が失敗した場合、スケジューリングセンターは障害戦略に従ってフェイルオーバーを実行します。ラウンドロビンフェイルオーバーと最大補償フェイルオーバーの 2 つのフェイルオーバー戦略が提供されます。ポーリング転送は、利用可能なエグゼキュータのリストをポーリングすることです。 1 つの実行者が成功すると、タスクは正常に実行されます。すべての実行者が失敗すると、タスクは失敗します。最大の補償転送は、まず現在のエグゼキュータでそれを数回再度実行することです。実行が成功した場合は転送されません。それでも実行が失敗する場合は、ポーリング転送戦略が実行されます。

IV.結論

ここまで、マイクロサービスタスクスケジューリングプラットフォーム SIA-TASK について、設計背景、アーキテクチャ設計、製品コンポーネントの機能と特徴など、簡単に紹介してきました。マイクロサービスタスクスケジューリングプラットフォーム SIA-TASK は、基本的に現在のビジネスニーズを解決し、シンプルで効率的なオーケストレーションおよびスケジューリングサービスを提供します。 SIA-TASKは今後も改良を重ね、より充実したサービスを提供してまいります。関連する技術文書と使用方法文書も後日提供されます。

[この記事は51CTOコラムYiXin Technology Institute、WeChatパブリックアカウント「YiXin Technology Institute（id：CE_TECH）」からのオリジナル記事です]

この著者の他の記事を読むにはここをクリックしてください

<<: UCloud UDBテクノロジーの実践を探る

>>: 最適なクラウドバックアップソリューションを選択する方法