👵 🦍 🕜 ServiceMix（Camel）およびRabbitMQに基づく統合プラットフォームの構築経験 🚴🏻 😈 🐗

データを交換する必要のある少なくとも2つの情報システムが会社に現れるとすぐに、相互作用を整理する方法の問題が生じます。多くのオプションがあります：ファイル交換、データベース間のリンク、ウェブまたは残りのサービス、さまざまなメッセージングシステム、古いRPCとCORBA、最新のgRPCなど。選択は、プロジェクト参加者の好みとシステムの機能（システムアーキテクチャ、使用するプラットフォーム、既製のAPIの可用性など）に依存します。何らかの交換を選択すると、システムが相互作用し始め、すべてがうまくいくと仮定します。しかし、その後、3番目のシステムが発生し、これに統合する必要もあり、4番目などが続きます。すでに使用されている技術に自分自身を制限することはできないという事実ではなく、再び座って交換の方法を選択する必要があります（新しいシステムの制限により、どこかで開発者が別の技術を主張したか、何か新しいことを試してみたかった）。システムの数が増えると、システム間の相互作用の数と複雑さが増し、使用されるテクノロジーの数が増えます。その結果、会社の統合アーキテクチャ全体が、色や糸のもつれたボールのようになり始め、会社のシステムを何らかの形でリンクします。遅かれ早かれ、すべてのシステムを透過的かつ拡張可能にリンクする単一の統合環境を作成することが考えられ始めています。

この記事では、Apache ServiceMix（Camel）とRabbitMQを使用してこのような統合環境を構築した経験について説明します。

技術スタック

うさぎ

RabbitMQは、AMQPプロトコルに基づくメッセージングシステムです。システムの詳細は説明しません。Habréには、システムの機能を詳細に説明する記事が既にいくつかあります。RabbitMQの使用場所と使用方法について説明します。

RabbitMQを通じて、会社の情報システムとデータを交換します。各システムに対して一連のキューが作成されます。たとえば、会計システムで顧客の検索を名前と生年月日で整理する必要があります。いくつかのキューを作成します。会計システムに関しては、クライアントの名前と生年月日を示すリクエストを送信します。アカウンティングシステムは着信キューをリッスンし、着信要求を処理します。 2つ目は発信です。アカウンティングシステムは、要求の条件に一致するクライアントのリストを含む応答を送信します。

便利な理由：

キューに保存されているメッセージは永続的です。つまりシステムがしばらく利用できない場合、メッセージはどこにも消えず、システムの起動後に処理されます。 RabbitMQ自体を再起動しても、メッセージは失われません。
キューは、システムが快適なモードで処理できるバッファとして機能し、ピーク負荷を回避します。ユーザーがインターフェイスで待機しているリクエストでは、これが機能しないことは明らかです。この場合、即時の応答が必要です。しかし、あらゆる種類の非同期相互作用には非常に適しています。
非同期モードの相互作用。同時に、同期呼び出しもサポートされています。

RabbitMQと対話するようにシステムを教えることは難しくありません。 RabbitMQには、さまざまなプラットフォーム（Java、.Net、Pythonなど）用の既製のクライアントがあります。クライアントはシンプルで簡単です。キューからメッセージを読み取り、および/またはキューにメッセージを送信するコードは、数行かかります。すべてのシステムがRabbitMQと友達になれるわけではないことは明らかです。たとえば、レガシーシステムやボックス化されたシステムの場合、これは困難です。この場合、交換は、これらのシステムをサポートするテクノロジーを使用して構築されます。データベースのストアドプロシージャを呼び出す場所、Webサービスと休憩サービスを使用する場所、他の場所です。他の多くの統合タスクのためにこのような対話を整理するために、Apache ServiceMix製品が使用されます。

Apache ServiceMix

ServiceMix-さまざまな統合の問題を解決するのに役立つ事前定義されたバンドルのセットを持つKarafコンテナー。

製品に含まれるものについてもう少し詳しく：

実際には、バンドルが機能し、それらを管理できるKarafコンテナ自体：インストール/アンインストール/停止/開始、ログの表示、コンポーネントの依存関係の確認など。
検証、さまざまな変換（JSONからXMLへの変換、XSLTを使用した変換など）、強化、ルーティング、分割と結合、監視、統合プロセスの実行など、古典的な統合機能を実行する幅広いバンドル。。
幅広い種類のアダプター：ファイルアダプター、WebおよびRESTサービス用アダプター、JMS、RabbitMQ、Kafkaなど。アダプターの完全なリストは、Camel Webサイトにあります。

事前にインストールされたバンドルのみを使用することに限定されることはほとんどありませんが、インストールされたセットを起動するには十分なはずです。なぜなら私たちはKarafコンテナを使用しているため、必要なバンドルをインストールできます。これは、機能（バンドルセット）をインストールするか、個々のバンドルをインストールするだけで実行できます。もちろん、独自のバンドルを作成することも、サードパーティのJavaライブラリをバンドルにラップすることもできます。

アパッチキャメル

ServiceMixの主要なコンポーネントはApache Camelフレームワークです。これにより、Camel用語でルートと呼ばれる統合プロセスを構築できます。

例を示しましょう-ルートとは何ですか：

これは、受信するマルチフォーマットメッセージを共通の出力フォーマットに変換する単純なルートの例です。メッセージの形式に応じて、ルートはメッセージを適切な変換にルーティングします。変換は、メッセージを共通の形式に変換し、結果を出力に送信します。

Camelは、ルート、最も一般的なJava DSLおよびSpring XMLの記述のためのさまざまな表記法をサポートしています。 Spring XMLを使用します。 Spring XML表記では、画像のルートは次のようになります。

<route id="Normalizer"> <from uri=" endpoint" /> <!--           --> <choice> <when> <xpath>/*[local-name()='Format_1']</xpath> <to uri="xslt:classpath:xslt/Format_1_Transformation.xslt" /> </when> <when> <xpath>/*[local-name()='Format_2']</xpath> <to uri="xslt:classpath:xslt/Format_2_Transformation.xslt" /> </when> <when> <xpath>/*[local-name()='Format_3']</xpath> <to uri="xslt:classpath:xslt/Format_3_Transformation.xslt" /> </when> </choice> <to uri=" endpoint" /> </route>

非常に素晴らしい追加機能は、CamelがSpringと完全に統合されていることです。 Beanを定義する使い慣れたSpring XMLを使用し、同じSpring XMLでCamelルートを定義できます。同時に、ビンはルートから呼び出すことができ、ルートはビンから呼び出すことができます。ルートからのビンの呼び出しはCamel固有の柔軟性で実装され、メッセージ本文をBeanメソッドに渡すか、ヘッダー+本文を渡すことができます。または、XPATH式で指定された特定のXMLメッセージタグの値のみを渡すことができます。ルート。そして、これらはすべて実質的に1行にまとめられています。

キャメルスタイルのエレガンスの例を次に示します。

 <camel:camelContext> <route id="Bean method invocation"> <from uri=" endpoint" /> <when> <simple>${bean:authManager?method=checkToken(${body})}</simple> <to uri=" " /> </when> </route> </camel:camelContext> <bean id="authManager" class="pachage.AuthManager" />

 public class AuthManager { public boolean checkToken(@Body Document xml, @XPath("/Root/Token/@Value") String token) { return checkSessionToken(token); } }

Camelのもう1つの重要な概念は、エンドポイント（以降、エンドポイント）です。ルートはエンドポイントからメッセージを読み取り、エンドポイントにメッセージを送信できます。エンドポイントは、たとえば、RabbitMQキュー、ディレクトリ内のファイル、公開された休憩サービスなどです。ルートがエンドポイントを読み取る場合、メッセージがそのエンドポイントに到着すると、ルートはそれを処理し始めます。これにより、ルートを公開できます。外部システムにアクセスする機能を提供します。たとえば、アンケートに入力されたデータの正確性を確認するなど、タスクを実行するルートがある場合は、それをWebサービスとして公開するか、JMSを介してアクセスできるようにするか、外部に両方を行うことができますシステムは、ルートの機能を利用できます。Webサービスへの呼び出しを介したものと、JMSキューを介したメッセージングを介したものがあります。

ルートが相互にやり取りできるように、エンドポイントも使用されます。あるルートは、別のルートが読み取るエンドポイントにメッセージを送信し、処理のためにメッセージを渡すことができます。これにより、アプリケーションのさまざまな場所で要求されるさまざまな機能を実装するルートの独自のパレットを作成できます。たとえば、ログメッセージ。毎回同じ一連のログアクションを実行する代わりに、特別に設計されたルートにメッセージ処理を単純に転送できます。

統合アーキテクチャ

当社は多くの情報システムを使用しています。システムがデータを交換するための統合環境を編成するには、まずシステムを統合プラットフォームに接続する必要があります。このため、ServiceMix上の各システムに対してアダプターが開発されており、システムとのデータ交換およびデータ形式の変換を担当します。

システムごとに、システムとServiceMixの間で1つのデータ交換テクノロジーが選択されます。複数選択できますが、これによりシステム側とServiceMix側の両方で実装が複雑になります。一般的な場合、いくつかの異なる技術の使用は正当化されませんが、技術的に実装することができます。システムとの交換には主にRabbitMQを使用します（ServiceMixが統合システムとメッセージを交換するキューのセットを作成します）。ただし、ServiceMixの一部である既製のアダプターのセットが本当に役立つ場合があります。たとえば、会計システムの場合、データベース内のストアドプロシージャを使用します。ストアドプロシージャを呼び出すには、MyBatisコンポーネントを使用します。これにより、ServiceMixを経由するメッセージをストアドプロシージャパラメータにマップできます。以下に、IDによるユーザーへのログインのインストールのマッピングの例を示します。

 <select id="setLogin" statementType="CALLABLE" parameterType="java.util.Map"> {call esb.SetLogin ( @UserId=#{UserId, mode=IN}, @LoginId=#{LoginId, mode=IN} )} </select>

アダプタは、システムが統合プラットフォームと対話する形式を内部形式に変換する役割も果たします。誰かが独自のXML形式を使用するJSON形式での交換を好む人もいますが、統合プラットフォーム内では、コンポーネントは内部標準XML形式でデータを交換します。現在、XMLは、その重さと、JSON、Protobufなどの新しい代替手段により人気を失っています。しかし、私の意見では、XMLは依然として統合の問題を解決するのに便利です。 XSLTやXPATHなど、生活を大幅に簡素化する多くの便利なテクノロジーがありますが、完全に人間が読むことができます。

コンポーネント（アダプター）間のメッセージルーティングは、ルーティングルールに基づいています。統合プラットフォームの1つのコンポーネント内のルートは、Camelの内部エンドポイント（直接、seda）を介して相互作用します。相互間で、コンポーネントはRabbitMQキューを介して交換します。これにより、統合プラットフォームのコンポーネントを独立させることができます。 1つのコンポーネントが落ちても、他のコンポーネントのパフォーマンスには影響しません。負荷が一時的に増加すると、メッセージはコンポーネントキューに蓄積され、残りの交換には影響しません。

このようなアーキテクチャが、ポイントツーポイントベースのシステム間の直接的な対話よりも優れている理由：

各システムは、1つのプロトコルと対話形式のみをサポートする必要があります。
他のシステムとの交換の詳細は、統合プラットフォームの背後にあるシステムから隠されています。システムは統合プラットフォームとのみ対話し、他のシステムの存在すら認識していない場合があります。少なくともそれらとの対話の機能については心配しないでください。
システムは疎結合であるため、たとえば、あるシステムを新しいシステムに交換する必要がある場合など、柔軟性が向上します。
監視、テスト、統合サポートのためのツールは、統合プラットフォームの側面に集中化されています。

耐障害性

RabbitMQレベルでのフェールオーバーは、クラスターを作成し、キューを同期することにより実現されます。 RabbitMQノードの1つでキューに入る各メッセージは、同期ポリシーに従って他のノードに複製されます（クラスターのすべてのノードに複製できます。特定の数のノードに複製できますが、まったく複製できません）。すべてのノードに対してメッセージレプリケーションを備えた3ノード構成を使用します。これにより、3つのノードのうち2つが落ちた場合にクラスターの完全な操作性を維持できます。ただし、これは各メッセージの処理時間と占有ディスク容量の点で最もコストのかかるオプションでもあることを理解する必要があります。 3つのノードはすべてクライアント上でRabbitMQに登録されますが、接続はノードの1つと開きますが、接続が切断された場合、クライアントは透過的に他のノードに切り替えて動作し続けます。

ServiceMixのフォールトトレランスは、2つのServiceMixノードのクラスターを使用して実現されます。同時に、これが許容される場合、バンドルの一部は並行して動作します。たとえば、1つのRabbitMQキューを読み取るアダプターは、並行して実行できます。そのうちの1つだけが常に1つのメッセージを受信しますが、同時にメッセージは2つのノード間で均等に分散されます。ノードの1つが落下した場合、2番目のノードが全負荷を引き受けます。一部のバンドルは1つのノードでのみアクティブになりますが、フォールダウンすると、2番目のノードでバンドルがアクティブになります。たとえば、アダプタが共有ネットワークディレクトリを読み取る場合、同じファイルを同時に読み取ると、複製と衝突が発生する可能性があります。この動作モードは、Hazelcastに基づく共有ロックを使用して実現されます。最初にロックをキャプチャしたバンドルはアクティブモードになり、その機能を実行し、2番目のバンドルはロックが解除されるのを待ってハングします。

ハローワールド

結論として、ServiceMixで実行するCamelのHello worldアプリケーションの簡単な例を挙げたいと思います。アプリケーションは、バンドルの開始時（バンドルのデプロイ時やServiceMixの再起動時など）にServiceMixログに「Hello world」というフレーズを1回書き込むだけです。

ServiceMixディストリビューションをダウンロードし、servicemix.sh（bat）を解凍して実行します。

新しいMavenプロジェクトを作成して構成します。

src / main / resourcesで、springサブディレクトリを作成するMETA-INFディレクトリを作成する必要があります。

なぜならバンドルをビルドする必要があります-pom.xmlを編集します（パッケージ化とビルドの手順を追加）：

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>HelloWorld</groupId> <artifactId>HelloWorld</artifactId> <version>1.0.0-SNAPSHOT</version> <name>HelloWorld</name> <description>HelloWorld</description> <packaging>bundle</packaging> <build> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>3.0.1</version> <extensions>true</extensions> <configuration> <instructions> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> <Import-Package>*</Import-Package> <Export-Package>${project.groupId};version=${project.version}</Export-Package> </instructions> </configuration> </plugin> </plugins> </build> </project>

Mavenの依存関係を追加する必要はありません。

Camelコンテキストとルートを構成します。

springディレクトリでcamel-context.xmlファイルを作成する必要があります（ローダーはMETA-INF / springでCamelコンテキスト記述ファイルを自動的に検索し、ルートを開始します）。 camel-context.xmlファイルに、次のコンテンツを挿入します（テキストに沿ってコメントが表示されます）。

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi" xmlns:camel="http://camel.apache.org/schema/spring" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd"> <!--  Camel  --> <camel:camelContext xmlns="http://camel.apache.org/schema/spring" id="HelloWorldContext"> <!--   --> <route id="HelloWorldRoute"> <!--          --> <from uri="timer://startTimer?repeatCount=1" /> <!--      Hello world --> <setBody> <constant>Hello world</constant> </setBody> <!--      --> <log message="${body}"/> </route> </camel:camelContext> </beans>

ルートがタスクを完了する（「Hello world」というテキストを記録する）ために、メッセージを送信する必要があります。この場合、このタスクはtimer <from uri = "timer：// startTimer？RepeatCount = 1" />によって解決されます。これは、 repeatCount = 1命令に続いて、ルート入力にメッセージを1回送信します。なぜならタイマーは空のメッセージをルート入力に送信します。それを何かで埋める必要があります-メッセージ本文に「Hello world」 <setBody>というテキストを入れます。ルートの最後で、メッセージ本文の内容をログ<log message = "$ {body}">に表示します。

プロジェクトをまとめる ： mvnパッケージ
展開されたバンドル。

ServiceMixでバンドルを展開する1つの方法は、jarファイルをdeployディレクトリにコピーすることです。組み立てたjarをServiceMix / deployディレクトリにコピーします。

ServiceMixログを見てください： ServiceMix / data / log / servicemix.log 新しいバンドルをインストールして起動した情報に加えて、「Hello world」という碑文が表示されます。

HelloWorldRoute | 43-org.apache.camel.camel-core-2.16.3 | ハローワールド

sshコンソールにログインして、コンテキストリストコンテキストのキャメルリストとルートリストルートのリストを表示してみてください。コマンドの出力には、HelloWorldContextとHelloWorldRouteがあります。

結論

結論として、ServiceMixとCamelは統合ソリューションを構築するための優れた製品であると言いたいと思います。ほとんどすべてのタスクで、エレガントでシンプルなソリューションが見つかります。製品は非常によく考えられており、開発者は本当に一生懸命働いていることがわかります。当社のServiceMixは2年間使用されており、現時点では約16の情報システムを統合し、150以上の統合サービスを開発しています。一部のコンポーネントにはまだ問題がありましたが、常に同様のコンポーネントがあり、そこから選択したり、極端な場合には独自のコンポーネントを開発したりできます。一般的に、製品は安定して確実に動作します。個人的には、私の印象は最もポジティブです。紛れもない利点は、ソースコードのオープン性とライセンスを購入する必要がないことです。さらに、これらの製品は、商業的な同等品より絶対に劣っていません。また、ServiceMixとCamelは、統合の問題を解決するためだけでなく使用できることにも注意してください。たとえば、KarafはWebアプリケーションを展開するのに最適です。この機会を利用して、管理者が統合プラットフォームを構成するためのWebインターフェイスを提供します。 Camelは、さまざまなビジネスコンポーネントとシームレスに統合します。たとえば、Drools（ビジネスルールエンジン）を使用して、特定のルール（ポートフォリオを使用したトランザクション強化）に従って着信トランザクションを適切なポートフォリオに割り当てます。これはミドルオフィスのユーザーによって構成されます。非常に興味深い製品はActiviti（BPMエンジン）です。これはKarafコンテナーで動作し、Camelと統合できます。これにより、統合とビジネス機能を組み合わせた非常に興味深いソリューションを作成できます。

ServiceMix（Camel）およびRabbitMQに基づく統合プラットフォームの構築経験