应用集成实战系列-服务总线
注：原文来自从csdn Steel Ren 的专栏，汇总在此方便查阅。
应用集成实战系列：服务总线中的发布订阅业务模式
在应用集成项目中，如果有数据同步的需求，尤其是主数据同步的需求，经常会用到发布订阅模式进行数据的发布。
• 发布订阅模式多用于消息分发业务，比如源系统数据更新，需要同步到多个业务系统(员工信息、产品信息更新)
• 发布订阅模式多采用消息发送方式(JMS)
– 源系统将数据发送到JMS主题①②
– 所有订阅该主题的服务都可以接收到数据，进行数据的接收，并调用目标系统服务写入数据③④
– 数据写入成功，目标系统向源系统发送通知①②③④(该步骤可选)
– 数据写入失败，记录冲正日志⑤
– 补偿流程定时查看冲正日志，重新调用失败的目标系统服务进行自动补偿，重试特定次数后仍不成功，记录手工补偿日志①②
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/54728496
应用集成实战系列：如何进行文件交换
在进行应用集成项目的实施过程中，因为有一些遗留系统无法提供服务接口，或者交换数据量比较大(10MB以上)的原因，通常都会遇到进行文件交换的需求。在之前的文章中，我们提到过，我们不建议通过服务总线传递比较大的报文，因此对于比较大的文件的传输，我们需要借助其他方式实现。
• 对于系统间传输数据更大的场景(5MB以上)，须考虑使用文件交换，传输数据存入文件当中
– 异步业务交互由三部分组成
• 文件属性消息发送
– ①源系统将查询请求信息发送给服务总线；②服务总线将查询请求转发给目标系统；③目标系统接收成功返回响应； ④服务总线将响应转发给源系统
• 文件实体传输
– ①②通过MFT(受控文件传输或其他FTP工具)传输数据文件
• 文件处理结果返回
– ①目标系统将文件处理完毕后，向服务总线发送处理结果；②服务总线将结果转发给源系统；③源系统接收成功返回响应；④服务总线将响应转发给目标系统
– 异步业务文件交换过程由ESB控制文件传输与属性消息传送的一致性
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/54728470
应用集成实战系列：服务总线中的服务补偿机制
在应用集成项目中，经常会遇到多个集成应用之间的交易数据一致性的问题，虽然很多成熟的应用集成产品都会提供分布式事务和重试的功能，但是这些功能往往在实际的应用中作用不是很大。主要因为：1.大多数集成接口使用的是基于HTTP的传输协议(Web Service、REST等)，而分布式事务通常只能支持诸如JDBC，EJB，JMS之类的协议；2、大多数集成服务之间的调用异常或是因为网络原因、或是因为数据原因都不可能很快自动恢复，而集成产品所提供的重试一般都是在短时间内的重试，比如30秒重试一次，重试3次等，在很多情况下无法满足需要。
为了保证集成项目实际应用中的交易数据一致性，我们需要在项目实施的过程中构建自己的服务补偿机制。根据需求的不同，服务补偿集成有如下两种：
实时冲正
对业务一致性要求高的集成业务，如果其采用的集成接口不支持分布式事务(基于HTTP的接口)，需要采用实时冲正进行服务的补偿
- 需要进行冲正补偿的系统服务，必须提供两个服务接口
- 正常服务接口：用来进行正常的业务服务调用
- 冲正服务接口：当集成过程中出现错误，调用冲正服务接口进行回滚操作
- 冲正服务在服务的异常处理分支进行调用，目标系统需要实现业务去重的操
批量补偿
对业务一致性要求不是很高(主要是时效性)的业务场景，可采用补偿流程定时重发的方式进行服务补偿
- 集成的过程中出现异常，将集成数据存储到冲正日志
- 补偿流程定时检查冲正日志，发现需要冲正的数据，自动重新调用目标服务进行服务重做进行服务补偿
- 如果多次调用补偿失败，可转为手工补偿
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/54691967
应用集成实战系列：服务总线中的异步业务交互模式
在使用服务总线进行集成时，异步业务交互模式也是比较常用的业务交互模式，尤其是在系统之间交互的信息量比较大的时候，为了避免数据的处理对系统交互产生阻塞，通常会采用异步业务交互模式。异步业务交互模式的技术实现往往也不一定是必须采用异步交互接口(比如JMS消息通讯之类)，很多时候，可以采用同步交互接口的组合实现异步业务交互模式。
异步业务交互模式通常为比较大的报文(大于1MB，小于10MB)的数据发送和数据获取两种业务场景。
异步数据发送业务
异步数据发送业务交互主要用于源系统向目标系统传输的信息较多(大于1MB，小于10MB)，并且处理时间比较长，并不需要实时获取处理结果的业务场景，比如BOM数据的传输和处理
异步业务交互由两部分组成
-
- 消息发送(异步过程)
- ①②源系统将需要处理的信息发送给服务总线，从服务总线获得传输结果(服务总线接收成功/失败)
- ③④服务总线将信息转发给目标系统，从目标系统获得传输结果(目标系统接收成功/失败)
- 结果返回(同步过程)
- ①目标系统将信息处理完毕后，向服务总线发送处理结果；②服务总线将结果转发给源系统；③源系统接收成功返回响应；④服务总线将响应转发给目标系统
- 消息发送(异步过程)
- 异步数据发送业务交互的消息发送过程中，对目标系统发送数据出现异常，将有服务总线进行数据的重发处理
异步数据查询业务
异步数据查询业务交互主要用于目标系统向源系统返回的信息较多(大于1MB，小于10MB)，并且处理时间比较长，并不需要实时获取处理结果的业务场景，比如BOM数据的查询
异步业务交互查询由两部分组成
- 消息发送(同步过程)
- ①源系统将查询请求信息发送给服务总线；②服务总线将查询请求转发给目标系统；③目标系统接收成功返回响应； ④服务总线将响应转发给源系统
- 结果返回(异步过程)
- ①②目标系统将查询结果信息发送给服务总线，从服务总线获得传输结果(服务总线接收成功/失败)
- ③④服务总线将信息转发给源系统，从源系统获得传输结果(目标系统接收成功/失败)
- 异步数据查询业务交互的消息发送过程中，对源系统发送数据出现异常，将有服务总线进行数据的重发处理
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/54429660
应用集成实战系列：服务总线中的同步业务交互模式
在使用服务总线进行集成时，同步业务交互模式是最常见，也是相对来说比较简单的交互模式，通常使用一个同步交互的服务接口即可封装完成。同步业务交互模式适用于系统之间一对一的交互，并且相互之间传递的报文比较小(建议报文大小在1MB以内)的实时业务交互场景(比如CRM接收到订单，要立即交付给ERP进行处理)，接口模式通常为Web Service、REST。
同步业务交互模式需要包含如下步骤：
① 源业务系统将请求信息发送给服务总线，并等待总线应答
② 服务总线将请求消息处理后，转发给目标业务系统，并等待目标系统应答
③ 目标业务系统接收请求，经过处理后将响应信息发送给服务总线
④ 服务总线将目标系统的响应消息处理后，返回给源系统。
同步交互业务的异常处理：
如果在整个交互过程中出现异常，服务总线也需要将异常信息作为响应消息，返回给源系统。
源系统在接收到总线返回的异常信息后，决定是否做重发处理。(源系统负责重发)
在某些异常情况下(比如服务总线调用目标系统超时)，目标系统可能已经接收到了请求，并进行了处理，因此如果源系统对请求做了重发操作，目标系统需要做去重处理。(目标系统负责去重)
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/53560632
应用集成实战系列：服务总线中同步交互服务接口的定义规范
在基于SOA的应用集成项目中，用户会定义很多服务接口用于系统之间的交互。作为SOA应用集成中的基本元素，服务总线中的服务接口的定义规范对应用集成项目的实施具有重要的指导意义。
根据我的经验，在应用集成项目中定义的服务接口大多数为同步交互接口，比如Web Service接口，基本会占接口总数的八、九成。即便是需要进行异步交互的业务，经常也是由多个同步交互服务接口组合实现的。在本文中，我将介绍服务总线中的同步交互服务接口的定义规范。
首先，总线中的一个同步交互服务的须根据如下模式进行设计：
在同步交互服务中，必须要包括如下三个基本的消息处理路径：
① 请求消息处理：接收调用端发送的请求消息数据并进行处理
② 响应消息处理：将服务处理结果生成响应消息并返回给调用端
③ 异常消息处理：对请求路径和响应路径中产生异常进行捕捉，生成异常消息，并作为响应消息返回给调用端
其次，在整个的服务消息处理的过程中，还需要包含如下元素：
服务日志：用于记录运行情况，包括调用时间、消息关键内容、成功/失败、异常信息等。日志记录的操作放在响应消息处理路径和异常消息处理路径当中，采用异步方式记录，以免日志记录操作影响服务的运行。
超时时间：在调用目标服务时，必须要设置调用超时时间，以免目标服务处理时间过长，导致服务总线中线程挂起的情况。超时时间建议不超过120秒。
报文校验(可选)：针对需要对报文进行限制(报文大小、格式等)的服务，需要在请求消息处理路径的起始处进行报文校验，校验失败触发异常消息处理路径。
调试日志(可选)：如果需要在处理过程中记录调试日志，必须要设置日志级别，以免在服务正常运行时占用过多的日志空间，消耗服务性能。
最后，同步交互服务接口的报文定义规范可参考如下格式：
- 请求消息报文格式：
<Request>
<ReqMsgHeader> --请求消息头，用于传送服务请求的关键信息
<SID/> --序列号系统生成，调用的唯一标识序号
<Invoker/> --请求系统名称，标识请求系统
<Key_1/> --业务关键字保留字段，用于记录关键日志信息和集成逻辑中的判断条件，可定义多个保留字段
<Key_2/>
<Key_3/>
<Key_4/>
<Key_5/>
</ReqMsgHeader>
<ReqMsgBody> --请求消息体，请求消息的内容，可以为XML或者格式化的字符串，一般情况下，不需要在服务总线中进行解析。用这种消息体字符串方式定义，目的是减少业务报文的变化对服务的影响，不需要对服务接口进行频繁的修改。
</ReqMsgBody>
</Request>
- 响应消息报文格式
<Response>
<RespMsgHeader> --响应消息头
<Result/> --响应结果 1成功 0失败
<RespMsg/> --响应结果描述，简单总结返回结果
<ExceptionInfo/> --异常信息，详细的异常信息
<Key_1/> --业务关键字保留字段，用于记录关键日志信息和集成逻辑中的判断条件，可定义多个保留字段
<Key_2/>
<Key_3/>
<Key_4/>
<Key_5/>
</RespMsgHeader>
<RespMsgBody> --响应消息体，如果服务返回复杂的结果，比如查询服务，将结果数据以XML或者格式化字符串的形式放在该字段中。通常，该字段不需要在服务总线中进行解析。用这种消息体字符串方式定义，目的是减少业务报文的变化对服务的影响，不需要对服务接口进行频繁的修改。
</RespMsgBody>
</Response>
以上是我根据之前的项目经验总结的服务总线中同步交互接口的定义规范，供参考，实际项目中，可根据具体情况进行调整。
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/53033855
应用集成实战系列：什么时候需慎重使用服务总线
目前的应用集成项目基本上都会基于服务总线产品(或商用或开源)进行实施的，有些用户或许是之前深受点对点硬编码集成之害，在通过服务总线/SOA实施集成项目时，会要求所有的系统之间交互全部通过服务总线实现。当项目真正上线运行时，却会发现各种各样的问题，严重的甚至出现集成服务器宕机，严重影响业务的运行。
出现这种问题的原因，就是因为客户在做集成时，没有搞清服务总线的优劣势，虽然服务总线是专门用于应用集成的，但是还是有一些集成的场景“不应该”使用服务总来实现。如下就是一些需要慎重使用服务总线的集成场景。
l 大报文传输
大数据量的发送或查询，比如BOM数据的传输，查询过去一年的订单等。在这样的数据传输，如果使用服务总线，需要把大量数据打包到一个服务(比如Web Service，REST等)报文中。根据多数服务总线产品的特性，这样的传输服务可能会长时间的在服务器中占用内存和线程资源，一旦出现大并发的情况，轻则会拖慢服务总线的性能，严重的可能会引起宕机。一般情况下，用HTTP报文包超过1MB，用JMS报文包超过5MB，就需要慎重考虑使用服务总线，可以考虑采用ETL或直连方式进行传输。
l 大文件传输
与大报文传输类似，不要将文件打包到服务报文中(比如Web Service的attachment中)进行传输，原因与大报文相同。建议采用FTP或者其他方式在服务总线之外实现文件的传输。目前市面上，很多服务总线产品是能够支持FTP协议的，可以通过服务总线操作FTP服务器进行文件传输。
l 系统内部的集成
曾经在项目中见过这样的情况，客户的某业务系统提供有多个服务接口(Web Service)，在实现集成时，需服务总线将该系统的这些接口进行组合调用，生成一个新的接口，供其他业务系统进行调用。在这个场景中，服务总线实现的完全是业务系统内部服务的编排与调度。对于这种情况，我更建议让业务系统内部进行改造，增加一个这样接口，然后再由服务总线进行封装，供其他系统调用。因为，由服务总线进行系统内部接口调度性能远不如系统内部的调用，如果接口交互的数据量比较大，并且逻辑比较复杂的话，那由服务总线进行组合调用后的接口性能会更加糟糕，同样可能会拖累服务总线的运行。
l 复杂的业务逻辑
通过服务总线关联多个系统的实现应用集成，在服务总线中承载的是集成逻辑，比如转换、路由等，而不要去实现复杂的业务逻辑。曾经见过客户的一个应用集成场景在服务总线中使用数十个集成组件来实现，编写的很复杂的业务逻辑，而这个服务集成每次至少需要几十秒中才能够完成。这种服务在业务量增大时，也会大大拖累服务总线的性能，带来潜在的危机。
l 高频次数据传输
虽然很多服务总线产品都有不错的性能，但是对于一些对性能要求很高，但是又没有什么格式转换和监控需求的集成(比如一些设备数据的实时采集场景)，我们也可以考虑不适用服务总线，直接采用直连方式，比如使用JMS或者Tuxedo之类高性能的传输方式进行对接。
以上是几个需要慎重使用服务总线场景的简单总结，供大家参考。总之，我们在应用服务总线时，需要让服务在运行时尽量短时间的占用服务总线内存和线程的资源，避免服务总线的阻塞，最大限度的保证服务总线的顺畅运行。
————————————————
版权声明：本文为CSDN博主「Steel Ren」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/steelren/article/details/52692052
