複数サービスをマッシュアップする際に注意したいこと | NTT Communications Developer Portal
企業がAPIを使う側に立った時、それは一つのAPIだけを使うとは限りません。APIでは複数のAPIを組み合わせるマッシュアップと呼ばれる形態が存在します。同じ市場に存在するAPI同士を組み合わせることで、API提供元ではできないサービスを提供できる可能性があります。有名なところではホテルや旅行の検索アプリケーションが挙げられます。 そうした複数のAPIを組み合わせて使う場合、問題になるのがネットワークの遅延であったり、API停止に伴うマッシュアップサービスへの影響です。今回はそうしたマッシュアップ時における問題点と解決策を紹介します。 フロントエンドではAPIを処理しない JSONやRESTfulでのAPI提供を行っていると、WebブラウザのJavaScript側でデータを取得したり集計できるようになります。そのためWebブラウザだけで処理を完結させたいと考えることでしょう。その方がサーバ
サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita
最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが
サービス分割とデータ統合アーキテクチャに関する考察 - Qiita
こんにちは、freeeでエンジニアをしている@yebiharaです。 この記事はfreee Engineers Advent Calendar 2015の22日目です。 皆さんの中には「マイクロサービスアーキテクチャ」という言葉を聞いたことがある方も多いと思います。 James LewisとMartin Fowlerによるブログ記事 Microservices(日本語訳)により、急激に広まった感のあるこの言葉ですが、マイクロサービスそのものについて書き始めると長くなり過ぎてしまうので、この記事では触れません。 さて、freeeのアーキテクチャもマイクロサービスを意識しています。 粒度についてはサービスによってマチマチで、必ずしも「マイクロ」とは言えないものもありますが、いずれにしても異なる機能を提供する複数のサービスをAPIで統合することにより、freeeのシステムは成り立っています1。
マイクロサービスアーキテクチャにおけるDatabase per serviceパターン、そしてその整合性の取り方について | cloud.config Tech Blog
マイクロサービスアーキテクチャにおけるDatabase per serviceパターン、そしてその整合性の取り方について マイクロサービスアーキテクチャにおけるデータベース 昨今、マイクロサービスアーキテクチャというアプリケーションアーキテクチャのパターンへの関心が高まってきています。 サービス全体を複数のサービスに分割し、相互に通信を行って連携を行わせることで、それぞれのサービスを疎結合にし、サービスの間の依存関係を小さくすることで、それぞれのサービスを素早く開発したり、デプロイの単位を小さくしたり、サービスごとに別の技術を使用することができる、というのがこのアーキテクチャの特徴になります。 その中で、データベースをどうやって持たせるのかという疑問については、Database per serviceというパターンがその回答になります。 このパターンにおいては、例えば、サービスAはデータベ
SSH接続をWebブラウザの純粋なHTTP上で実現する - nwtgck / Ryo Ota
HTTPといえばHTML/CSS/JavaScriptや画像などの小さめの限りがあるデータを手に入れるためによく使われている印象がある。REST APIのようなHTTPを使ったAPIでも限りのあるデータがリクエストとレスポンスになる印象が強い。
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービス 統合db - Google 検索
マイクロサービスの管理画面 - qsona's project