Java Day Tokyo 2016 参加レポート2 マイクロサービスについて #javadaytokyo

今回のもう一つの参加目的、

「マイクロサービスの実践例と、支援するようなJavaのアーキテクチャについて」です。

モジュールによるマイクロサービス？

はじめに、「1-A Java SE 9 Overview」より。

Project jigsaw によるModulanizeの目的の一つは、「開発者が、マイクロサービスなアプリケーションを開発できるようにする」「デプロイできるようにする」ことだと話されていました。
（通訳と俺の日本語聞き取りが間違ってなければ）

これって、モジュールのjar単位でデプロイしていく運用を想定されてるのでしょうか。

ちょっと「俺の知ってるマイクロサービスと違う」感があるのですが、必要な（Javaで言うところの）APIだけが適切にexportsされているのであれば、安全にモジュールの差し替えも可能なのかな…
DDLをとっかえてるみたいでおっかないのですけど。

実践して分かったJavaマイクロサービス開発

続いて、谷本心氏による発表「実践して分かったJavaマイクロサービス開発」より。

実在する、レガシーでモノリシックなECサイトをマイクロサービスに解体していった体験記でした。

セッションの内容自体は後で資料公開されるそうなのでそちらを見ていただくとして、セッション中に出てきた、衝撃を受けた言葉を衝撃を受けた順にご紹介したいと思います。

アクセサとコントローラで共通のInterface（Javaの）を実装した話

Client側サービスのItemAccesssorクラスが、Itemサービスを呼び、ItemControllerクラスが起動するような仕組みの時に、
ItemAcessorクラスとItemControllerクラス双方に、ItemServiceというインタフェースを実装するようにした　という話。

良かったこと

　・依存がIDEのHierarchy検索で簡単に探せる
　・おなじIFなのでコントローラをDIするとサービス間の結合テストがJunitでできる！（なにこれすごい）

これ、おもしろい工夫だし実用的なのですが、
マイクロサービスのメリットの一つである、Polyglot（多言語性）完全に捨てる話で、すごい割り切りだなと思いました。

谷本さん曰く
「各サービス基盤が標準化されている方にメリットが有る」とのこと。
確かに、マイクロサービス化してサービスの数が増えたところで、いちいち選択言語は変えないでしょうから、Javaで統一する、と割りきった設計にするのは一理ありますね。
そしてその場合、Modelのクラスはなんとなく一緒のものを使いそうですが、アクセサとコントローラで同じIFを実装する、と言うのは考えたことがありませんでした。

AWSを使ってないとマイクロサービスのメリットが引き出しにくい

特にスケーリングについて言及されてました。高負荷の際にすぐにスケールできるような状況でなければマイクロサービスのメリットが得にくいのではないか、と。

私自身はマイクロサービスのメリットは、各サービスごとの凝縮度を上げる＆サービス間の結合度を下げる　ことで得られるメンテナンス性の高さが最大のメリットだと思っているので、クラウドでなければ意味が無い　とまではいかないと思いますが、スケーリングし易い　という恩恵は確かに受けずらいですね。

どうしてもAPIの設計が画面に引きずられる

その結果、APIは再利用性が低いものに。
結果、「フロントサービス」と「ドメインサービス」が分割され、「フロントサービス」が「ドメインサービス」を必要に応じて呼ぶようになった。

来た！　これはまさにここ最近私も悩み続けていた点で、とりあえず落ち着いた結論もほぼ同じ感じ。

RESTfulなマイクロサービスを作ろうとすると、画面に必要なロジックがどうしてもどこかに必要になるんですよね。