一，前言
Spring-Integration基於Spring，在應用程式中啟用了輕量級訊息傳遞，並支援通過宣告式介面卡與外部系統整合。這一段官網的介紹，概況了整個Integration的用途。個人感覺訊息傳遞是真正的重點。
如上圖所示，典型的生產者-消費者模式，中間通過一個特定的通道進行資料傳輸，說到這，是不是隱隱感覺到queue的存在。確實事實上這個所謂的通道預設就是用的 blockingqueue。
Spring-Integration網上的資料是真少，再加上原始碼分析的是更少。關於Spring-Integration的基本介紹直接去官網上看更加的直觀，這邊就不累述了。
今天主要是看個簡單的hello word進來分析下整個執行過程。
先看下程式碼：
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
https://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
https://www.springframework.org/schema/integration/spring-integration.xsd">
<annotation-config/>
<channel id="oc" >
<queue/>
</channel>
<beans:bean id="Beans" class="com.example.demo.Beans"/>
</beans:beans>
@Configuration
public class Beans {
@ServiceActivator(inputChannel = "ic", outputChannel = "oc")
public String sayHello(String name) {
return "Hello " + name;
}
}
public class HelloWorldDemo {
@Test
public void testDemo() throws Exception {
ClassPathXmlApplicationContext context =
new ClassPathXmlApplicationContext("/demo.xml", HelloWorldDemo.class);
DirectChannel inputChannel = context.getBean("ic", DirectChannel.class);
PollableChannel outputChannel = context.getBean("oc", PollableChannel.class);
inputChannel.send(new GenericMessage<String>("World"));
System.out.println("==> HelloWorldDemo: " + outputChannel.receive(0).getPayload());
context.close();
}
}
out:
==> HelloWorldDemo: Hello World
二，ServiceActivator
上面的程式碼演示了呼叫方法的入站通道介面卡和標準的出站通道介面卡， 它們之間是一個帶註解的ServiceActivator。關於這個ServiceActivator就是一個訊息端點。
訊息端點的主要作用是以非侵入性方式將應用程式程式碼連線到訊息傳遞框架。換句話說，理想情況下，應用程式程式碼應該不知道訊息物件或訊息管道。這類似於 MVC 正規化中controller 的作用。正如controller 處理 HTTP 請求一樣，訊息端點處理訊息。以及controller 對映到 URL 模式一樣，訊息端點對映到訊息通道。這兩種情況的目標是相同的。
ServiceActivator是用於將服務例項連線到訊息傳遞系統的通用端點。必須配置輸入訊息通道，如果要呼叫的服務方法能夠返回值，還可以提供輸出訊息通道。
具體流程如下圖：
上面的程式碼比較簡單，但是或許會發現我們只定義了輸出通道oc，輸入通道ic竟然沒有定義也能正常應用，是不是很奇怪？帶著疑問我們先看下ServiceActivator的原始碼：
註釋上寫的很清楚，如果輸入通道不存在，將在應用程式上下文中註冊具有此名稱的DirectChannel 。具體在哪定義，我們後面會看到，現在不急，先一步步來看他的執行過程。
我們全域性查詢ServiceActivator，看他是哪邊進行處理的，最後發現了MessagingAnnotationPostProcessor類，用來處理方法級訊息註解的BeanPostProcessor實現。
@Override
public void afterPropertiesSet() {
Assert.notNull(this.beanFactory, "BeanFactory must not be null");
((BeanDefinitionRegistry) this.beanFactory).registerBeanDefinition(
IntegrationContextUtils.DISPOSABLES_BEAN_NAME,
BeanDefinitionBuilder.genericBeanDefinition(Disposables.class, Disposables::new)
.getRawBeanDefinition());
this.postProcessors.put(Filter.class, new FilterAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(Router.class, new RouterAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(Transformer.class, new TransformerAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(ServiceActivator.class, new ServiceActivatorAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(Splitter.class, new SplitterAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(Aggregator.class, new AggregatorAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(InboundChannelAdapter.class,
new InboundChannelAdapterAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(BridgeFrom.class, new BridgeFromAnnotationPostProcessor(this.beanFactory));
this.postProcessors.put(BridgeTo.class, new BridgeToAnnotationPostProcessor(this.beanFactory));
Map<Class<? extends Annotation>, MethodAnnotationPostProcessor<?>> customPostProcessors =
setupCustomPostProcessors();
if (!CollectionUtils.isEmpty(customPostProcessors)) {
this.postProcessors.putAll(customPostProcessors);
}
}
在afterPropertiesSet方法中，我們看到定義了一個後處理器postProcessors，裡面註冊了相關的註解處理類。包含各種訊息端點處理，除了上面寫的ServiceActivator，還有過濾器，路由，轉換器等各種不同的端點方法。
接著往向下看，既然實現了BeanPostProcessor，那必然要用到postProcessAfterInitialization方法實現，這裡的流程大概就是遍歷出包含有@ServiceActivator的bean方法，用來做後續處理。我們直接看重點的程式碼。
Object result = postProcessor.postProcess(bean, beanName, targetMethod, annotations);
三，postProcess
在AbstractMethodAnnotationPostProcessor中有個共通方法postProcess用來生成對應的端點資訊。具體程式碼：
@Override
public Object postProcess(Object bean, String beanName, Method method, List<Annotation> annotations) {
Object sourceHandler = null;
if (beanAnnotationAware() && AnnotatedElementUtils.isAnnotated(method, Bean.class.getName())) {
if (!this.beanFactory.containsBeanDefinition(resolveTargetBeanName(method))) {
this.logger.debug("Skipping endpoint creation; perhaps due to some '@Conditional' annotation.");
return null;
}
else {
sourceHandler = resolveTargetBeanFromMethodWithBeanAnnotation(method);
}
}
//生成對應的MessageHandler，用來執行對應的註解的方法
MessageHandler handler = createHandler(bean, method, annotations);
if (!(handler instanceof ReactiveMessageHandlerAdapter)) {
orderable(method, handler);
producerOrRouter(annotations, handler);
if (!handler.equals(sourceHandler)) {
handler = registerHandlerBean(beanName, method, handler);
}
handler = annotated(method, handler);
handler = adviceChain(beanName, annotations, handler);
}
//將MessageHandler實現連線到訊息端點，生成對應的endpoint。
AbstractEndpoint endpoint = createEndpoint(handler, method, annotations);
if (endpoint != null) {
return endpoint;
}
else {
return handler;
}
}
這裡面主要是兩件事：
- 根據模板模式中不同的createHandler抽象方法實現，生成對應的MessageHandler。譬如說我們這邊的
ServiceActivatorAnnotationPostProcessor - 將MessageHandler實現連線到訊息端點，生成對應的endpoint。
1.createHandler
@Override
protected MessageHandler createHandler(Object bean, Method method, List<Annotation> annotations) {
AbstractReplyProducingMessageHandler serviceActivator;
if (AnnotatedElementUtils.isAnnotated(method, Bean.class.getName())) {
...
else {
serviceActivator = new ServiceActivatingHandler(bean, method);
}
String requiresReply = MessagingAnnotationUtils.resolveAttribute(annotations, "requiresReply", String.class);
if (StringUtils.hasText(requiresReply)) {
serviceActivator.setRequiresReply(resolveAttributeToBoolean(requiresReply));
}
String isAsync = MessagingAnnotationUtils.resolveAttribute(annotations, "async", String.class);
if (StringUtils.hasText(isAsync)) {
serviceActivator.setAsync(resolveAttributeToBoolean(isAsync));
}
//是否設定了輸出通道
setOutputChannelIfPresent(annotations, serviceActivator);
return serviceActivator;
}
createHandler的程式碼比較簡單，就是根據註解中的幾個屬性還有對應的方法引數，生成ServiceActivatingHandler。追溯下去ServiceActivatingHandler中最後會生成一個委託物件MessagingMethodInvokerHelper用來以反射的方式來執行目標方法。
2.createEndpoint
createEndpoint字面上都能知道是生成訊息端點，事實上也是，把生成的handler和對應的管道進行關聯。具體看下程式碼體會：
protected AbstractEndpoint createEndpoint(MessageHandler handler, @SuppressWarnings("unused") Method method,
List<Annotation> annotations) {
AbstractEndpoint endpoint = null;
//取得註解中inputChannelName
String inputChannelName = MessagingAnnotationUtils.resolveAttribute(annotations, getInputChannelAttribute(),
String.class);
if (StringUtils.hasText(inputChannelName)) {
MessageChannel inputChannel;
try {
//從beanFactory中取得對應的通道bean
inputChannel = this.channelResolver.resolveDestination(inputChannelName);
}
catch (DestinationResolutionException e) {
//取不到，則自動註冊一個型別為DirectChannel的inputChannel
if (e.getCause() instanceof NoSuchBeanDefinitionException) {
inputChannel = new DirectChannel();
this.beanFactory.registerSingleton(inputChannelName, inputChannel);
inputChannel = (MessageChannel) this.beanFactory.initializeBean(inputChannel, inputChannelName);
if (this.disposables != null) {
this.disposables.add((DisposableBean) inputChannel);
}
}
else {
throw e;
}
}
Assert.notNull(inputChannel, () -> "failed to resolve inputChannel '" + inputChannelName + "'");
//生成endpoint
endpoint = doCreateEndpoint(handler, inputChannel, annotations);
}
return endpoint;
}
上面的程式碼中，我們就能清楚的看到為什麼我們在demo中沒有註冊輸入通道也能正常應用的原因了，從而回答之前的疑問。
protected AbstractEndpoint doCreateEndpoint(MessageHandler handler, MessageChannel inputChannel,
List<Annotation> annotations) {
....
else if (inputChannel instanceof SubscribableChannel) {
//生成SubscribableChannel型別對應的執行端點
return new EventDrivenConsumer((SubscribableChannel) inputChannel, handler);
}
else if (inputChannel instanceof PollableChannel) {
return pollingConsumer(inputChannel, handler, pollers);
}
else {
throw new IllegalArgumentException("Unsupported 'inputChannel' type: '"
+ inputChannel.getClass().getName() + "'. " +
"Must be one of 'SubscribableChannel', 'PollableChannel' or 'ReactiveStreamsSubscribableChannel'");
}
}
通道型別一共有兩種，一種是釋出訂閱，一種是可輪詢的，我們是預設是走的第一種，因為DirectChannel預設就是個SubscribableChannel。所以最終我們生成了對應的資訊端點類EventDrivenConsumer。
我們先看下EventDrivenConsumer整體結構：
EventDrivenConsumer上面有一個抽象類AbstractEndpoint，最上面實現了Lifecycle介面，所以生命週期跟著容器走，我們直接跳到star方法看：
@Override
protected void doStart() {
this.logComponentSubscriptionEvent(true);
//把handler和inputChannel進行繫結
this.inputChannel.subscribe(this.handler);
if (this.handler instanceof Lifecycle) {
((Lifecycle) this.handler).start();
}
}
@Override
public synchronized boolean addHandler(MessageHandler handler) {
Assert.notNull(handler, "handler must not be null");
Assert.isTrue(this.handlers.size() < this.maxSubscribers, "Maximum subscribers exceeded");
boolean added = this.handlers.add(handler);
if (this.handlers.size() == 1) {
this.theOneHandler = handler;
}
else {
this.theOneHandler = null;
}
return added;
}
上面的程式碼主要就是把handler註冊到inputChannel中，這樣只要inputChannel通道一收到資訊，就會通知他註冊的handlers進行處理。程式碼中比較清楚的記錄了一切的操作，就不多解釋了。
四，傳送資訊
執行完上面一系列的註冊，已經把這一些的通道打通了，剩下的就是真正的傳送操作了。下面分析下inputChannel.send(new GenericMessage<String>("World"));看看send操作：
/**
* 在此頻道上傳送訊息。 如果通道已滿，則此方法將阻塞，直到發生超時或傳送執行緒中斷。 如果指定的超時時間為 0，則該方法將立即返回。 如果小於零，它將無限期阻塞（請參閱send(Message) ）。
* 引數：
* messageArg – 要傳送的訊息
* timeout - 以毫秒為單位的超時時間
* 返回：
* true如果訊息傳送成功， false如果訊息無法在規定時間內傳送或傳送執行緒被中斷
*/
@Override
public boolean send(Message<?> messageArg, long timeout) {
...
try {
//message是否需要轉換
message = convertPayloadIfNecessary(message);
//傳送前攔截器
if (interceptorList.getSize() > 0) {
interceptorStack = new ArrayDeque<>();
message = interceptorList.preSend(message, this, interceptorStack);
if (message == null) {
return false;
}
}
if (this.metricsCaptor != null) {
sample = this.metricsCaptor.start();
}
//傳送操作
sent = doSend(message, timeout);
if (sample != null) {
sample.stop(sendTimer(sent));
}
metricsProcessed = true;
if (debugEnabled) {
logger.debug("postSend (sent=" + sent + ") on channel '" + this + "', message: " + message);
}
//傳送後攔截器
if (interceptorStack != null) {
interceptorList.postSend(message, this, sent);
interceptorList.afterSendCompletion(message, this, sent, null, interceptorStack);
}
return sent;
}
catch (Exception ex) {
...
}
}
真正的send操作跟下去，會發現層次極深，礙於篇幅，我們直接跟到重點程式碼：
@Override
protected final void handleMessageInternal(Message<?> message) {
Object result;
if (this.advisedRequestHandler == null) {
//反射執行對應的端點方法
result = handleRequestMessage(message);
}
else {
result = doInvokeAdvisedRequestHandler(message);
}
if (result != null) {
//往outputChannel傳送執行結果
sendOutputs(result, message);
}
...
}
handleRequestMessage的操作就是用之前我們handler中的委託類MessagingMethodInvokerHelper去反射執行對應的端點方法，然後把執行結果傳送outputChannel。最後我們直接定位到具體的傳送操作：
@Override
protected boolean doSend(Message<?> message, long timeout) {
Assert.notNull(message, "'message' must not be null");
try {
if (this.queue instanceof BlockingQueue) {
BlockingQueue<Message<?>> blockingQueue = (BlockingQueue<Message<?>>) this.queue;
if (timeout > 0) {
return blockingQueue.offer(message, timeout, TimeUnit.MILLISECONDS);
}
if (timeout == 0) {
return blockingQueue.offer(message);
}
blockingQueue.put(message);
return true;
}
else {
try {
return this.queue.offer(message);
}
finally {
this.queueSemaphore.release();
}
}
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
return false;
}
}
看到這，我們就明白了資料的去向，儲存在佇列裡了，生產者產生的資料就已經生成了，所以傳送的操作基本上就告一段落了。
五，接收資訊
資料已經生成，後面就是看如何消費操作了，下面分析下 outputChannel.receive(0).getPayload()操作：
/**
* 從該通道接收第一條可用訊息。 如果通道不包含任何訊息，則此方法將阻塞，直到分配的超時時間過去。 如果指定的超時時間為 0，則該方法將立即返回。 如果小於零，它將無限期阻塞（參見receive() ）。
* 引數：
* timeout - 以毫秒為單位的超時時間
* 返回：
* 如果在分配的時間內沒有可用的訊息或接收執行緒被中斷，則為第一個可用訊息或null 。
*/
@Override // NOSONAR complexity
@Nullable
public Message<?> receive(long timeout) {
...
try {
//接受前攔截器操作
if (interceptorList.getSize() > 0) {
interceptorStack = new ArrayDeque<>();
//一旦呼叫接收並在實際檢索訊息之前呼叫
if (!interceptorList.preReceive(this, interceptorStack)) {
return null;
}
}
//接收操作
Message<?> message = doReceive(timeout);
...
//在檢索到 Message 之後但在將其返回給呼叫者之前立即呼叫。 必要時可以修改訊息
if (interceptorStack != null && message != null) {
message = interceptorList.postReceive(message, this);
}
//在接收完成後呼叫，而不管已引發的任何異常，從而允許適當的資源清理
interceptorList.afterReceiveCompletion(message, this, null, interceptorStack);
return message;
}
catch (RuntimeException ex) {
...
}
}
最後的doReceive操作，其實大家都心知肚明瞭，就是從上面的佇列中直接讀取資料，程式碼比較簡單，就不註釋了：
@Override
@Nullable
protected Message<?> doReceive(long timeout) {
try {
if (timeout > 0) {
if (this.queue instanceof BlockingQueue) {
return ((BlockingQueue<Message<?>>) this.queue).poll(timeout, TimeUnit.MILLISECONDS);
}
else {
return pollNonBlockingQueue(timeout);
}
}
if (timeout == 0) {
return this.queue.poll();
}
if (this.queue instanceof BlockingQueue) {
return ((BlockingQueue<Message<?>>) this.queue).take();
}
else {
Message<?> message = this.queue.poll();
while (message == null) {
this.queueSemaphore.tryAcquire(50, TimeUnit.MILLISECONDS); // NOSONAR ok to ignore result
message = this.queue.poll();
}
return message;
}
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
}
}
六，結語
能堅持看到這的，基本上都是勇士了。這一系列的執行過程其實還是比較繞的，我估計有些人看得也是雲裡霧裡。其實我已經儘量精簡了許多，Spring-Integration其實涉及到的應用分支更多，我這也只是十分基礎的東西，我只能把我自己知道的先記錄下來。如果讓你對Spring-Integration產生了興趣，那本文的目的就達到了。這需要你自己去實地操作研究下，總是有收穫的。O(∩_∩)O謝謝