Java マイクロサービスのガイド。パート 1: マイクロサービスの基本とアーキテクチャ

このガイドでは、Java マイクロサービスとは何か、その設計と作成方法を学びます。また、Java マイクロサービス ライブラリに関する質問や、マイクロサービスの使用の実現可能性についても説明します。Java マイクロサービスの翻訳と適応: 実践ガイド。

Java マイクロサービス: 基本

マイクロサービスを理解するには、まずマイクロサービスではないものを定義する必要があります。それは「モノリス」ではありませんか - Java モノリス: それは何ですか、またその長所と短所は何ですか?

Java モノリスとは何ですか?

あなたが銀行やフィンテックの新興企業で働いていると想像してください。新しい銀行口座を開設するために使用できるモバイル アプリをユーザーに提供します。Java コードでは、これによりコントローラー クラスが存在します。簡略化すると次のようになります。

@Controller
class BankController {

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        riskCheck(form);
        openBankAccount(form);
        // etc..
    }
}

次のことを行うにはコントローラーが必要です。

1. 登録フォームを確認しました。
2. ユーザーの住所のリスクを確認して、銀行口座を提供するかどうかを決定しました。
3. 銀行口座を開設しました。

このクラスは、BankController残りのソースとともに、デプロイメント用の Bank.jar または Bank.war ファイルにパッケージ化されます。これは、銀行を運営するために必要なすべてのコードを含む古き良きモノリスです。大まかな見積もりとして、.jar (または .war) ファイルの初期サイズは 1 ～ 100 MB の範囲になります。これで、サーバー上で .jar ファイルを実行するだけで済みます。Java アプリケーションをデプロイするために必要な作業はこれだけです。 図、左上の四角形: モノラル (リシック) バンク java -jar Bank.jar (アプリサーバーへの cp .war/.ear) のデプロイメント。右の長方形: ブラウザを開きます。

Java モノリスの問題は何ですか?

Java モノリスには本質的に何も問題はありません。ただし、経験上、プロジェクト内で次のことが起こることがわかっています。

• 多くのプログラマー、チーム、コンサルタントが働いています...
• ...非常に曖昧な要件を持つ顧客からの圧力を受けて、同じ一枚岩の上で...
• 数年以内に...

...この場合、小さなbank.jarファイルだけでも膨大なギガバイトのコードに変わり、デプロイはおろか、近づくことすら恐ろしいことになります。

Java モノリスのサイズを縮小するにはどうすればよいですか?

当然の疑問が生じます: モノリスをどのように小さくするか? 現在、bank.jar は 1 つの JVM、1 つのサーバー上の 1 つのプロセスで実行されています。それ以上でもそれ以下でもありません。そして今、次のような論理的な考えが頭に浮かぶかもしれません。「しかし、リスク検証サービスは会社の他の部門でも使用できるのです。これは、私のモノリシック バンキング アプリケーションとは直接関係ありません。おそらくモノリスから切り出して別の製品として展開する必要があるでしょうか? つまり、技術的に言えば、別の Java プロセスとして実行されます。」

Java マイクロサービスとは何ですか?

実際には、このフレーズは、メソッド呼び出しがriskCheck()BankController から行われないことを意味します。このメソッドまたは Bean コンポーネントとそのすべての補助クラスは、独自の Maven または Gradle プロジェクトに移動されます。また、銀行モノリスとは独立して展開され、バージョン管理下に置かれます。ただし、マイクロサービスの定義は解釈の余地があるため、この抽出プロセス全体が新しい RiskCheck モジュール自体をマイクロサービスに変えるわけではありません。これにより、チーム内や企業内で頻繁に議論が行われます。

• 5 ～ 7 クラスはプロジェクト マイクロですか?
• 100 または 1000 クラス...それでもマイクロですか?
• マイクロサービスは一般的にクラスの数に関係しますか?

理論的な推論は置いておいて、代わりに実際的な考慮事項に固執して、これを実行しましょう。

1. サイズやドメインの境界に関係なく、個別にデプロイされたすべてのサービスをマイクロサービスと呼びましょう。
2. サービス間通信をどのように調整するかを考えてみましょう。私たちのマイクロサービスには、相互に通信する方法が必要です。

要約すると、以前は 1 つの JVM プロセス、つまり銀行を実行するための堅固なモノリスがありました。これで、銀行業務用モノリス JVM プロセスと、独自の JVM プロセス内で実行される個別の RiskCheck マイクロサービスが完成しました。そして今、リスクをチェックするために、モノリスはこのマイクロサービスを呼び出す必要があります。これを行う方法？

Java マイクロサービス間の通信を確立するにはどうすればよいですか?

一般に、同期通信と非同期通信の 2 つのオプションがあります。

同期通信：（HTTP）/REST

通常、マイクロサービス間の同期通信は、HTTP および XML または JSON を返す REST のようなサービスを介して行われます。もちろん、他のオプションがあるかもしれません - 少なくともGoogle プロトコル バッファーを選択してください。即時の応答が必要な場合は、REST 通信を使用することをお勧めします。この例では、口座開設前にリスク検証が必要なため、これがまさに行う必要があることです。リスクチェックがなければアカウントは存在しません。以下のツールについては、「同期 Java REST 呼び出しに最適なライブラリはどれか」のセクションで説明します。

メッセージング - 非同期通信

非同期マイクロサービス通信は、通常、JMS 実装とメッセージを交換したり、 AMQPなどのプロトコルを使用したりすることによって実現されます。ここで「通常」と書いたのには理由があります。電子メールと SMTP の統合の数は過小評価できないとしましょう。すぐに対応する必要がない場合に使用してください。たとえば、ユーザーが「今すぐ購入」ボタンをクリックした場合、あなたは請求書を生成したいと考えます。このプロセスは、ユーザーの購入要求と応答のサイクル内で発生するべきではありません。以下では、非同期 Java メッセージングに最適なツールについて説明します。

例: Java での REST API 呼び出し

同期マイクロサービス通信を選択すると仮定します。この場合、低レベルの Java コード (上で示したもの) は次のようになります。(ここでの低レベルとは、マイクロサービス通信では、実際の HTTP 呼び出しからユーザーを抽象化するクライアント ライブラリが通常作成されるという事実を意味します)。

@Controller
class BankController {

    @Autowired
    private HttpClient httpClient;

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        httpClient.send(riskRequest, responseHandler());
        setupAccount(form);
        // etc..
    }
}

コードに基づいて、Bank と RiskCheck という 2 つの Java (マイクロ) サービスをデプロイする必要があることがわかります。その結果、2 つの JVM プロセスが実行されることになります。 Java マイクロサービス プロジェクトの開発に必要なのはこれだけです。1 つのモノリシック プロジェクトではなく、より小さなチャンク (.jar または .war ファイル) を構築してデプロイするだけです。「モノリスをどのようにマイクロサービスに分割するべきか?」という質問に対する答えは依然として不明です。これらのピースはどれくらい小さい必要がありますか?正しいサイズを決定するにはどうすればよいですか? 確認しよう。

Java マイクロサービス アーキテクチャ

実際、企業はさまざまな方法でマイクロサービス プロジェクトを開発しています。このアプローチは、既存のモノリスをマイクロサービス プロジェクトに変換しようとしているのか、それともプロジェクトを最初から開始しようとしているのかによって異なります。

モノリスからマイクロサービスへ

最も論理的なアイデアの 1 つは、既存のモノリスからマイクロサービスを抽出することです。ここでの接頭辞「micro」は、実際には、抽出されるサービスが本当に小さいことを意味するわけではなく、必ずしもそうであるわけではないことに注意してください。理論的背景を見てみましょう。

アイデア: モノリスをマイクロサービスに分割する

マイクロサービスのアプローチはレガシー プロジェクトに適用できます。だからこそ:

1. ほとんどの場合、このようなプロジェクトは維持、変更、拡張することが困難です。
2. 開発者から管理者まで、誰もが簡素化を望んでいます。
3. ドメインの境界が（比較的）明確です。つまり、ソフトウェアが何をすべきかを正確に知っています。

この例に戻ると、これは、Java バンキング モノリスを調べて、ドメインの境界を越えてそれを分解できることを意味します。

• したがって、ユーザー データ (名前、住所、電話番号など) の処理を​​別のマイクロサービス「アカウント管理」に分離するのが合理的です。
• あるいは、ユーザーのリスク レベルをチェックする前述の「リスク チェッカー モジュール」は、他の多くのプロジェクトや会社の部門でも使用できます。
• または、請求書を PDF 形式またはメールで送信する請求モジュール。

アイデアの実装: 他の人にやってもらう

上で説明したアプローチは、紙や UML のような図に適しています。ただし、すべてがそれほど単純ではありません。その実際の実装には、綿密な技術的準備が必要です。モノリスから何を抽出するとよいかについての私たちの理解と抽出プロセス自体の間には、大きなギャップがあります。ほとんどのエンタープライズ プロジェクトは、開発者が、たとえば 7 年前のバージョンの Hibernate を新しいバージョンにアップグレードすることを恐れる段階に達しています。ライブラリもそれに伴って更新されますが、何かが壊れてしまう危険性が非常にあります。では、その同じ開発者が、データベース トランザクションの境界が不明瞭な古代のレガシー コードを掘り下げて、明確に定義されたマイクロサービスを抽出する必要があるのでしょうか? 多くの場合、この問題は非常に複雑で、ホワイトボードや建築会議では「解決」できません。 Twitter 開発者 @simonbrown の言葉を引用すると、 これは何度でも言います...人々がモノリスを正しく構築できない場合、マイクロサービスは役に立ちません。 サイモン・ブラウン

マイクロサービス アーキテクチャに基づいてゼロからプロジェクトを作成する

新しい Java プロジェクトの場合、前の部分の 3 つの番号付きポイントは少し異なって見えます。

1. 白紙の状態から始めるので、メンテナンスするための「荷物」はありません。
2. 開発者は、将来的には物事をシンプルにしていきたいと考えています。
3. 問題: ドメイン境界の全体像が非常に曖昧です。ソフトウェアが実際に何を行うべきかがわかりません (ヒント: アジャイル ;))

これにより、企業は Java マイクロサービスを使用した新しいプロジェクトを試みています。

技術的なマイクロサービス アーキテクチャ

最初の点は開発者にとって最も明白なようですが、それを強く推奨しない人もいます。Hadi Hariri 氏は、IntelliJ での「Extract Microservice」リファクタリングを推奨しています。次の例は非常に単純化されていますが、実際のプロジェクトで観察される実装は、残念ながら、この例からそれほど離れていません。 マイクロサービス以前

@Service
class UserService {

    public void register(User user) {
        String email = user.getEmail();
        String username =  email.substring(0, email.indexOf("@"));
        // ...
    }
}

部分文字列 Java マイクロサービスを使用する場合

@Service
class UserService {

    @Autowired
    private HttpClient client;

    public void register(User user) {
        String email = user.getEmail();
        //теперь вызываем substring microservice via http
        String username =  httpClient.send(substringRequest(email), responseHandler());
        // ...
    }
}

つまり、明確な理由もなく、本質的に Java メソッド呼び出しを HTTP 呼び出しにラップしていることになります。ただし、その理由の 1 つは、経験不足と Java マイクロサービス アプローチを強制しようとすることです。推奨事項: これは行わないでください。

ワークフロー指向のマイクロサービス アーキテクチャ

次に一般的なアプローチは、Java マイクロサービスをワークフロー ベースのモジュールに分割することです。実際の例: ドイツでは、(公的) 医師の診察を受けるとき、医師はあなたの訪問を医療 CRM システムに記録する必要があります。保険から支払いを受け取るために、医師はあなたの治療 (および他の患者の治療) に関するデータを XML 経由で仲介業者に送信します。ブローカーはこの XML ファイルを調べて、(簡略化して) 次のようにします。

1. 正しい XML ファイルが受信されたかどうかを確認します。
2. それは、その処置の妥当性をチェックすることになる。たとえば、婦人科医から1日に3回の歯のクリーニング処置を受けた1歳児は、やや疑わしいように見える。
3. XML を他の官僚的なデータと組み合わせます。
4. XML ファイルを保険会社に転送して支払いを開始します。
5. そして結果を医師に送信し、「成功」または「意味が分かり次第、この録音を再送信してください」というメッセージを医師に提供します。

注記。この例では、マイクロサービス間の通信は役割を果たしませんが、いずれにせよ医師はすぐにフィードバックを受信しないため、メッセージ ブローカー (RabbitMQ など) によって非同期に実行される可能性があります。 繰り返しになりますが、これは紙の上では素晴らしく見えますが、当然のことながら次のような疑問が生じます。

• 1 つの XML ファイルを処理するために 6 つのアプリケーションをデプロイする必要がありますか?
• これらのマイクロサービスは本当に相互に独立しているのでしょうか? それぞれを独立して導入できますか? バージョンや API スキームが異なる場合は?
• 検証マイクロサービスが機能しない場合、信頼性マイクロサービスは何をしますか? システムはまだ機能していますか?
• これらのマイクロサービスは同じデータベースを共有しますか (DB テーブルに共通のデータが必ず必要です)、それともそれぞれ独自のデータベースを持っていますか?
• …などなど。

興味深いことに、各サービスには正確で明確に定義された目的があるため、上の図はより単純に見えます。以前は、この恐ろしい一枚岩のように見えました。 これらの図の単純さについて議論することはできますが、現在では、これらの追加の運用上の課題を解決する必要があることは間違いありません。

• アプリケーションを 1 つだけデプロイする必要はなく、少なくとも 6 つデプロイする必要があります。
• マイクロサービス アーキテクチャをどこまで進めたいかによっては、複数のデータベースをデプロイする必要がある場合もあります。
• 各システムがオンラインであり、適切に動作していることを確認する必要があります。
• マイクロサービス間の呼び出しが本当に復元力があることを確認する必要があります (「Java マイクロサービスの復元力を高める方法」を参照)。
• そして、ローカル開発設定から統合テストに至るまで、このセットアップが意味するその他すべてのこと。

したがって、推奨事項は次のようになります。

• あなたが Netflix ではない場合 (おそらく、あなたは Netflix ではありません)...
• 開発環境を開くと、5 秒で簡単に復元できる運用データベースを破棄するカオス モンキーを引き起こすような、非常に強力な作業スキルを持っている場合を除きます。
• あるいは、@monzo のような気分で、できるからといって 1500 個のマイクロサービスを試してみたいと考えている人もいるでしょう。

→そんなことはしないでください。そして今では、誇張的ではなくなりました。ドメイン境界を越えてマイクロサービスをモデル化しようとすることは、非常に合理的であるように思えます。ただし、これは、1 つのワークフローを小さな個別の部分 (XML の受信、XML の検証、XML の転送) に分割する必要があるという意味ではありません。したがって、Java マイクロサービスを使用して新しいプロジェクトを開始し、ドメインの境界がまだ非常に曖昧な場合は、マイクロサービスのサイズを低いレベルに保つようにしてください。後でいつでもモジュールを追加できます。そして、新しいインフラストラクチャをサポートするために、チーム/会社/部門で高度な DevOps を導入していることを確認してください。

ポリグロットまたはチーム指向のマイクロサービス アーキテクチャ

マイクロサービス開発には、ほぼ自由主義的な 3 番目のアプローチがあります。それは、チームまたは個人が、任意の数の言語またはマイクロサービスを使用してユーザー ストーリーを実装できるようにすることです (マーケティング担当者は、このアプローチを「多言語プログラミング」と呼んでいます)。したがって、上記の XML 検証サービスを Java で記述し、同時に検証マイクロサービスを (数学的に正確にするために) Haskell で記述することができます。保険転送マイクロサービスの場合は、Erlang を使用できます (実際に拡張する必要があるため ;))。開発者の観点からは楽しいように見えるかもしれません（隔離された環境で完璧な言語を使用して完璧なシステムを開発する）ことは、実際には組織が望んでいることではありません、つまり均質化と標準化です。これは、言語、ライブラリ、およびツールの比較的標準化されたセットを意味し、将来、より環境に優しい環境に移行したときに、他の開発者が引き続き Haskell マイクロサービスをサポートできるようにします。 歴史が示すように、標準化は通常、あまりにも深く浸透しすぎます。たとえば、Fortune 500 に名を連ねる大企業の開発者は、Spring が「会社の技術ロードマップの一部ではない」という理由で、Spring の使用さえ許可されないことがありました。ただし、多言語アプローチへの完全な移行は、ほぼ同じことであり、同じコインの裏返しです。推奨事項: 多言語プログラミングを使用する場合は、同じプログラミング言語エコシステム内で多様性を減らしてください。したがって、Java と、たとえば Haskell を使用するよりも、Kotlin と Java (どちらの言語も JVM に基づいており、相互に 100% 互換性があります) を一緒に使用する方が良いでしょう。次のパートでは、 Java マイクロサービスのデプロイとテストについて学びます。