コンテナをさらに活用しよう! 「マイクロサービス」と「サーバーレス」
はじめに 今回は、コンテナを中心にした技術をより有効活用するためのアーキテクチャ(構造)について説明していきます。そのため、今までよりも少し難しい内容になるかもしれません。取り上げるテーマは「マイクロサービス」と「サーバーレス」です。本来であれば、この2つのアーキテクチャを説明するためには、サービスの分割や開発者によって作られるアプリケーションの開発手法から説明しなければならないのですが、今回はアーキテクチャにフォーカスを当てていきたいと思います。 マイクロサービスアーキテクチャとは まずは、マイクロサービスアーキテクチャについて説明していきましょう。マイクロサービスアーキテクチャを説明するためには、「モノリシック」なサービスと対比するとわかりやすいでしょう。図1に2つの構造を並べてみました。 つまり「マイクロ」という言葉の通り、アプリケーションをある程度の細かな機能単位で分割し、独立して
マイクロサービス指向アプリケーションの設計 - .NET
このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。 このセクションでは、仮想のサーバー側エンタープライズ アプリケーションの開発について説明します。 アプリケーションの仕様 仮想アプリケーションは、ビジネス ロジックを実行し、データベースにアクセスした後、HTML、JSON、または XML 応答を返すことで要求を処理します。 このアプリケーションで、シングル ページ アプリケーション (SPA) を実行するデスクトップ ブラウザー、従来の Web アプリ、モバイル Web アプリ、およびネイティブ モバイル アプリを含むさまざまなクライアントをサポートする必要があるとします。 さらに、アプリケーシ
マイクロサービスの Saga パターンについて - Qiita
以前の記事で『Microservice Patterns』について要約したが、その中の一つの Saga パターンについて、もう少し詳しく掘り下げてみる。 どういう文脈で Saga パターンを使うか？ 各サービスがそれぞれの Bounded Context (整合性の境界)で自前のデータストア（Database per Service）を持っているマイクロサービスアーキテクチャで、複数サービスにまたがるワークフローのデータ整合性を維持したい。 どういう制約のもとで Saga パターンを使うか？ 以下のような事情で、分散トランザクションは使いたくない。 モダンでメジャーな NoSQL やメッセージブローカではサポートされていないものが多い。 CAP 定理の認知度が高まって、Consistency を絶対視する風潮が見直され、Availability をより重視するシステムも増えている。 分散ト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
