spring 消息傳遞機制

在上一篇文章中，我們已經開始討論基于消息的通信中的消費者驅動的合同測試 。 在今天的帖子中，我們將在測試工具箱中包含另一個工具，但是在此之前，讓我對顯微鏡下的系統(tǒng)進行快速回顧。 它有兩項服務， 訂單服務和貨運服務 。 訂單服務將消息/事件發(fā)布到消息隊列，然后運貨服務從那里使用它們。

通過尋找合適的測試支架，我們發(fā)現了Pact框架（準確地說是Pact JVM ）。 該協(xié)議提供了編寫消費者和生產者測試的簡單明了的方法，沒有為不進行消費者驅動的合同測試提供任何借口。 但是，該領域還有另一個參與者Spring Cloud Contract ，這就是我們今天要討論的內容。

首先， Spring Cloud Contract適合基于最佳的基于JVM的項目，該項目建立在出色的Spring產品組合之上（盡管您也可以使其在多語言場景中工作）。 另外， Spring Cloud Contract采用的協(xié)作流程與Pact教給我們的協(xié)作流程略有不同，這不一定是一件壞事。 讓我們直接說清楚。

由于我們只研究消息傳遞，因此Spring Cloud Contract要求我們要做的第一件事就是定義消息傳遞協(xié)議規(guī)范，該規(guī)范是使用便捷的Groovy Contract DSL編寫的。

package contracts org.springframework.cloud.contract.spec.Contract.make { name "OrderConfirmed Event" label 'order' ????input { 'createOrder()' triggeredBy( 'createOrder()' ) } ????outputMessage { sentTo 'orders' ????????body([ orderId: $(anyUuid()), paymentId: $(anyUuid()), amount: $(anyDouble()), street: $(anyNonBlankString()), city: $(anyNonBlankString()), state: $(regex( '[AZ]{2}' )), zip: $(regex( '[0-9]{5}' )), country: $(anyOf( 'USA' , 'Mexico' )) ]) ????????headers { header( 'Content-Type' , 'application/json' ) } } }

它類似于我們已經熟悉的許多Pact規(guī)范（如果您不是Groovy的忠實擁護者 ，則不需要真正學習它即可使用Spring Cloud Contract ）。 這里有趣的部分是triggeredBy和sentTo塊：基本上，這些輪廓是如何被生成的消息（或觸發(fā)），并且其中它應該分別著陸（通道或隊列名稱）。 在這種情況下， createOrder（）只是方法名稱，我們必須為其提供實現。

package com.example.order; import java.math.BigDecimal; import java.util.UUID; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.cloud.contract.verifier.messaging.boot.AutoConfigureMessageVerifier; import org.springframework.integration.support.MessageBuilder; import org.springframework.messaging.MessageChannel; import org.springframework.test.context.junit4.SpringRunner; import com.example.order.event.OrderConfirmed; @RunWith (SpringRunner. class ) @SpringBootTest @AutoConfigureMessageVerifier public class OrderBase { @Autowired private MessageChannel orders; ????public void createOrder() { final OrderConfirmed order = new OrderConfirmed(); order.setOrderId(UUID.randomUUID()); order.setPaymentId(UUID.randomUUID()); order.setAmount( new BigDecimal( "102.32" )); order.setStreet( "1203 Westmisnter Blvrd" ); order.setCity( "Westminster" ); order.setCountry( "USA" ); order.setState( "MI" ); order.setZip( "92239" ); orders.send( MessageBuilder .withPayload(order) .setHeader( "Content-Type" , "application/json" ) .build()); } }

不過，這里只剩下一個小細節(jié)：這些合同是由提供者（或更確切地說，生產者）而不是消費者來管理的。 不僅如此，生產者有責任為消費者發(fā)布所有存根，以便他們能夠針對其編寫測試。 當然，與Pact所采用的路徑不同，但是從好的方面來說，針對生產者的測試套件是由Apache Maven / Gradle插件100％生成的。

< plugin > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-contract-maven-plugin</ artifactId > < version >2.1.4.RELEASE</ version > < extensions >true</ extensions > < configuration > < packageWithBaseClasses >com.example.order</ packageWithBaseClasses > </ configuration > </ plugin >

您可能已經注意到，該插件將假定基本測試類（必須提供createOrder（）方法實現的那些類）位于com.example.order包中，即我們放置OrderBase類的確切位置。 要完成設置，我們需要向pom.xml文件中添加一些依賴項。

< dependencyManagement > < dependencies > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-dependencies</ artifactId > < version >Greenwich.SR4</ version > < type >pom</ type > < scope >import</ scope > </ dependency > < dependency > < groupId >org.springframework.boot</ groupId > < artifactId >spring-boot-dependencies</ artifactId > < version >2.1.10.RELEASE</ version > < type >pom</ type > < scope >import</ scope > </ dependency > </ dependencies > </ dependencyManagement > < dependencies > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-starter-contract-verifier</ artifactId > < scope >test</ scope > </ dependency > < dependency > < groupId >org.springframework.boot</ groupId > < artifactId >spring-boot-starter-test</ artifactId > < scope >test</ scope > </ dependency > </ dependencies >

而且我們已經完成了生產者方面的工作！ 如果我們現在運行mvn clean install ，將發(fā)生兩件事。 首先，您會注意到已經運行并通過了一些測試，盡管我們沒有編寫任何測試，但這些測試都是以我們的名義生成的。

------------------------------------------------------- TESTS ------------------------------------------------------- Running com.example.order.OrderTest .... Results : Tests run: 1 , Failures: 0 , Errors: 0 , Skipped: 0

其次，也將生成（發(fā)布）針對消費者的存根（在這種情況下，將其捆綁到order-service-messaging-contract-tests-0.0.1-SNAPSHOT-stubs.jar中 ）。

... [INFO] [INFO] --- spring-cloud-contract-maven-plugin: 2.1 . 4 .RELEASE:generateStubs ( default -generateStubs) @ order-service-messaging-contract-tests --- .RELEASE:generateStubs ( [INFO] Files matching this pattern will be excluded from stubs generation [] [INFO] Files matching pattern will be excluded from stubs generation [] [INFO] Building jar: order-service-messaging-contract-tests- 0.0 . 1 -SNAPSHOT-stubs.jar [INFO] ....

太好了，因此我們已經發(fā)布了消息傳遞合同規(guī)范和存根，現在就在消費者的領域，即Shipment Service 。 消費者最棘手的部分可能是配置所選的消息傳遞集成庫。 在我們的案例中，它將是Spring Cloud Stream，但是也可以使用其他集成 。

理解Spring Cloud Contract在消費者方面如何工作的最快方法是從頭開始，并首先查看完整的示例測試套件。

@RunWith (SpringRunner. class ) @SpringBootTest @AutoConfigureMessageVerifier @AutoConfigureStubRunner ( ids = "com.example:order-service-messaging-contract-tests:+:stubs" , stubsMode = StubRunnerProperties.StubsMode.LOCAL ) public class OrderMessagingContractTest { @Autowired private MessageVerifier<Message<?>> verifier; @Autowired private StubFinder stubFinder; @Test public void testOrderConfirmed() throws Exception { stubFinder.trigger( "order" ); ????????final Message<?> message = verifier.receive( "orders" ); assertThat(message, notNullValue()); assertThat(message.getPayload(), isJson( allOf(List.of( withJsonPath( "$.orderId" ), withJsonPath( "$.paymentId" ), withJsonPath( "$.amount" ), withJsonPath( "$.street" ), withJsonPath( "$.city" ), withJsonPath( "$.state" ), withJsonPath( "$.zip" ), withJsonPath( "$.country" ) )))); } }

在最上方， @AutoConfigureStubRunner引用生產者發(fā)布的存根，有效地來自order-service-messaging-contract-tests-0.0.1-SNAPSHOT-stubs.jar存檔中的存根 。 StubFinder通過調用stubFinder.trigger（“ order”）幫助我們?yōu)闇y試用例選擇正確的存根，并觸發(fā)特定的消息傳遞合同驗證流程。 “ order”值不是任意的，它應與分配給合同規(guī)范的標簽匹配，在我們的示例中，我們將其定義為：

package contracts org.springframework.cloud.contract.spec.Contract.make { ... label 'order' ... }

這樣，測試應該看起來簡單而直接：觸發(fā)流程，驗證消息是否已放入消息傳遞通道并滿足消費者的期望。 從配置的角度來看，我們只需要提供此消息傳遞通道即可運行測試。

@SpringBootConfiguration public class OrderMessagingConfiguration { @Bean PollableChannel orders() { return MessageChannels.queue().get(); } }

再說一次，bean的名稱orders不是一個隨機選擇，它必須從合同規(guī)范中獲取很多目的地：

package contracts org.springframework.cloud.contract.spec.Contract.make { ... outputMessage { sentTo 'orders' ... } ... }

最后但并非最不重要的一點，讓我們枚舉使用者方面所需的依賴關系（幸運的是，無需使用任何其他的Apache Maven或Gradle插件）。

< dependencyManagement > < dependencies > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-dependencies</ artifactId > < version >Greenwich.SR4</ version > < type >pom</ type > < scope >import</ scope > </ dependency > </ dependencies > </ dependencyManagement > < dependencies > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-starter-contract-verifier</ artifactId > < scope >test</ scope > </ dependency > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-starter-contract-stub-runner</ artifactId > < scope >test</ scope > </ dependency > < dependency > < groupId >org.springframework.cloud</ groupId > < artifactId >spring-cloud-stream</ artifactId > < version >2.2.1.RELEASE</ version > < type >test-jar</ type > < scope >test</ scope > < classifier >test-binder</ classifier > </ dependency > </ dependencies >

在這里快速說明。 最后一個依賴關系是一個很重要的難題，它帶來了Spring Cloud Stream與Spring Cloud Contract的集成。 這樣，消費者就全都準備好了。

------------------------------------------------------- TESTS ------------------------------------------------------- Running com.example.order.OrderMessagingContractTest ... Results : Tests run: 1 , Failures: 0 , Errors: 0 , Skipped: 0

為了結束循環(huán)，我們應該回顧消費者驅動的合同測試的核心承諾之一：允許生產者在不破壞消費者的情況下發(fā)展合同。 實際上，這意味著消費者可以將測試歸還給生產者，盡管這樣做的輕率性與Spring Cloud Contract無關 。 原因很簡單：生產者是那些首先編寫消息合同規(guī)范的人，并且期望從這些規(guī)范中生成的測試無法抵御任何重大更改。 盡管如此，對于生產者來說，了解消費者如何使用他們的消息還是有很多好處的，所以請給我一些想法。

滿懷希望，這是一個有趣的話題。 Spring Cloud Contract帶來了將消費者驅動的合約測試應用于消息傳遞的不同觀點。 它是Pact JVM的一個有吸引力的替代方法，特別是如果您的應用程序和服務已經依賴Spring項目 。

與往常一樣，完整的項目資源可在Github上找到 。

翻譯自: https://www.javacodegeeks.com/2019/12/spring-covered-again-consumer-driven-contract-testing-messaging-continued.html

spring 消息傳遞機制

總結

以上是生活随笔為你收集整理的spring 消息传递机制_Spring再次涵盖了您：继续进行消费者驱动的消息传递合同测试...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。