アーキテクチャ設計:データサービスシステム0対1の実装計画

この記事のソースコード:GitHub・ここをクリック|| GitEE・ここをクリック

1.ビジネスに基づく

データサービスには通常、多くのビジネスモデルがあり、複雑なシステムアーキテクチャとビジネスにつながります。さまざまなビジネスには独自の機能と複雑さがあります。データ管理自体は簡単な作業ではないため、システムアーキテクチャの初期段階では、サービス機能を考慮したビジネスシナリオは次のとおりです。

APIサービス:HTTPモードに基づくデータサービス。リスク管理モデル、スコアリング、不正防止、その他のサービスなど、リクエストを通じてデータを取得します。

プラットフォームサービス:カスタマイズされたサービスに対する顧客の需要が少ない包括的なサービス機能統合システム、およびマーケティング用の完全なプロセス管理機能を提供する自動デジタルマーケティングプラットフォームなどの完全なプロセスデータサービス機能。

収集サービス:通常、顧客はポイントを埋める方法で関連するクリックイベントを送信し、収集システムはオムニチャネルに基づいて要約分析を実行し、顧客にフィードバックを提供します。

視覚的分析:これは、データ分析と視覚化の2つの主要な領域に分けられます。データは、共同分析のために複数のデータソースにロードでき、一般的なデータインサイトシステムなどのフロントエンドコンポーネントに基づく高度に自動化された分析です。

ツールの民営化:蓄積された技術的能力に基づいて、データ管理システムを顧客に直接販売し、それらを独自のローカルサービスに展開します。

データサービスシナリオでは、さまざまなビジネスがそれぞれのシナリオでデータサポートを必要としますが、さまざまなビジネスは、運用、決済、注文などの同じ基本機能を必要とします。さまざまなビジネスシナリオを理解するには、共通点と相違点を見つけるのは非常に簡単です。アイデア:システムの継続的な拡張と進化を促進するために、類似点はパブリックサービスで開発され、ビジネスの違いは独立したサービスで開発されます。

2、ビジネス層アーキテクチャ

異なるデータサービス機能の最大の違いは、コアデータのサポートに依存する必要があることです。ビジネスの観点から、システムアーキテクチャレイヤーには複雑なパブリック機能も必要です。そうでない場合は、アーキテクチャの初期段階で検討する必要があります。事業は急速に発展し、復興の問題に直面しようとしています。

顧客の操作:各顧客のアクセスには、手順、サービスの説明、請求ルール、契約管理、再充電、サービスのアクティブ化と非アクティブ化、請求、および一連のサポート機能の完全なセットが必要です。通常、2つの入り口があります。顧客ログイン終了、サービス側操作終了。

支払いと決済:顧客のリチャージと払い戻し、またはサービスパーティ自身の支払いニーズを解決するために複数の支払いチャネルを集約するなどの支払い機能を提供し、さまざまな決済請求書データ出力と調整バランス機能を提供する最も複雑なシステムモジュール。

注文管理:各顧客の要求、または各サービスの使用には、単価、注文番号、および時間を含む請求アクションの詳細な注文レコードが必要です。決済のコアベースとして、最も集中したビジネスデータでもあります。場所発生が発生した場所。

権限システム:データサービスシステムでは、権限システムの設計は、会社の本体のニーズの解決に重点を置いています。さまざまなビジネスチームがさまざまなサービス運用、顧客管理などを担当するため、明確で体系的な権限管理が行われます。さまざまな役割に必要です。ビジネス担当者は適切な権限を割り当てます。

ログ統合:詳細ログシステムでは、サービスが異常な場合のデータ完了分析に通常のビジネスログデータを使用でき、開発者がシステムの問題やボトルネックを分析してサービス機能を継続的に最適化するために異常なログデータを使用できます。

ビジネスシナリオに基づくサービスの分割と設計、および公共サービスの基本的な構築により、ビジネスレイヤーの構造が合理的かつスケーラブルであることが保証されます。合理的であるかどうかの基本的な考慮事項は、継続的な新しいビジネスシナリオが必要かどうかです。システムの大幅な改訂。サービス容量が継続的に強化されている場合、システム変換のコストは小さく、自然な構造は合理的です。

3.データセンター

さまざまなビジネスサービスシナリオは、コアデータ機能に依存する必要があります。これがサービスのセールスポイントです。サービス機能をサポートするコアデータは、通常、個別に展開され、通常はデータセンターとして理解されるさまざまなサービスシナリオを提供します。同時に、ビジネスサービス自体もさまざまなデータを生成します。ここでは、サービスの展開方法に応じて個別に保存されます。

サービス機能:複数の企業の公的な依存関係として、データセンターはデータベースのクエリ機能を提供するだけでなく、大規模なデータタスクを処理するときに特定のスケジューリングとコンピューターシステムを提供する必要があります。

展開方法:データの特性に応じて、通常、クラスター、サブデータベースとテーブル、OLAPエンジン、データウェアハウスなどのさまざまな方法で格納され、データの特性に基づいて統合されたサービス機能を提供します。ビジネス層に開かれています。

データの更新:データはリアルタイムまたは定期的に更新する必要があります。データのソースは通常、ビッグデータによって計算および処理されるさまざまなデータ、ビジネスレイヤーによって誤って検証されたデータ、または使用中に継続的に最適化されるデータです。

データセンターの独立したアーキテクチャの展開は非常に必要な操作です。ほとんどのデータはリンクされています。データ間のリンク処理はビジネスレベルに結合する必要はありません。データのフロー、修正、セキュリティ管理などは可能です。すべてがデータセンターにあります。統合管理により、データの混合展開によって引き起こされる一連の複雑な問題が回避されます。

第四に、ビッグデータの最下層

最も低いレベルのデータサービス機能には大規模なデータ処理機能が必要であるため、データの保存、計算、分析、および移動には多くのビッグデータコンポーネントテクノロジーが使用されます。

データストレージ:ビッグデータの下部にある最も一般的なストレージは、ファイル、構造化データベースストレージ、半構造化ログファイル、および一部の非構造化データの形式です。

コンピューティング能力:大量のデータの処理は、迅速な処理の目的を達成するために、さまざまな並列コンピューティング、オフラインタスク、リアルタイムコンピューティング、およびその他の方法に依存する必要があります。

データ処理:データ処理が完了した後、サービス機能は最下層で直接提供されません。データは通常、ビジネスにサービス機能を提供するために上位のデータセンターに同期されます。ここでの処理は、処理されるデータ出力またはデータ入力です。 。

ビッグデータの基盤となるコンポーネントはシステムのコア機能です。データの正確な計算と分析によりサービス機能が保証され、既存のアーキテクチャの継続的な自動化とツールベースの管理が非常に重要です。大規模なデータ管理のプロセスはより手動です。特にデータをデータセンターにプッシュしたり、最下層でデータを受信したりする過程では、効率が低下することを意味し、安全で安定したデータの自動送信を確保するための戦略に合意する必要があります。

5、全体的な考慮事項

複雑なシステムを設計する場合、最も重要なことは、ビジネスモデルを明確に分類し、ビジネスモデルを分析し、ビジネス特性に基づいてシステムアーキテクチャを作成して、上記のデータサービスシステムなどの多くの迂回を回避することです。

まず、大きな観点から、システムはビジネスサービス、データセンター、ビッグデータの基盤となる機能の3つの主要部分を分割し、モジュールを拡張できるようにするために、各大きなモジュール間に強い結合関係がないことを要求します。独立して;

次に、各モジュールに必要なコア機能を決定します。ビジネス層は基本的なサービス機能を保証し、次に各ビジネスに必要な基本機能を抽出してカプセル化し、ビジネスサービスと公共サービスを分割し、ビジネス機能をサポートします。

次に、ビジネスとデータセンター間の通信機能、インターフェイス標準、データセキュリティなどの詳細、またはデータセンターと基盤となるビッグデータ間のデータ処理モードなど、さまざまなモジュール間のコラボレーションモードを決定します。データ循環機能;

最後に、各モジュールの具体的な詳細を実装します。ここで考慮する必要があるのは、ビジネスモデルに従って、同じコンポーネントとアーキテクチャメソッドを選択できる場合は、アーキテクチャの選択とコンポーネントの依存関係を統一し、障壁を減らすようにすることです。異なるモジュール間;

上記の完全なシステムアーキテクチャは、設立開始から安定したサービス機能の提供まで約7か月かかります。この間、絶えず進化とアップグレードが行われ、新しいサービスモジュールが継続的に起動され、システム監視が実行されます。ビジネスサービスは比較的完全で体系的で、比較的安定しています。

6、ソースコードアドレス

GitHub地址:知了一笑
https://github.com/cicadasmile/spring-cloud-base
GitEE地址:知了一笑
https://gitee.com/cicadasmile/spring-cloud-base

ラベルを読む

[ Java Foundation ] [デザインパターン] [構造とアルゴリズム] [ Linuxシステム] [データベース]

[分散アーキテクチャ] [マイクロサービス] [ビッグデータコンポーネント] [ SpringBoot Advanced ] [ Spring&Boot Foundation ]

[データ分析] [テクニカルマップ] [職場]

おすすめ

転載: blog.csdn.net/cicada_smile/article/details/114004495