前回の記事では、ドメイン モデリング、マイクロサービス設計、フロントエンド設計手法に焦点を当てました。これらを組み合わせて、ミドルエンド構築のための全体的なソリューションを形成できます。中台および台湾のプラットフォームのほとんどは分散型マイクロサービス アーキテクチャに基づいており、このエンタープライズ レベルのデジタル変革には、注目し考慮に値する側面が数多くあります。
エンタープライズビジネスモデル、ビジネス境界、フロントオフィスとミドルオフィスの統合に注意を払うだけでなく、データテクノロジーシステム、マイクロサービス設計、マルチアクティブなどの分野の設計とコラボレーションにも注意を払う必要があります。実装の経験と考え方を組み合わせて、今日は分散アーキテクチャの下でのいくつかの重要な問題について話します。
1. どのような分散データベースを選択すればよいですか?
分散アーキテクチャにおけるデータ アプリケーションのシナリオは、集中アーキテクチャよりもはるかに複雑であり、多くのデータ関連の問題が発生します。データに関しては、まず適切な分散データベースを選択する必要があります。
ほとんどの分散データベースは、データ アクセスの高パフォーマンス、マルチアクティブ、災害復旧を実現するために、データの複数のコピーを使用します。現在、主に 3 つの異なる分散データベース ソリューションがあります。それらの主な違いは、データの複数のコピーとデータベース ミドルウェアを処理する方法です。
1. 統合分散データベースソリューション
データの複数のコピーと高可用性をサポートします。Paxos プロトコルが主に使用され、複数のデータ コピーが一度に書き込まれます。ほとんどのコピーが正常に書き込まれた場合、成功とみなされます。代表的な製品としてはOceanBaseやGaussianデータベースなどがあります。
2. 集中データベース＋データベースミドルウェアソリューション
集中データベースとデータベースミドルウェアを組み合わせたソリューションであり、データベースミドルウェアによるデータルーティングとグローバルデータ管理を実現します。データベースミドルウェアとデータベースは独立して展開され、データベース自体の同期メカニズムを使用してマスターコピーデータの一貫性が実現されます。集中型データベースには主に MySQL データベースと PostgreSQL データベースが含まれており、これら 2 つのデータベースに基づいて、オープンソース データベース ミドルウェア MyCat+MySQL ソリューション、TBase (PostgreSQL をベースとしていますが、比較的大規模なパッケージ化と変更が加えられています) やその他のソリューションなど、多くのソリューションが派生しています。 。
3. 集中データベース + サブライブラリ クラス ライブラリ ソリューション
これは軽量のデータベース ミドルウェア ソリューションであり、サブライブラリ クラス ライブラリは実際には基本的な JAR パッケージであり、データ ルーティングとデータ収集を実装するためにアプリケーション ソフトウェアと一緒に展開されます。これは、比較的単純な読み取り/書き込みトランザクション シナリオに適していますが、強整合性と集計分析クエリに関しては比較的弱いです。典型的なサブライブラリの基本コンポーネントには、ShardingSphere が含まれます。
4. まとめ
3 つのソリューションの導入コストは異なり、ビジネスサポート機能も大きく異なります。統合分散データベースは大手インターネット企業を中心に開発され、超強力なデータ処理能力を備えていますが、その多くはクラウドコンピューティング基盤を必要とし、導入コストや技術力が比較的高くなります。一元化されたデータベース + データベース ミドルウェア ソリューションは、導入コストと技術力が中程度であり、中規模および大規模企業のビジネス要件を満たすことができます。3 番目のサブライブラリ クラス ライブラリ ソリューションは、単純なビジネス シナリオを処理でき、コストとスキル要件は比較的低いです。データベースを選択するときは、自社の機能、コスト、ビジネス ニーズを考慮して適切なソリューションを選択する必要があります。
2. データベースサブデータベースの主キーをどのように設計するか?
分散データベースを選択した後の 2 番目のステップは、データ サブデータベースを検討することですが、このとき、サブデータベースの主キーの設計が非常に重要です。
顧客に連絡するという重要な業務では、顧客 ID をサブデータベースの主キーとして使用することをお勧めします。これにより、同じ顧客のデータが同じデータ ユニットに確実に分散され、データ ユニット間での頻繁なデータ アクセスが回避されます。データセンター間での頻繁なサービスコールやデータユニット間でのクエリは、システムのパフォーマンスに致命的な影響を与えます。
すべての顧客データを同じデータユニットに入れることで、顧客は一貫したサービスを提供しやすくなります。企業にとって、「顧客中心」のビジネス機能は、まずデータの観点から「顧客中心」でなければなりません。
もちろん、組織やユーザーなどのビジネス ニーズに応じて、他のビジネス属性をサブデータベースの主キーとして使用することもできます。
3. データベースデータの同期とレプリケーション
マイクロサービス アーキテクチャでは、データはさらに分割されます。データ統合を実現するには、データベース間のバッチデータ同期とレプリケーションが不可欠です。データの同期とレプリケーションは主に、ビジネス データの移行、データ バックアップ、さまざまなチャネルからデータ プラットフォームまたはデータ センターへのコア ビジネス データのデータ レプリケーション、およびさまざまな対象データの統合を実現するためのデータベース間のデータ同期に使用されます。
従来のデータ送信方法には、ETL ツールやタイミング引き出しプログラムが含まれますが、データには適時性の点で欠点があります。分散アーキテクチャは一般に、データベース ロジック ログに基づく増分データ キャプチャ (CDC) テクノロジーを採用しており、準リアルタイムのデータ複製と送信を実現し、データ処理とアプリケーション ロジックの分離を実現し、より簡単かつ便利になります。使用します。
主流の PostgreSQL および MySQL データベースには、多数のデータベース ログ キャプチャ テクノロジ コンポーネントがあります。CDC は、ドメイン イベントの増分データを取得するテクノロジとして、ドメイン イベント駆動設計でも使用できます。
4. データベース間の関連付けクエリをどのように処理するか?
データベース間の関連付けクエリは分散データベースの欠点であり、クエリのパフォーマンスに影響します。ドメインをモデル化する場合、多くのエンティティが異なるマイクロサービスに分散されますが、多くの場合、ビジネス要件により、エンティティ間の関連付けクエリが必要になります。
関連するクエリには 2 種類のビジネス シナリオがあります。
- 1 つ目のタイプは、特定のディメンションまたは特定の主題ドメインに基づくデータ クエリです。たとえば、顧客の完全なビジネス ビューに基づくデータ クエリで、複数の事業分野のマイクロサービスにまたがります。
- 2 番目のタイプは、組織テーブルとビジネス テーブル間の結合テーブル クエリなど、テーブル間の関連付けクエリです。ただし、組織テーブルとビジネス テーブルは異なるマイクロサービスに分散されています。
これら 2 種類の関連クエリを解決するにはどうすればよいでしょうか?
最初のタイプのシナリオでは、データがさまざまなマイクロサービスに分散しているため、複数のマイクロサービスにわたってこれらのデータをカウントすることはできません。さまざまなビジネスのマイクロサービスからデータを取得するトピック指向の分散データベースを構築できます。データベース ログ キャプチャ テクノロジーは、ビジネス側の各マイクロサービスから対象のデータベースにデータを準リアルタイムで収集するために使用されます。データを収集する場合は、事前にデータの関連付け（複数のテーブルのデータを 1 つの広いテーブルにマージするなど）を行うか、データ モデルを確立します。トピック データベース構築のためにマイクロサービスにクエリを実行します。このようにして、1 つのクエリで顧客のあらゆる側面のビジネス データを取得できます。テーマやシナリオに応じて適切なサブデータベースの主キーを設計して、クエリの効率を向上させることもできます。
2 番目のタイプのシナリオでは、同じデータベース内にないテーブル間の関連クエリ シナリオでは、小さなテーブル ブロードキャストを使用して、ビジネス ライブラリに冗長コード サブテーブルを追加できます。メイン テーブルのデータが変更されると、メッセージのパブリッシュとサブスクリプションのドメイン イベント駆動型モードを通じて、すべてのサブテーブル データを非同期的に更新できます。これにより、テーブル間の関連付けクエリを解決できるだけでなく、データ クエリの効率も向上します。
5. 高頻度のホットスポット データをどのように扱うか?
商品や機関などのコードデータなどの高頻度のホットデータの場合、複数のアプリケーションを同時に対象とするため、高い同時応答能力が必要です。これらはデータベースに多大なアクセス圧力をもたらし、システムのパフォーマンスに影響を与えます。
一般的な方法は、これらの高頻度のホット データをデータベースから Redis などのキャッシュにロードし、キャッシュを介してデータ アクセス サービスを提供することです。これにより、データベースへの負荷が軽減されるだけでなく、データ アクセスのパフォーマンスも向上します。
さらに、あいまいクエリを必要とする高頻度データの場合は、ElasticSearch などの検索エンジンを使用することもできます。キャッシュは調味料のようなもので、少ない投資ですぐに結果が得られ、ユーザー エクスペリエンスが迅速に向上します。
6. シーケンス前後のビジネスデータの処理
マイクロサービスを設計するとき、一部のデータを前のマイクロサービスのデータに関連付ける必要があることがよくあります。たとえば、保険ビジネスでは、保険申請マイクロサービスが保険申請フォームを生成した後、保険契約と以前の申請フォーム データなどが関連付けられます。電子商取引ビジネスでは、貨物納品書は以前の注文データに関連付けられます。関連データはビジネスの事前注文マイクロサービスに分散しているため、異なるマイクロサービスのデータベースを介してそれらのデータの関連付けを確立することはできません。
シーケンスの前後でこの種のエンティティの関連付けを解決するにはどうすればよいでしょうか?
一般に、シーケンス前およびシーケンス後のデータはドメイン イベントに関連しています。ドメイン イベント処理メカニズムを使用すると、オンデマンドでドメイン イベント エンティティを通じて予約注文データを現在のマイクロサービス データベースに送信し、冗長化できます。
予約注文データをエンティティまたは値オブジェクトとして設計し、現在のエンティティによって参照できるようにすることができます。設計するときは、次の点に注意する必要があります。 予約注文データが現在のマイクロサービス内で全体としてのみ変更可能で、クエリや統計分析を実行しない場合は、値オブジェクトとして設計できます。 ; 予約注文データが複数あり、クエリと統計分析を行う必要がある場合は、エンティティとして設計できます。
これにより、貨物輸送マイクロサービスで前回のオーダーの一覧データと貨物輸送オーダーのデータを一度に取得し、フロントエンドアプリケーションに一括でフィードバックすることができ、呼び出し回数を削減できます。マイクロサービス全体で。事前注文データがエンティティとして設計されている場合は、事前注文データをクエリ条件として使用して、ローカル マイクロサービスで多次元の包括的なデータ クエリを実行することもできます。必要な場合にのみ、プレオーダー マイクロサービスからプレオーダー エンティティの詳細データが取得されます。これにより、データの整合性が保証され、マイクロサービスの依存性が軽減され、マイクロサービス間の呼び出しが削減され、システムのパフォーマンスが向上します。
7. データセンターとエンタープライズレベルのデータ統合
分散型マイクロサービス アーキテクチャによりアプリケーションの柔軟性と高可用性が向上しますが、元の集中型データはマイクロサービスの分割により多くのデータ アイランドを形成し、データ統合とエンタープライズ レベルのデータ使用の困難さが増大します。データセンターを使用してデータ融合を実現し、分散アーキテクチャ下でのデータ アプリケーションと統合の問題を解決できます。
データセンターは 3 つのステップで構築できます。
- まず、統一データ標準に従って、さまざまなマイクロサービスとチャネル ビジネス データの収集と保存を完了し、データ アイランドとプライマリ データ共有の問題を解決します。
- 次に、テーマ別データ モデルを確立し、さまざまなテーマやシナリオに従ってデータを処理し、統合された顧客ビュー、エージェント ビュー、チャネル ビューなどのさまざまなテーマのデータ ビューを確立します。
- 第三に、ビジネスとビジネスモデルの革新をサポートするために、ビジネスニーズに基づいたデータシステムを確立します。
データセンターは分析シナリオに限定されず、トランザクション シナリオにも適用されます。データ ウェアハウスとデータ プラットフォーム上に構築し、フロントエンド ビジネスで使用するデータ プラットフォームを提供して、トランザクション シナリオのサポートを提供できます。
8. BFF とエンタープライズレベルのビジネスオーケストレーションとコラボレーション
エンタープライズ レベルのビジネス プロセスは、多くの場合、複数のマイクロサービスによって完了されます。単一責任の各マイクロサービスは構成要素のようなもので、独自の特定の機能のみを実行します。では、これらのマイクロサービスを組織してエンタープライズレベルのビジネスオーケストレーションとコラボレーションを完了するにはどうすればよいでしょうか?
マイクロサービスとフロントエンド アプリケーションの間に BFF マイクロサービスのレイヤー (フロントエンドのバックエンド) を追加できます。BFF の主な役割は、マイクロサービス間のサービスの構成とオーケストレーションを処理することです。マイクロサービスのアプリケーション サービスもサービスの構成とオーケストレーションを処理します。この 2 つの違いは何ですか?
BFF は中間プラットフォームのマイクロサービスの上に位置し、主な役割はマイクロサービス間のサービス調整です。アプリケーション サービスは主にマイクロサービス内のサービスの構成とオーケストレーションを扱います。設計時には、再利用可能なサービス機能をできる限り下位層に預けることで、機能の再利用を実現しながら、センターを越えたサービス呼び出しを回避することができます。
BFF は、フロントエンド アプリケーションとマイクロサービスの間のペースを調整するための歯車のようなものです。ファサード サービスを通じてさまざまなフロント エンドを適応させ、サービスの構成とオーケストレーションを通じてマイクロサービスを編成および調整します。BFF マイクロサービスは、要件やプロセスの変化に応じてフロントエンド アプリケーションのバージョンと連携してリリースできるため、フロントエンド要件の変化に適応するために中間段階のマイクロサービスを頻繁に改訂したりリリースしたりする必要がなくなり、それによってロジックの安定性が確保されます。マイクロサービスのコアドメイン。
BFF が十分に強力であれば、それはさまざまなミドルエンド機能とマイクロサービス機能を統合し、マルチチャネル アプリケーションを指向したビジネス機能プラットフォームになります。
9. 分散トランザクションまたはイベント駆動メカニズム?
分散アーキテクチャでは、元のモノマーの内部呼び出しは分散呼び出しになります。操作に複数のマイクロサービスのデータ変更が含まれる場合、データの整合性の問題が発生します。データの整合性には強整合性と最終整合性の2種類があり、実装スキームや実装コストが異なります。
高いリアルタイム要件を持つ強力な整合性のビジネス シナリオでは、分散トランザクションを使用できますが、分散トランザクションにはパフォーマンス コストがかかります。設計時には、ビジネスの分割、データの一貫性、パフォーマンス、および実装の複雑さのバランスをとる必要があります。分散トランザクションの生成を回避します。 。
ドメイン イベントによって駆動される非同期手法は、分散アーキテクチャの一般的な設計手法であり、非リアルタイム シナリオにおける最終的なデータの一貫性の問題を解決できます。メッセージ ミドルウェアに基づくドメイン イベントの発行とサブスクリプションは、マイクロサービスを適切に分離できます。山を削り谷を埋めることで、リアルタイムのデータベース アクセスへのプレッシャーが軽減され、ビジネスのスループットと処理能力が向上します。イベント駆動によって読み取りと書き込みの分離を実現し、データベース アクセスのパフォーマンスを向上させることもできます。最終的な整合性のシナリオでは、ドメイン イベント駆動型の設計アプローチを採用することをお勧めします。
10. マルチセンターおよびマルチアクティブ設計
分散アーキテクチャの高可用性は主にマルチアクティブ設計によって実現されます. マルチセンター マルチアクティブは非常に複雑なプロジェクトです. 以下に主に以下の設計を列挙します.
1. 適切な分散データベースを選択します。
データベースは、複数のデータセンター展開をサポートし、データの複数のコピー、基礎となるデータの複製と同期、およびデータ回復の適時性の技術要件を満たしている必要があります。
2. ユニット化されたアーキテクチャ設計。
複数のアプリケーションで構成されるビジネスユニットを導入の基本単位として、同一都市内、異なる場所へのマルチアクティブ導入やセンター間での柔軟な拡張を実現します。各ユニットのビジネス機能は自己完結型であり、すべてのビジネス プロセスはこのユニット内で完了できます。どのユニットのデータも複数のデータ センターにコピーがあり、障害によるデータ損失は発生しません。ユニットの障害は影響を及ぼしません。他の同様のユニットの通常の動作。ユニットを設計するときは、データセンターやユニット間での呼び出しを避けるように努める必要があります。
3. アクセスルーティング。
アクセス ルーティングには、アクセス層、アプリケーション層、およびデータ層でのルーティングが含まれており、フロントエンド アクセスがルーティングに従ってデータ センターおよびビジネス ユニットに正確に到達し、ビジネス データが配置されているデータベースに正確に書き込みまたは取得できるようにします。
4. グローバル構成データ管理。
各データセンターのグローバル構成データの一元管理を実現し、各データセンターのグローバル構成データをリアルタイムに同期してデータの整合性を確保します。
要約する
エンタープライズレベルの分散アーキテクチャの実装は、多くの技術システムと手法が関与する非常に複雑なシステム エンジニアリングです。今日は 10 の主要な設計領域を挙げましたが、それぞれの領域は実際には非常に複雑で、多大な投資と研究が必要です。実装する場合、あなたとあなたの会社は、自社の状況に基づいて適切な技術コンポーネントと実装ソリューションを選択する必要があります。