简化软件集成:一个Apache Camel教程
|
軟件很少(如果有的話)存在于信息真空中。至少,這是我們軟件工程師可以為我們開發(fā)的大多數(shù)應(yīng)用程序做出的假設(shè)。
在任何規(guī)模上,每種軟件都以某種方式與其他軟件進行通信,出于各種原因:從某處獲取參考數(shù)據(jù),發(fā)送監(jiān)控信號,與其他服務(wù)保持聯(lián)系,同時作為分布式的一部分系統(tǒng)等等。
簡化軟件集成:一個Apache Camel教程
在本教程中,您將了解集成大型軟件的一些最大挑戰(zhàn),以及Apache Camel如何輕松解決這些難題。
問題:系統(tǒng)集成的體系結(jié)構(gòu)設(shè)計
在您的軟件工程中,您可能至少做了一次以下操作:
1.確定應(yīng)啟動數(shù)據(jù)發(fā)送的業(yè)務(wù)邏輯片段。
2.在相同的應(yīng)用程序?qū)?#xff0c;根據(jù)收件人的期望寫入數(shù)據(jù)轉(zhuǎn)換。
3.將數(shù)據(jù)封裝在適合通過網(wǎng)絡(luò)傳輸和路由的結(jié)構(gòu)中。
4.使用適當(dāng)?shù)尿?qū)動程序或客戶端SDK打開到目標(biāo)應(yīng)用程序的連接。
5.發(fā)送數(shù)據(jù)并處理響應(yīng)。
為什么這是一個不好的行為?
雖然你只有這種幾個連接,它仍然是可管理的。隨著系統(tǒng)之間關(guān)系的增加,應(yīng)用程序的業(yè)務(wù)邏輯與集成邏輯混合在一起,即集成數(shù)據(jù),補償兩個系統(tǒng)之間的技術(shù)差異,并通過SOAP,REST或更多異常請求將數(shù)據(jù)傳輸?shù)酵獠肯到y(tǒng)。
如果您要集成多個應(yīng)用程序,那么在這樣的代碼中追溯依賴關(guān)系的整個畫面是非常困難的:數(shù)據(jù)產(chǎn)生在哪里以及哪些服務(wù)使用它?您將有許多地方集成邏輯重復(fù),以引導(dǎo)。
有了這樣的方法,雖然這個任務(wù)在技術(shù)上已經(jīng)完成,但是我們在集成的可維護性和可伸縮性方面遇到了很大的問題。這個系統(tǒng)中數(shù)據(jù)流的快速重組幾乎是不可能的,更不用說更深層次的問題,比如缺少監(jiān)視,斷路,數(shù)據(jù)恢復(fù)等等。
當(dāng)將軟件集成到一個相當(dāng)大的企業(yè)的范圍時,這一點尤為重要。要處理企業(yè)集成,就意味著要與一組應(yīng)用程序一起工作,這些應(yīng)用程序運行在廣泛的平臺上,并且存在于不同的位置。在這樣一個軟件環(huán)境中,數(shù)據(jù)交換是相當(dāng)苛刻的。它必須符合行業(yè)的高安全標(biāo)準(zhǔn),并提供可靠的數(shù)據(jù)傳輸方式。在企業(yè)環(huán)境中,系統(tǒng)集成需要一個獨立的、全面的架構(gòu)設(shè)計。
本文將向您介紹軟件集成面臨的獨特困難,并為集成任務(wù)提供一些經(jīng)驗驅(qū)動的解決方案。我們將熟悉Apache Camel,這是一個有用的框架,可以減輕集成開發(fā)人員頭痛的最壞情況。我們將以駱駝如何幫助建立由Kubernetes提供支持的微服務(wù)集群中的通信為例。
整合困難
解決該問題的一個廣泛使用的方法是在應(yīng)用程序中分離一個集成層。它可以存在于同一個應(yīng)用程序中,也可以作為一個獨立運行的專用軟件 - 在后一種情況下稱為中間件。
在開發(fā)和支持中間件時,您通常會遇到什么問題?一般來說,你有以下關(guān)鍵點:
所有數(shù)據(jù)通道在一定程度上都不可靠。數(shù)據(jù)強度低到中等時,可能不會出現(xiàn)由此不可靠性引起的問題。從應(yīng)用程序內(nèi)存到下面的緩存和設(shè)備的每個存儲級別都可能出現(xiàn)故障。只有大量的數(shù)據(jù)才會出現(xiàn)一些罕見的錯誤。即使成熟的生產(chǎn)就緒供應(yīng)商產(chǎn)品也有未解決的與數(shù)據(jù)丟失有關(guān)的錯誤跟蹤器問題。一個中間件系統(tǒng)應(yīng)該能夠通知你這些數(shù)據(jù)的傷亡,并及時提供消息重新傳遞。
應(yīng)用程序使用不同的協(xié)議和數(shù)據(jù)格式。這意味著集成系統(tǒng)是數(shù)據(jù)轉(zhuǎn)換和適配器到其他參與者的帷幕,并利用了各種技術(shù)。這些方法可以包括簡單的REST API調(diào)用,但也可以訪問隊列代理,通過FTP發(fā)送CSV命令,或者將數(shù)據(jù)批量拖到數(shù)據(jù)庫表中。這是一張長長的單子,它不會變短的。
數(shù)據(jù)格式和路由規(guī)則的變化是不可避免的。應(yīng)用程序開發(fā)過程中的每個步驟都會改變數(shù)據(jù)結(jié)構(gòu),這通常會導(dǎo)致集成數(shù)據(jù)格式和轉(zhuǎn)換的變化。有時候,重組企業(yè)數(shù)據(jù)流的基礎(chǔ)設(shè)施變化是必要的。例如,引入一個驗證參考數(shù)據(jù)的單點時,可能會發(fā)生這些更改,這些參考數(shù)據(jù)必須處理整個公司的所有主數(shù)據(jù)條目。有了N系統(tǒng),我們最終可能N^2在它們之間有最大的連接,所以必須應(yīng)用更改的地方的數(shù)量增長得相當(dāng)快。這將像雪崩一樣。為了保持可維護性,中間件層必須通過多種路由和數(shù)據(jù)轉(zhuǎn)換提供清晰的依賴關(guān)系圖。
在設(shè)計集成和選擇最合適的中間件解決方案時,應(yīng)該牢記這些想法。處理這個問題的可能方法之一是利用企業(yè)服務(wù)總線(ESB)。但是主要供應(yīng)商提供的ESB通常過于沉重,而且往往比他們的價值更麻煩:ESB幾乎不可能快速啟動,它的學(xué)習(xí)曲線相當(dāng)陡峭,而且它的靈活性被犧牲于一長串的功能和內(nèi)置工具。在我看來,輕量級的開源集成解決方案要優(yōu)越得多 - 它們更具彈性,易于部署到云中,并且易于擴展。
軟件集成并不容易。今天,當(dāng)我們構(gòu)建微服務(wù)架構(gòu)并處理大量的小型服務(wù)時,我們對于它們應(yīng)該如何有效溝通也抱有很高的期望。
企業(yè)集成模式
正如所料,像一般的軟件開發(fā)一樣,數(shù)據(jù)路由和轉(zhuǎn)換的發(fā)展涉及重復(fù)的操作。經(jīng)過一段時間的處理整合問題的專業(yè)人員對這方面的經(jīng)驗進行了總結(jié)和系統(tǒng)化。在結(jié)果中,有一組稱為企業(yè)集成模式的提取模板,用于設(shè)計數(shù)據(jù)流。這些整合方法在Gregor Hophe和Bobby Wolfe的同名書中有描述,這很像“四人幫”的書,但是在膠合軟件方面。
舉一個例子,規(guī)范化模式引入了一個組件,它將具有不同數(shù)據(jù)格式的語義相同的消息映射到單個規(guī)范模型,或者聚合器是一個將一系列消息合并為一個的EIP。
由于它們是用于解決架構(gòu)問題的技術(shù)無關(guān)的抽象,所以EIP有助于編寫一個架構(gòu)設(shè)計,它不會深入到代碼級別,而是足夠詳細地描述數(shù)據(jù)流。這種描述整合路線的符號不僅使設(shè)計簡潔,而且在解決與各業(yè)務(wù)領(lǐng)域的團隊成員的整合任務(wù)的背景下,設(shè)置了一個通用的術(shù)語和通用的語言,這是非常重要的。
介紹Apache Camel
集成路由被寫成由塊組成的管道。它創(chuàng)建了一個完全透明的圖像來幫助追蹤數(shù)據(jù)流。
駱駝有許多流行的API適配器。例如,從Apache Kafka獲取數(shù)據(jù),監(jiān)控AWS EC2實例,與Salesforce集成 - 所有這些任務(wù)都可以使用現(xiàn)成的組件來解決。
幾年前,我正在一個大型食品雜貨零售網(wǎng)絡(luò)中建立一個企業(yè)集成體系,商店分布廣泛。我從一個專有的ESB解決方案開始,后來證明這個方案過于繁瑣。然后,我們的團隊遇到了Apache Camel,在做了一些“概念驗證”工作之后,我們很快地將所有的數(shù)據(jù)流改寫成了Camel路由。
Apache Camel可以被描述為一個“中介路由器”,它是一個面向消息的中間件框架,實現(xiàn)了我熟悉的EIP列表。它利用這些模式,支持所有常見的傳輸協(xié)議,并且包含了大量有用的適配器。駱駝能夠處理大量的集成例程,而無需編寫自己的代碼。
除此之外,我會選出下面的Apache Camel特性:
集成路由被寫成由塊組成的管道。它創(chuàng)建了一個完全透明的圖像來幫助追蹤數(shù)據(jù)流。
Camel有許多流行的API適配器。例如,從Apache Kafka獲取數(shù)據(jù),監(jiān)控AWS EC2實例,與Salesforce集成 - 所有這些任務(wù)都可以使用現(xiàn)成的組件來解決。
Apache Camel路由可以用Java或Scala DSL編寫。(XML配置也可用,但過于冗長,調(diào)試功能更差)。它不會對通信服務(wù)的技術(shù)堆棧施加限制,但是如果您使用Java或Scala編寫,則可以將Camel嵌入到應(yīng)用程序中獨立運行。
Camel使用的路由符號可以用下面的簡單偽代碼來描述:
|
|
的Source,Transformer以及Destination是指由其uri指向?qū)崿F(xiàn)組件的端點。
是什么讓Camel解決了我之前描述的整合問題?我們來看一下。首先,路由和轉(zhuǎn)換邏輯現(xiàn)在只能用于專門的Apache Camel配置。其次,通過簡潔自然的DSL結(jié)合EIP的使用,出現(xiàn)了系統(tǒng)之間的依賴關(guān)系圖。它由易理解的抽象構(gòu)成,路由邏輯易于調(diào)整。最后,我們不必編寫轉(zhuǎn)換代碼的堆,因為適當(dāng)?shù)倪m配器可能已經(jīng)包含在內(nèi)。
我應(yīng)該補充一點,Apache Camel是一個成熟的框架,并定期更新。它有一個偉大的社區(qū)和相當(dāng)龐大的知識庫。
它確實有它自己的缺點。駱駝不應(yīng)該被視為一個復(fù)雜的整合套件。這是一個沒有高級功能(如業(yè)務(wù)流程管理工具或活動監(jiān)視器)的工具箱,但可用于創(chuàng)建此類軟件。
替代系統(tǒng)可能是,例如Spring Integration或Mule ESB。對于Spring Integration來說,盡管它被認為是輕量級的,但根據(jù)我的經(jīng)驗,把它放在一起并編寫大量的XML配置文件可能會變得異常復(fù)雜,并且不是一個簡單的出路。Mule ESB是一個功能強大且功能強大的工具集,但顧名思義,它是一種企業(yè)服務(wù)總線,因此它屬于不同的權(quán)重類別。Mule可以與Fuse ESB進行比較,Fuse ESB是一款基于Apache Camel的類似產(chǎn)品,具有豐富的功能。對我來說,使用Apache Camel來粘貼服務(wù)是一件不容易的事情。它很容易使用,并產(chǎn)生一個干凈的描述,在什么地方,同時,它的功能足夠建設(shè)復(fù)雜的集成。
編寫一個示例路線
我們開始編寫代碼。我們將從一個同步數(shù)據(jù)流開始,這個數(shù)據(jù)流將消息從單一來源路由到收件人列表。路由規(guī)則將用Java DSL編寫。
我們將使用Maven構(gòu)建項目。首先將以下依賴項添加到pom.xml:
|
|
或者,應(yīng)用程序可以建立在camel-archetype-java原型之上。
Camel路徑定義在RouteBuilder.configure方法中聲明。
| public void configure() { Redeliveries(0)); Order.class) // unmarshal JSON to Order class containing List <OrderItem> process one by one ("Handling Drink"); ("dessertStation"). log("Handling Dessert"); ("hotMealStation"). log("Handling Hot Meal"); ("coldMealStation"). log("Handling Cold Meal"); .log("Handling Something Other"); |
在這個定義中,我們創(chuàng)建了一個從JSON文件中獲取記錄的路徑,將它們拆分成條目,并根據(jù)消息內(nèi)容路由到一組處理程序。
讓我們在準(zhǔn)備好的測試數(shù)據(jù)上運行它。我們將得到輸出:
|
camel-1) started in 10.716 seconds BodyType: com.antongoncharov.camel.example.model .OrderItem, Body: OrderItem{id='1', type='Drink', name='Americano', qty='1'}] BodyType: com.antongoncharov.camel.example.model.OrderItem, Body: OrderItem{id='2', type='Hot Meal', name='French Omelette', qty='1'}] BodyType: com.antongoncharov.camel.example. model. OrderItem, Body: OrderItem{id='3', type='Hot Meal', name='Lasagna', qty='1'}] BodyType: com.antongoncharov.camel.example.model.OrderItem, Body: OrderItem{id='4', type='Hot Meal', name='Rice Balls', qty='1'}] BodyType: com.antongoncharov.camel.example.model. OrderItem, Body: OrderItem{id='5', type='Dessert', name='Blueberry Pie', qty='1'}] |
正如所料,Camel路由消息到目的地。
數(shù)據(jù)傳輸選擇
在上面的示例中,組件之間的交互是同步的,并通過應(yīng)用程序內(nèi)存執(zhí)行。但是,當(dāng)我們處理不共享內(nèi)存的單獨應(yīng)用程序時,還有更多的通信方式:
1.文件交換。一個應(yīng)用程序產(chǎn)生共享數(shù)據(jù)文件供另一個使用。這是老派精神的生存之地。這種溝通方式帶來了諸多后果:缺乏交易和一致性,性能較差,系統(tǒng)之間的孤立協(xié)調(diào)。許多開發(fā)人員最終編寫了自制的集成解決方案,使這個過程或多或少地可以管理。
2.通用數(shù)據(jù)庫。讓應(yīng)用程序?qū)⑺麄兿M蚕淼臄?shù)據(jù)存儲在單個數(shù)據(jù)庫的通用模式中。設(shè)計統(tǒng)一模式和處理并發(fā)訪問表是這種方法最突出的挑戰(zhàn)。與文件交換一樣,這很容易成為永久的瓶頸。
3.遠程API調(diào)用。提供一個接口,允許應(yīng)用程序與另一個正在運行的應(yīng)用程序進行交互,如典型的方法調(diào)用。應(yīng)用程序通過API調(diào)用共享功能,但是它在過程中緊密耦合它們。
4.消息。讓每個應(yīng)用程序連接到一個通用的消息傳遞系統(tǒng),并使用消息異步交換數(shù)據(jù)和調(diào)用行為。發(fā)送者和接收者都不必同時啟動并運行消息。
有更多的交互方式,但是我們應(yīng)該記住,從廣義上講,有兩種類型的交互:同步和異步。第一個就像在你的代碼中調(diào)用一個函數(shù) - 執(zhí)行流程將一直等待,直到它執(zhí)行并返回一個值。使用異步方法,相同的數(shù)據(jù)通過中間消息隊列或訂閱主題發(fā)送。異步遠程函數(shù)調(diào)用可以作為請求 - 回復(fù)EIP來實現(xiàn)。
異步消息傳遞不是萬能的,它涉及到一定的限制。您很少在網(wǎng)絡(luò)上看到消息API; 同步REST服務(wù)更受歡迎。但是消息中間件被廣泛用于企業(yè)內(nèi)部網(wǎng)或分布式系統(tǒng)后端基礎(chǔ)設(shè)施。
使用消息隊列
讓我們的示例異步。管理隊列和訂閱主題的軟件系統(tǒng)稱為消息代理。這就像一個表和列的RDBMS。隊列用作點對點集成,而主題用于與許多接收者的發(fā)布 - 訂閱通信。我們將使用Apache ActiveMQ作為JMS消息代理,因為它是可靠且可嵌入的。
添加以下依賴項。有時activemq-all,向項目中添加包含所有ActiveMQ jar 的過度,但我們會保持我們的應(yīng)用程序的依賴關(guān)系不復(fù)雜。
|
|
然后以編程方式啟動代理。在Spring Boot中,通過插入spring-boot-starter-activemqMaven依賴關(guān)系,我們得到了一個自動配置。
使用以下命令運行新的消息代理,只指定連接器的端點:
|
|
并將以下配置片段添加到configure方法體:
|
|
現(xiàn)在我們可以使用消息隊列來更新前面的例子。隊列將自動創(chuàng)建消息傳遞。
| public void configure() { liveries(0)); // unmarshal JSON to Order class containing List<OrderItem> to process one by one log("Drinks"); ("dessertAsync").log("Dessert"); ("coldMealAsync").log("Cold Meals"); .log("Others"); |
好了,現(xiàn)在交互已經(jīng)變得異步了。這些數(shù)據(jù)的潛在消費者在準(zhǔn)備好時可以訪問它。這是一個松耦合的例子,我們試圖在一個被動的架構(gòu)中實現(xiàn)。其中一項服務(wù)不可用將不會阻止其他服務(wù)。而且,消費者可以并行地從隊列中縮放和讀取。隊列本身可以擴展和分區(qū)。持久隊列可以將數(shù)據(jù)存儲在磁盤上,等待處理,即使所有參與者都關(guān)閉了。因此,這個系統(tǒng)更容錯。
一個驚人的事實是,CERN使用Apache Camel和ActiveMQ來監(jiān)視大型強子對撞機(LHC)的系統(tǒng)。還有一個有趣的碩士論文解釋了為這個任務(wù)選擇合適的中間件解決方案。所以,正如他們在主題演講中所說:“沒有JMS-沒有粒子物理學(xué)!”
監(jiān)控
在前面的例子中,我們創(chuàng)建了兩個服務(wù)之間的數(shù)據(jù)通道。這是架構(gòu)中一個額外的潛在失敗點,所以我們必須照顧它。我們來看看Apache Camel提供的監(jiān)視功能。基本上,它通過JMX提供有關(guān)其路由的統(tǒng)計信息。ActiveMQ以相同的方式公開隊列統(tǒng)計信息。
我們打開應(yīng)用程序中的JMX服務(wù)器,使其能夠使用命令行選項運行:
|
ctor=true inName=org.apache.camel registryPort=1099 =camel |
現(xiàn)在運行該應(yīng)用程序,以便該路線已完成其工作。打開標(biāo)準(zhǔn)jconsole工具并連接到應(yīng)用程序進程。連接到網(wǎng)址service:jmx:rmi:///jndi/rmi://localhost:1099/camel。轉(zhuǎn)到MBeans樹中的org.apache.camel域。
我們可以看到,關(guān)于路由的一切都在控制之中。我們有正在進行的消息的數(shù)量,錯誤計數(shù)和隊列中的消息計數(shù)。這些信息可以通過流水線連接到一些監(jiān)視工具集,如Graphana或Kibana。你可以通過實現(xiàn)知名的ELK棧來做到這一點。
還有一個可插拔和可擴展的Web控制臺提供了一個用戶界面,用于管理駱駝的ActiveMQ,和更多的人,叫hawt.io。
測試路線
Apache Camel具有相當(dāng)廣泛的功能,可以用模擬組件編寫測試路由。這是一個強大的工具,但是為了測試而編寫單獨的路由是一個耗時的過程。在生產(chǎn)線上運行測試而不修改管線會更有效率。駱駝有這個功能,可以使用AdviceWith組件來實現(xiàn)。
讓我們在我們的示例中啟用測試邏輯并運行示例測試。
|
|
測試類是:
|
|
現(xiàn)在運行與應(yīng)用程序的測試mvn test。我們可以看到,我們的路線已經(jīng)成功地通過了測試建議。沒有消息通過實際的隊列傳遞,測試已經(jīng)通過。
| INFO | Route: main started and consuming from: file://testInbox |
今天的一個集成問題是應(yīng)用程序不再是靜態(tài)的。在云基礎(chǔ)架構(gòu)中,我們同時處理在多個節(jié)點上運行的虛擬服務(wù)。它使得微服務(wù)架構(gòu)能夠與小型,輕量級服務(wù)網(wǎng)絡(luò)相互作用。這些服務(wù)的壽命是不可靠的,我們必須動態(tài)地發(fā)現(xiàn)它們。
將云服務(wù)合并在一起是Apache Camel可以解決的任務(wù)。特別有趣的是,由于EIP的風(fēng)格和駱駝有足夠的適配器和支持多種協(xié)議的事實。最近的2.18版本添加了ServiceCall組件,該組件引入了調(diào)用API并通過集群發(fā)現(xiàn)機制解析其地址的功能。目前,它支持Consul,Kubernetes,Ribbon等。可以很容易地找到代理的一些例子,其中ServiceCall用Consul配置。我們將在這里使用Kubernetes,因為這是我最喜歡的集群解決方案。
整合架構(gòu)如下:
該Order服務(wù)和Inventory服務(wù)將是一個簡單的Spring Boot應(yīng)用程序返回靜態(tài)數(shù)據(jù)。我們不是綁定在這里的一個特定的技術(shù)堆棧。這些服務(wù)正在產(chǎn)生我們想要處理的數(shù)據(jù)。
訂購服務(wù)控制器:
| @RestController |
它以如下格式產(chǎn)生數(shù)據(jù):
| [{"id":1,"items":[2,3,4]},{"id":2,"items":[5,3]}] |
該Inventory服務(wù)控制器是完全類似Order服務(wù)的:
| @RestController |
InventoryStorage是保存數(shù)據(jù)的通用存儲庫。在這個例子中,它返回靜態(tài)預(yù)定義的對象,這些對象被封送到下面的格式。
| [{"id":1,"name":"Laptop","description":"Up to 12-hours battery life","price":499.9},{"id":2,"name" |
讓我們編寫一個連接它們的網(wǎng)關(guān)路由,但在這個步驟中沒有ServiceCall:
|
/json")) =true") json")) true") |
現(xiàn)在想象一下,每個服務(wù)不再是一個特定的實例,而是一個運行一個實例的云。我們將使用Minikube在本地嘗試Kubernetes集群。
配置網(wǎng)絡(luò)路由以在本地查看Kubernetes節(jié)點(
|
in minikube? {print $2}’? previous command? for testing ? |
給出的示例適用于Mac / Linux環(huán)境):
使用Dockerfile配置將服務(wù)包裝在Docker容器中,如下所示:
|
-jar /app.jar |
構(gòu)建并將服務(wù)映像推送到Docker注冊表。現(xiàn)在運行本地Kubernetes集群中的節(jié)點。
Kubernetes.yaml部署配置:
| apiVersion: extensions/v1beta1 |
將這些部署作為集群中的服務(wù)公開:
|
|
現(xiàn)在我們可以檢查請求是否由集群中隨機選擇的節(jié)點提供服務(wù)。curl -X http://192.168.99.100:30517/info依次運行幾次以訪問minikube NodePort以獲得公開的服務(wù)(使用您的主機和端口)。在輸出中,我們看到我們已經(jīng)實現(xiàn)了請求平衡。
| Inventory Service UUID = 22f8ca6b-f56b-4984-927b-cbf9fcf81da5 |
添加camel-kubernetes和camel-netty4-http依賴項目的pom.xml。然后將ServiceCall組件配置為使用共享路徑定義中的所有服務(wù)調(diào)用的Kubernetes主節(jié)點發(fā)現(xiàn):
|
new KubernetesConfiguration(); .168.64.2:8443"); /antongoncharov/.minikube/client.crt"); /antongoncharov/.minikube/client.key"); ServiceCallConfigurationDefinition(); rviceDiscovery(kubernetesCon figuration)); |
ServiceCall EIP完善了Spring Boot。大多數(shù)選項可以直接在application.properties文件中配置。
使用ServiceCall組件授權(quán)Camel 路由:
| rest("/orders") |
我們還啟動了路線中的斷路器。這是一個集成掛鉤,允許在發(fā)送錯誤或收件人不可用的情況下暫停遠程系統(tǒng)調(diào)用。這旨在避免級聯(lián)系統(tǒng)故障。Hystrix組件通過實現(xiàn)斷路器模式來幫助實現(xiàn)這一點。
讓我們運行它并發(fā)送測試請求; 我們會得到這兩個服務(wù)聚合的響應(yīng)。
| [{"id":1,"items":[{"id":2,"name":"Monitor","description":"27-inch, response time: 7ms","price":200 |
結(jié)果如預(yù)期。
其他用例
我展示了Apache Camel如何在一個集群中集成微服務(wù)。這個框架的其他用途是什么?一般來說,在基于規(guī)則的路由可能是解決方案的任何地方都是有用的。例如,Apache Camel可以成為Eclipse Kura適配器的物聯(lián)網(wǎng)中間件。它可以處理來自各種組件和服務(wù)的日志信號的監(jiān)視,就像在CERN系統(tǒng)中一樣。它也可以是企業(yè)級SOA的集成框架,也可以是批量數(shù)據(jù)處理的管道,雖然它在這方面與Apache Spark沒有很好的競爭。
結(jié)論
你可以看到系統(tǒng)集成不是一個簡單的過程。我們很幸運,因為收集了很多經(jīng)驗。正確應(yīng)用它來構(gòu)建靈活和容錯的解決方案非常重要。
為了確保正確的應(yīng)用,我建議有一個重要的集成方面的清單。必須具備的項目包括:
1.是否有單獨的集成層?
2.是否有集成測試?
3.我們知道預(yù)期的峰值數(shù)據(jù)強度嗎?
4.我們是否知道預(yù)期的數(shù)據(jù)交付時間?
5.消息相關(guān)性是否重要?如果序列中斷?
6.我們應(yīng)該以同步還是異步的方式來做?
7.格式和路由規(guī)則更頻繁地變化在哪里?
8.我們有辦法監(jiān)督這個過程嗎?
在本文中,我們嘗試了Apache Camel,這是一個輕量級集成框架,可幫助您在解決集成問題時節(jié)省時間和精力。正如我們所展示的,它可以作為一個工具,支持相關(guān)的微服務(wù)體系結(jié)構(gòu),全面負責(zé)微服務(wù)之間的數(shù)據(jù)交換。
from:?http://www.uml.org.cn/zjjs/201801181.asp
總結(jié)
以上是生活随笔為你收集整理的简化软件集成:一个Apache Camel教程的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java 7 源码学习系列(一)——St
- 下一篇: Apache Camel:基于企业集成模