Skip to main content
Version: Next

Newbe.Claptrap を選択する理由

この記事では、Newbe.Claptrap プロジェクトの本文の概要について説明します。

車輪は需要から生まれた#

インターネットアプリケーションの急速な発展に伴い、関連する技術理論と実現手段が継続的に作成されています。「クラウド ネイティブ アーキテクチャ」、「マイクロサービス アーキテクチャ」、「DevOps」などのキーワードは、エンジニアの視点にますます登場しています。要約すると、これらの新しい理論と新技術の出現は、インターネットアプリケーションにおけるいくつかの技術的な問題を解決することを:

容量の拡張性を高めるには、。ビジネスの成功を前提に、インターネット アプリケーションのユーザー数、システム圧力、ハードウェア デバイスの数は、時間の経過と共に大幅に増加します。これは、州の容量のスケーラビリティを適用するための要件を提起します。この容量のスケーラビリティは、多くの場合、"アプリは水平方向のスケーラビリティをサポートする必要がある" と記述されます。

システムの安定性を高めるには、。アプリケーションは中断なく動作し、このアプリケーションに関連するすべての人が望むビジネス活動の継続的な進歩を保証します。しかし、これを行うには、通常、非常に困難です。今日のインターネットアプリケーションは、多くの同様の競合他社に直面して、この点で十分に健全ではない場合、ユーザーの一部の好意を失う可能性が高いです。

機能拡張性を高めるには、。「変化を受け入れる」とは、人々が「アジャイルプロジェクト管理」に関連する何かについて言及するとき、一つの言葉です。この用語は、今日のインターネットアプリケーションが成功するためには、機能的に成功することがいかに重要であるかを完全に反映しています。また、現在のインターネット環境における製品需要の変化も反映しています。システム エンジニアとして、アプリケーションの確立の初期段階で考慮する必要があります。

の使いやすさを高めるには、。ここでいう開発の容易さは,アプリケーションシステム自体の開発の容易さである.開発を容易にし、独自のコード構造、テスト可能性、および展開可能性を適用するには、適切な努力が必要です。

パフォーマンス要件が高い場合。ここでいう性能要求とは,特にシステム容量が増加した場合の性能要求である.システムの単一ポイント パフォーマンスの問題を回避し、アプリケーション システムを水平方向に拡張できます。通常、パフォーマンスに問題がある場合、物理デバイスを追加することで問題を解決できる最も簡単な方法です。システムパフォーマンスの最適化スキームは、通常、異なるシステム容量で異なります。したがって、アプリケーションシナリオと組み合わせた技術スキームの選択は、常にシステムエンジニアが考慮する必要がある問題です。

このプロジェクトは、上記のシステム機能要件に基づいて要約された開発フレームワークのセットです。これには、関連する理論的基礎、開発ライブラリ、および技術プロトコルが含まれています。

世界には「銀の弾丸」は存在しない。フレームワークのセットは、すべての問題を解決しません。 - 匿名を条件に月が落ちる

需要から#

分散システムについて説明するときは、多くの場合、アカウント転送という単純なビジネス シナリオを使用します。ここでは、このビジネス シナリオについて説明します。

たとえば、アカウント システムを備えたビジネス システムを構築する必要があります。各アカウントには残高があります。これで、アカウント A の残高の 300 をアカウント B に転送する転送操作が必要です。また、前のセクションの基本的な要件に基づいて、このシナリオを実装する際には、次の点を考慮する必要があります:

  • システム容量の急増に対応する必要があります。アプリの初期には、最初のユーザーが 1000 人しいる場合があります。アプリのプロモーションとロボットアカウントの流入により、ユーザー数は1ヶ月で3つの大きな増加、すなわち100万レベルまで増加しました。
  • システムの安定性と回復性を考慮する必要があります。システム全体の平均故障時間を最小限に抑え、システム障害が発生した場合でも、可能な限り簡単に回復できる必要があります。つまり、単一障害点を回避します。
  • ビジネスのスケーラビリティを考慮する必要があります。その後、いくつかのビジネスロジックを追加する必要があります:アカウントレベルに応じて1日の転送を制限し、転送が成功した後にSMS通知を行い、転送は、特定のアカウントで「T+1」アカウントを達成するために、一定の金額の秘密の転送をサポートします。
  • コードのテスト可能性を考慮する必要があります。システムのビジネス コードとシステム コードは適切に分離され、単体テストによってビジネス コードとシステム コードの正確性とパフォーマンスを暫定的に検証できます。

車輪の理論#

このセクションでは、読者がフレームワークの作業プロセスを理解しやすいように、フレームワークと密接に統合された理論的な要素をいくつか紹介します。

アクタ モード#

アクタ モードは同時実行プログラミング モデルです。このプログラミング モデルの適用により、一部のシステムの同時実行の問題を解決できます。ここで説明する同時実行の問題は、コンピュータが同じデータを論理的に処理するときに、同時に開始される複数の要求が存在するためにデータが正しくない可能性がある問題を指します。この問題は、マルチスレッド プログラミング中に発生する必要があります。簡単な例として、同期ロックなしで 100 スレッドを使用して、メモリ内の 1 つのint変数に対して++操作を同時に実行します。その後、最終的な変数の結果は 100 未満になる傾向があります。ここでは、アクタ モードがこの問題を回避する方法について説明します。

まず、理解しやすいように、読者はここでアクタをオブジェクトと見なします。オブジェクト指向言語 (Java、C# など) では、Actor はnewキーワードを使用して作成されたオブジェクトであると考えます。ただし、このオブジェクトには特別な機能があります:

自身の状態を持つ。オブジェクトは、オブジェクト指向言語が基本的に持っている独自のプロパティを持つ可能性があります。アクタ モードでは、これらのプロパティはまとめてアクタの状態 (State) と呼ばれます。アクタの状態は、アクタ自体によって維持されます。

これは2つの点を強調します:

まず、アクタの状態はそれ自体によってのみ変更できますが、アクタの状態を外部から変更するには、アクタを呼び出すことによってのみ変更できます。

アクタの状態を更新します

第 2 に、アクタの状態はアクタ内でのみ維持され、現在のアクタ以外のオブジェクトと共有されません。ここでいう非共有とは,外部属性の変更によってアクタの内部状態の変化を引き起こできないことを強調する.これは主に、オブジェクト参照言語機能を持つ一部のプログラミング言語と区別するために行います。例如:在 C#的 class 的 public 属性,假如是引用类型,那么在外部获得这个 class 之后是可以改变 class 中的属性的。ただし、これはアクタ モードでは許可しません。

アクタの状態を共有します

ただし、Actor 内から外部にデータを読み取ることができますが、これは許容されます。

アクタの状態を読み取ります

スレッド。通常、アクタは同時に 1 つの呼び出ししか受け付けられません。ここでいうスレッドとは、コンピュータ内のスレッドを意味するのではなく、「アクタが一度に 1 つの要求しか処理できないという特徴」を強調するために使用される単語です。現在のアクタが呼び出しを受け入れる場合、残りの呼び出しはブロックされ、呼び出しが終了するまで次の要求は許可されません。これは、同期ロックのメカニズムに似ています。これにより、アクタの内部状態を変更するときに同時実行の問題が発生する可能性が回避されます。具体一点说明:如果使用 100 个线程对一个 Actor 进行并发调用,让 Actor 对状态中的一个 int 变量进行 ++ 操作。最終的な状態の値は 100 である必要があります。

アクタを同時に呼び出します

ただし、シングル スレッドも絶対ではなく、同時実行の問題がない要求では、同時実行処理が許可されます。たとえば、通常、同時実行の問題を持つアクタの状態を読み取る場合、この時点で同時実行操作が許可されます。

アクタを同時に読み取ります

アクタのシングルスレッド機能について読んだとき、読者は、通常、アクタ自体の処理が遅くなり、パフォーマンスの問題を引き起こすかどうかを考慮しますか?これについては、読者がこの質問を保持し続け、答えを探し続けることを願っています。

イベント トレーサビリティ モード#

イベント トレーサビリティ パターンは、ソフトウェア設計のアイデアです。この設計思想は、通常、CRUD ベースのシステム設計の従来の方法とは異なります。CRUD アプリケーションには、通常、いくつかの制限があります:

  1. 通常、CRUD アプリはデータ ストアを直接操作します。このような実装は、データベースの最適化が不十分なためにパフォーマンスのボトルネックを引き起こす可能性があり、アプリのスケーリングが困難になります。
  2. 通常、特定の領域では、データ更新のエラーを防ぐために、同時実行の問題を処理するために注意する必要があるデータがあります。通常、このような問題を回避するには、"ロック" や "トランザクション" などの関連テクノロジを導入する必要があります。ただし、パフォーマンスが低下する可能性があります。
  3. データの変更履歴は、通常、追加の監査手段を追加しない限り追跡できません。通常、データ ストアにはデータの最終状態が保存されます。

CRUD アプローチとは対照的に、イベント トレーサビリティは、上記の制限を設計的に回避します。次に、上記の「転送」ビジネス シナリオを中心に、イベント トレーサビリティの基本的な動作について簡単に説明します。

CRUD アプローチを使用して "転送" を実装します。

CRUDによる「送金」の実現

「転送」は、イベントトレーサビリティによって達成されます。

イベントトレーサビリティによる「転送」

上の図に示すように、転送業務に関連する残高の変更は、イベント トレーサビリティ パターンによってイベントとして格納されます。また、ビジネス自体も実現しますが、これはいくつかの利点をもたらします:

  • イベントを使用すると、口座番号の任意の段階で残高を復元し、口座残高の追跡をある程度実現できます。
  • 2 つのアカウントのイベントは個別に処理されます。したがって、2 つのアカウントの処理速度は互いに影響しません。たとえば、アカウント B の転送は、追加の処理が必要な場合に若干の遅延が発生する可能性がありますが、アカウント A は引き続き転送できます。
  • イベントをサブスクライブすることで、ビジネスの非同期処理を行うことができます。たとえば:データベースの統計を更新したり、SMS 通知を送信したりするその他の非同期操作があります。

もちろん、イベントトレーサビリティパターンの導入は、イベントトレーサビリティに関連するいくつかの技術的な問題を導入します。たとえば:イベントによって消費されるストレージは膨大であり、最終的な整合性を適用する必要があり、イベントは不変であり、リファクタリングが困難になる可能性があります。これらの問題については、いくつかの記事でより詳細に説明されています。読者は、理解と評価のために、後続の拡張読書を読むことができます。

システム設計の変更によってビジネスの複雑さが軽減されるわけではなく、ある場所から別の場所に移動するだけです。 ――いつも自分の料理の月が落ちると言います

車輪を回せ#

読者が前節の理論を大いに理解した上で、このセクションでは、上記の「転送」ビジネス シナリオと組み合わせて、フレームワークのしくみを紹介します。まず、読者はこのフレームワークの 2 つの名詞を理解する必要があります。

Claptrap#

Claptrap

Claptrap は、このフレームワークで定義されている特別なアクタです。上記のアクタの2つの特性に加えて、クラプトップは、以下の特性を有する:

状態はイベントによって制御。アクタの状態はアクタ内で維持されます。Claptrap についても同じことが言えますが、Claptrap の状態を変更すると、アクタ内の変更に加えて、イベントを通じてのみ変更できます。これにより、イベント トレーサビリティ モードとアクタ モードが組み合わされます。アクタの状態の正確性とトレーサビリティは、イベント トレーサビリティ モードによって保証されます。Claptrap の状態を変更するこれらのイベントは、Claptrap 自体によって生成されます。イベントは、外部呼び出しまたは Claptrap 内のクラス トリガー メカニズムによって発生する可能性があります。

Minion#

Minion

Minion は、このフレームワークで定義されている特殊なアクタです。は、Claptrap に基づいて行った調整です。これは、次の特性を持っています:

対応する Claptrap からイベントを読み取。Claptrap と同様に、Minion の状態もイベントによって制御されます。違いは、Minion は文字通り、対応する Claptrap からイベントを取得し、状態を変更する場合です。したがって、Claptrap がイベントを生成した後の後続の操作を非同期に処理できます。

ビジネスの実装#

次に、このフレームワークが前述の「転送」シナリオをどのように実装するかについて説明します。まず、次の図を使用して、主なプロセスを確認します:

Claptrap & Minion

上の図に示すように、プロセス全体は、このフレームワークがビジネス シナリオを実装するための一なるプロセスです。また、いくつかの点に注意を:

  • 図では、Client と Claptrap の呼び出しは、プロセス全体が終了するのを待つ必要がなくなり、Client が応答を高速化できる第 1 フェーズにのみ存在します。
  • Claptrap A は、独自の要求を処理し、Minion A にイベントを送信した後、要求を再受け入れ、Claptrap A のスループットを向上させます。
  • Minion は、Claptrap 間の呼び出しエージェントのみを処理する必要はありません。Minion では、ビジネス ニーズに基づいてテキスト メッセージを送信したり:データベース統計を更新したりすることもできます。
  • Minion は、対応する Claptrap からクエリを行うのではなく、外部からクエリを実行できるように、データの一部を独自の状態に維持することもできます。たとえば:、アカウントの過去 24 時間の転送の動きをカウントして、すばやく照会できます。

ビジネス容量#

このフレームワークは、ビジネス容量の継続的な増加に対応できる水平方向に拡張可能なシステム アーキテクチャを構築する必要があります。この点で、このフレームワークは、アプリケーションと物理デバイスのを実装するの Dapr を使用しています。

もちろん、データ ストレージの一部には、データベース クラスタなどの一連の問題も伴います。これらは、フレームワーク理論の設計ではなく、技術的なアプリケーションの詳細です。したがって、ここでは、フレームワークが上記のオープン ソース アーキテクチャに基づいて容量を縮小できる場合にのみ示します。

読者が後続のプロジェクト コンテンツで回答を求めることができます。

準備は万端です#

フレームワークの予備的な理解を得たと信じています。现在,进入Newbe.Claptrap 快速入门 开始尝试该项目吧。