@yusukey のご好意により Twitter Japan の会場をお借りして Finagle hack-a-thon が開催されました。 Twitter Japan はサイコーでした。 #ステマ
![#finagle_hack at Twitter Japan .@yakitori](https://cdn-ak-scissors.b.st-hatena.com/image/square/700c31097584a55b6162f92fe1ff5bf2927beec3/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F3ec6ba6848990d66674d64dc883eef74-1200x630.png)
ちょっと前に「thriftって便利らしいよー」って話を聞いていたのだけれども、なかなか手をつけられずにいたらはてなブックーマークで使われているらしいという噂を聞いたり、Thriftを使って俺俺Key-Value Storeを作ったのように、TXを使ったThriftの紹介などが出てきたりしたのでそろそろ自分でも試したいなあと思い、試しました。で、先に結論を言っておくとThrift、とても気に入りました。とても簡単に処理用の専用サーバをたてることができて、かつ簡単にクライアントから処理要求が送れます。ボクは今まではRESTFulな感じでhttpでこのタスクをやっていたのですが、RESTFulな専用サーバをたてるのは結構開発コストがかかるんですよね。その点で、Thriftは開発コストはとても落ちると思うのでとても気に入っています。なんといって言語バインディングを自動で生成してくれるのは本当に開発
協調型分散システムに必要な Peer to Peer (以下PTP) RPC サービスインフラストラクチャを構築するための通信端点の設計について。コンポーネントと役割ベースでの記述となります。プロトコルは別途。 抜けている点など多々存在していると思いますのでご意見などをコメント頂けると幸いです。 概要 SOAP, Thrift, RMI など従来の RPC の多くはクライアント-サーバ型で構成されています。これは主 (Server) の提供するサービスを従 (Client) から利用するという一方通行の利用形態です。 この構成はサーバ側からクライアントへ通知を行う必要があるようなシステム設計とはうまく適合しません。例えばサーバで行なっている非同期処理の結果通知が必要な場合、ロングポーリングのような実装で回避するか、さもなくばサーバからクライアントへ逆方向の RCP 接続を行う必要があります
Nettyと言えばJavaのノンブロッキングIOのAPIであるNIOをラップしたフレームワークとして、TwitterのFinagleなどで分散ネットワークアプリケーションシステムで使わていて高速で実績のあるライブラリとして有名ですが、ノンブロッキングIOでイベント駆動のサーバークライアントのネットワークアプリケーションを知るのに非常に良い題材ですので、素人翻訳ですがその日本語訳を公開することにしました。 ちなみにNettyがどれぐらいパフォーマンスに優れているのかというと、Herokuの仮想インスタンスを利用した実験の結果が参考になります。Scala(Finagle)がNettyの実装を利用したものになりますが、秒間6000リクエスト時の1dyno(APサーバー)の応答が秒間4000レスポンスで、C(Accept)、Java(Jetty)、Java(Tomcat)、Js(Node)、Pyt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く