BT

マイクロサービス - 重要なのはサイズよりも使い方

| 作者: Jan Stenberg フォローする 37 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2014年5月18日. 推定読書時間: 2 分 |

原文(投稿日:2014/05/08)へのリンク

マイクロサービスの定義をサイズのみに頼るのは基準として不十分だ,それではサービスの責務が適切かどうかを判断することはできない – Jeppe Ceamon氏は一連のブログ記事で,マイクロサービスに対する自身の見解を明確にすると同時に,同期双方向通信の問題点についても指摘している。

大規模システム統合とSOAを専門とする受託開発者としてデンマークで活躍する氏は,小規模なマイクロサービスを同期通信で結合するのは1990年代のCorbaやJ2EE,分散オブジェクトと事実上同じであり,RMIやIIOPを単にHTTPに置き換えたに過ぎない,と述べている。マイクロサービスが一般的にHTTPを使うからといって,JSONやRESTに"8 fallacies of distributed computing"に要約されたようなリモート通信のデメリットがなくなる訳ではない。

このような同期通信に代わるものを創造する上で,氏が基盤としたもののひとつは,Pat Helland氏と,同氏が分散トランザクションに異議を唱えた"Life beyond Distributed Transactions: An Apostate’s Opinion"である。Ceamon氏のソリューションは3つの柱で成り立っている。

  1. サービスへのデータ割り当て。
  2. データ識別。
  3. サービス間通信。

この第1と第2のポイントを,氏はドメイン駆動設計(DDD/Domain-Driven Design)の概念を導入して解決する。エンティティに収集したデータの集合体(aggregate)をUUIDなどを用いてユニークに識別可能とした上で,ひとつのサービスに割り当てるのだ。それぞれの集合体はトランザクション後も一貫性を保たなければならない。方針としては,1ユースケース=1トランザクション=1集合体,というようなものだ。

サービス間通信の問題は非同期通信によって解決する。具体的には,メッセージキューなどのトランスポートチャネルで送信側がメッセージを送る,完全な一方向通信を使用するのである。送信側はメッセージの受信を待つ必要はない。受信側へのメッセージの配信と受信については,トランスポートチャネルが責務を持つことが前提だ。

サービスをより小さなサービスに分割することに注目しながら,それらが互いに非同期一方向通信を使用してコミュニケートする方法に関して,ブログ記事の執筆を続けていきたい,と氏は考えている。

マイクロサービスアーキテクチャは,ビジネス機能を満足する自律性と独立展開性を備えたサービスのセットとして,ソフトウェアアプリケーションを設計する方法を示す概念として,ここ数年間で注目を集めている。11月下旬には,ロンドンでカンファレンスが開催される予定だ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT