ブログシステムのアーキテクチャに関する考察 (パート 2) -- Static と CQRS_html/css

ブログシステムのアーキテクチャに関する考察 (パート 2) -- Static と CQRS_html/css_WEB-ITnose

WBOY

リリース： 2016-06-21 08:52:33

オリジナル

1263 人が閲覧しました

複雑なシステムの場合、前の記事のアプローチは非常に優れています。しかし、単純なシステムにとって、これはやりすぎでしょうか?ブログシステムを設計したい場合、書き込みと読み取りを分離することを検討できますか?

CQS

コマンドとクエリの責任の分離 Command Query Responsibility Segregation (CQRS) は、読み取りと書き込みを分離する方法です。システムの動作これは 2 つの独立したモデルのアーキテクチャパターンです。

このアーキテクチャについての深い考察は、DDD の以前の理解に基づいています。 DDD分野で広く使われているという。 CQRS を理解するには、読み取りおよび書き込みリクエストを処理するための別のモデルと API セット、つまり CQS (Command Query Separation) モードを使用することから始めることができます。 CQS パターンは、ソフトウェアの第一人者である Bertrand Meyer (エッフェル言語の父であり、オブジェクト指向のオープンクローズ原則 OCP の提案者) によって最初に提案されました。彼は、オブジェクトの動作にはコマンドとクエリの 2 種類しかないと考えています。

このタイプのアーキテクチャを以下に示します。

最適化されたクエリタイプを作成することに加えて、読み取る API の部分を簡単に変更できます。一部のキャッシュメカニズム、または読み取り API リクエストを別のサーバーに移動することもできます。

読み取りと書き込みが類似しているアプリケーションの場合、このアーキテクチャは適切に見えます。同じ RDBMS を使用するこのアーキテクチャには、依然としてボトルネックの問題が存在します。書き込み量が多く、読み取り量が少ないアプリケーションにとって、このアーキテクチャは依然として不合理です。

この問題を解決するために、人々は当然キャッシュを使用してこの問題を解決します。アプリケーションサービスの外部に HTTP サーバーがあり、ユーザーが存在する一部のリソースをキャッシュするために HTTP サーバーの外部にキャッシュサーバーがあります。以下に示すように:

実際、そのようなサーバーは冗長である可能性があります。なぜ HTML を直接生成しないのでしょうか?

編集と出版の分離

おそらく、Martin Folwer によって提案された編集と出版の共有アーキテクチャについて聞いたことがあるでしょう。つまり、記事は編集時にはある形式で、公開時には別の形式になります。たとえば、マークダウンで編集され、HTML で公開されます。

最も典型的なアプリケーションは、GitHub で人気のある Hexo フレームワークや Jekyll フレームワークなどの静的 Web サイトです。以下の図に示すように、Hexo のワークフローは次のとおりです。

プロジェクトをローカルに生成し、新しいブログを作成したり、コンテンツの作成を開始したりできます。これにより、このサービスをローカルで実行できるようになり、ブログのコンテンツを表示したり、スタイルなどを変更したりすることもできます。上記の作業を完了したら、静的コンテンツを生成し、アプリケーションを GitHub ページにデプロイできます。

これはすべて完璧に見えます。2 つの異なるデータソースがあります。1 つは md 形式のテキストで、もう 1 つは最終的に生成された HTML です。彼らは読み書き/分離を実装しました:

しかし、フロントエンド開発者として、JSON がなく、Ajax リクエストを使用できない場合、ブログをシングルページアプリケーションにするにはどうすればよいでしょうか?

編集、出版、開発の分離

ブログを hexo 形式ではなく JSON に変換する必要があるためです。これらの JSON ファイルの存在により、Git を NoSQL データベースとして扱うことができます。同時に、これらの JSON ファイルは API として直接使用することもできます

次に、これらのブログは hexo のような HTML を生成する必要もあります。

さらに、開発者は開発中のエディタの使用に影響を与えないため、次のアーキテクチャがあります:

これには 2 つの違いがありますデータ形式は JSON ですMarkdown データと最終的に生成された HTML を保存するファイル。

ブログの数が少ない Web サイトや一般的な Web サイトの場合、上記のテクノロジーを使用しても問題ありません。しかし、大量のデータを含む Web サイトはどうなるでしょうか? EventBus の使用

以前にプレイしたデモでは、Python の Scrapy クローラーを使用して既存の動的 Web サイトをクロールし、それらを静的 Web サイトに変換し、AWS S3 にデプロイしました。

しかし、これだけだとまだ問題がいくつかあります: