OSS.Coreの基本的な考え方

フレームワークという言葉が話題になっている昨今、xx社のアーキテクチャデザインは、そのほとんどが単なる遊びであり、どのようにしてそのフレームワークが生まれ、どのように細部が考えられているのか。それらの間の分離の根拠は何ですか? 特に人気が高まっているマイクロサービスとその派生マイクロサービス ゲートウェイ製品については、まだ疑問を抱いている人も多いと思います。この記事は、その過程で考えたことを記録したものであり、おそらく次のような疑問を中心に皆さんが理解できるようになることを願っています:

1. マイクロサービスの起源

2.マイクロサービスの設計思想

3. OSS.Core フレームワークの設計と実装

その話を始める前に、まず、従来のアーキテクチャとマイクロサービス アーキテクチャが互いに独立/対立するものではないことを理解していただきたいと思います。マイクロサービスは、同時メンテナンスなどの問題に対処するために従来のフレームワークから派生した論理的な概念であり、プロジェクトのさまざまな段階での考え方や問題解決の方法を変えることを意味します。次に、論理アーキテクチャと物理アーキテクチャ (ファイル) を区別します。ほとんどの場合、論理アーキテクチャは物理アーキテクチャに対応しますが、物理アーキテクチャに複数の論理アーキテクチャが含まれる場合があります。

1. マイクロサービスの起源

マイクロサービスは主に、いくつかの大規模で複雑なアプリケーションを複数のサービスの組み合わせに分解し、各サービスは自律しており、より柔軟で簡単なメンテナンス効果を実現します。

理解を深めるために、まず同時実行性を解決する 3 つの一般的な方法を見てみましょう:

1. データベースのマスターとスレーブの分離、さらにはマルチマスター書き込みやパーティション化メカニズムを追加し、それに応じて接続文字列を変更するか、アクセス権を追加します

ミドルウェア データベース処理能力を向上させます。

2. データベースのリソースは比較的逼迫しており、時間がかかるため、アクセス速度を向上させるために、分散

キャッシュなどを使用して下位層へのアクセスを減らすのが一般的です。

3. 負荷分散オフロード処理では、大量のリクエストがアプリケーションに到着する前に、リクエストを異なるマシンに分散して、単一マシンの帯域幅とパフォーマンスのボトルネックの問題を解決します。

もちろん、フロントエンド

静的ファイル圧縮、CDNアクセラレーション、IPレート制御など、同時実行性を解決する方法は他にもたくさんありますが、ここでは省略します。

上記の 3 つの方法をここにリストした理由は、この図と組み合わせることで、従来のサービス全体とマイクロ サービスの変更を比較しやすくなるからです。サービス フレームワーク全体では、モジュール間の結合、プロジェクト内の相互呼び出し、およびさまざまな複雑な集計操作が多く存在するため、ほとんどの場合、全体としてしかデプロイできません。左の図では、負荷分散を行う場合、全体として複数のマシンにデプロイする必要があります。データベースについても同様で、プロジェクト内の各モジュールのニーズは異なります。

例: 製品モジュールと注文モジュールのアクセス頻度とプロセスの複雑さは大きく異なります。注文頻度は比較的低く、比較的少数のマシンで実行する方が便利で高速です。トラブルシューティングとメンテナンス。右の図にあるように、サービスを細分化した後、状況に応じて、より小さな展開単位を使用してそれらを組み合わせることができます。

同時に、インターネット製品が急速に反復されている今日の時代では、製品には、さまざまな端末向けにさまざまなアプリケーション機能を迅速に起動する機能が必要であり、同時に従来の全体的なビジネス調整を迅速に起動できる必要があります。サービスモデルだけではもはや十分ではありません。マイクロサービスはパーツに分割されているため、各モジュールは独立しているため素早く組み合わせることができ、各モジュールは異なる需要点に応じて異なる特性を持つ

プログラミング言語

を使用することができます。

2. マイクロサービスの設計思想

各プロダクトには独自の基準と優先順位があるため、サービス単位の設計も異なりますが、最も基本的な点は次のとおりです:

サービスの自律性

マイクロサービス モジュールを設計するときは、現在のサービスの独立性、特にデータ モジュールの独立性を確保する必要があります。他のサービスには、現在のサービスの下でのみデータベース モジュールを直接操作する権限がありません。サービスインターフェースを通じて。モジュールは独立しているため、適切なプログラミング言語と対応する導入規模を選択できます。ローカルでの柔軟な最適化を実現します。マイクロサービスは互いに独立しており、上記の利便性をもたらしますが、直面する必要のあるいくつかの問題ももたらします:

まず第一に: 現在のサービスの境界を定義する方法と、現在のサービスガバナンスの範囲を決定する方法。

サービス単位を最小化するため、サービスの責任境界を決定する必要があります。サービスライフサイクルプロセス、エリア、推定を組み合わせることが推奨されます。スケール これらの点を考慮すると、たとえばユーザーサービスでは、訪問数が少なく人が少ない場合、基本的なユーザー情報と残高口座をサービスモジュールの下に配置して、作業負荷と集中力を減らすことができます。規模が大きい場合は、基本サービスとアセットサービスに分けることができます。

2番目: クロスサービスデータ クエリ 問題

例えば、クライアントで製品を検索する方法、ユーザーの検索や統計データのクエリなども可能です。これを処理する 2 つの方法を紹介します:

1. API Gateway

この状況は、サービス ユニットが多すぎて、クライアントが異なるサービス ユニットのデータをクエリする必要がある場合に適しています。 API サービス ゲートウェイを構築します (APP ゲートウェイとは異なることに注意してください)。クライアントは、現在のゲートウェイと対話するだけで済み、それらを集約して別のマイクロサービスに転送します。以下に示すように:

2. データの冗長性またはバックグラウンドデータの同期

たとえば、注文情報には、ユーザーの名前などのいくつかのユーザーフィールドが必要です。現時点では、これらのフィールドを完全に冗長化できます。モジュールの下のマイクロサービス データを注文します。別の例として、統計モジュールでは、データ プロデューサーとクエリーがまったく異なる オブジェクト に属しており、あまりリアルタイムではないため、統計サービスと、それに対応する他のサービスが event メッセージを通じて対話することをお勧めします。対応する統計データを 更新します。これは、クエリ時に統計サービス内の独自のデータを使用して完了できます。

もう一度：サービス間の通信問題を解決する方法

それは、サービスを互いに独立させ、異なるサービスデータベースを直接操作する可能性を遮断したためです。では、データの一貫性をどのように扱うのでしょうか? 従来のサービス モデル では、それらがすべて混在しているため、トランザクションまたは ストアド プロシージャ を通じてデータの一貫性を確保できます。一般的な方法は 2 つあります:

1. 非同期イベント メッセージ ドライバー

このタイプのソリューションは、上記の統計サービスの更新、サービスのイベント トリガーなど、リアルタイム データに対する要件が比較的低いシナリオに適しています。次に、応答メッセージ通知をメッセージ キュー にプッシュし、このキューのサービスに登録して更新されたデータを受信します。図に示すように:

2. 直接インターフェースリクエスト(HTTP、RPC)

カスケード依存関係を防ぐことは一般的に推奨されません。このタイプのリクエストは主に、リアルタイム データ要件の高いリクエストを対象としています。たとえば、フラッシュ セールの注文プロセス中に、在庫サービスの控除が成功したかどうかをすぐに知る必要があります。 (注: .net でのタスクのサポートはすでに非常に優れています。IO 操作によるワーカー スレッドの消費を減らすために、非同期 http リクエストを使用することをお勧めします。フロントエンドは Task<ActionResult> を返します)

最後に: クライアントへのアクセス方法

サービスをカプセル化した後、サービスと最終クライアントがアクセスする方法は、実際のセキュリティのルールと要件に従って決定する必要があります。一般的に、サービスが比較的小さい場合、関数はカウントされません。図に示すように、サービス インターフェイスをクライアントに直接公開してアクセスすることもできます。または、

API の形式でクライアントに提供することもできます。前述のゲートウェイ

もちろん、成熟したマイクロサービス ゲートウェイも多数あります。たとえば、Azure クラウド上の Service Fabric や API Management の両方が利用可能です。

3. OSS.Core フレームワークのアイデアと実装

OSS.Core プロジェクトは、私が最近書いている小さなオープンソース製品です。それを知っている友人なら、私が以前に OSS.Social、OSS.PayCenter、OSS.Common、OSS.Http などのコンポーネントを書いたことを知っているはずです。このプロジェクトができることを願っています。 これらのコンポーネントを接続するために、マイクロサービスに関する一般的な考え方をこの製品の論理アーキテクチャに反映できるように最善を尽くします。 まず、プロジェクトの物理アーキテクチャ図を示します。

このプロジェクトでは、Front

Endsフォルダーの下にAdminSiteとWebSiteが配置されており、2つのサイトはユーザーフロントエンドとバックグラウンド管理フロントエンドです

WebApi,Service,Do

mainMos(画像のModelとInterface）クラスライブラリLayersフォルダーの下に、API

Infrastruction（ビジネス関連の一般エンティティ列挙補助クラス）とCommon（ビジネスに関係のないエンティティ補助クラス）の基礎を形成します。インフラストラクチャ クラス ライブラリとして、すべてのレベルで使用できます

リポジトリはクラス ライブラリで呼び出されます (一時的にはプロジェクト内の OSS.Core.RepDapper の

Mysql 実装であり、将来的には他のデータベース サポートが追加される可能性があります) )、主に Rep..Interface の特定の実装。

プラグは、Common プラグインの下にロギング、キャッシュ、構成インターフェイスの特定の実装を実装しており、Common を介してすべてのレベルで直接呼び出すことができます。

マイクロサービスの話に戻りますが、この製品では、各サービスのレイヤーの下に一連のクラス ライブラリ実装を作成しません。このプロジェクトでは、各サービスをフォルダー分離の形で分離します。 API ゲートウェイ。内部呼び出しシーケンスが次のようになることを願っています:

現在のコード構造図:

以上がOSS.Coreの基本的な考え方の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。