ØMQを使ってMicroservice間をロスレスでデータを同期させるStrongZero - Qiita
対象読者 2つの疎結合なシステム間を、メモリを大量に使っちゃうような大がかりな仕組みなしで、ほぼリアルタイムにデータロスなしに同期させたい、そういうアーキテクチャが欲しい方。 動機 Microservicesを疎結合に保ちつつ、バッチ処理やレポート機能でのクエリの高速化のため、データを同期させたいことがままあります。このあたりの話は、テキストの「5章 モノリスの分割」に載っています。 あるサービスから、データを定期的に吸い上げて、別のサービス、ツールに送るデータポンプという仕組みがあります。 イベント駆動でメッセージを関連サービスに送るイベントデータポンプや、バックアップツールを使って高速にデータ転送するバックアップデータポンプが紹介されていますが、結果整合性だけどなるべくリアルタイム(Near Real-Time)で同期させたいとなると、イベントデータポンプな仕組みしか選択肢にはならない
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
至高のファイルアップロード - Qiita
システムエンジニアにとって頻出機能のひとつで、要件がモリッとしがちなファイルアップロードについてです。アップロードファイルもただの画像やPDFではなく、ExcelやCSVファイルをアップロードして、中身を読み取ってデータベースに格納する、あれを対象とします。 標準的なファイルアップロードでの設計ポイント ファイルのアップロード機能を実装しようとなると、以下のような点の設計を考える必要があります。 同期? 非同期? タイムアウトのリスクがあれば、非同期にする ブラウザのタイムアウト 通信経路(プロキシやファイヤウォール)でのタイムアウト Webサーバのタイムアウト ユーザがレスポンス返ってこないので、処理を中止するリスク 非同期の場合の実行方式 Webサーバ内でスレッドを新規に作る or 別プロセスへ処理をディスパッチする 流量制御のためリクエストをキューイングする Progress 長時間
サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita
最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
