本文主要是介绍应用集成实战系列：什么时候需慎重使用服务总线，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目前的应用集成项目基本上都会基于服务总线产品(或商用或开源)进行实施的，有些用户或许是之前深受点对点硬编码集成之害，在通过服务总线/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之类高性能的传输方式进行对接。
以上是几个需要慎重使用服务总线场景的简单总结，供大家参考。总之，我们在应用服务总线时，需要让服务在运行时尽量短时间的占用服务总线内存和线程的资源，避免服务总线的阻塞，最大限度的保证服务总线的顺畅运行。
欢迎关注我的微信公众号：
这篇关于应用集成实战系列：什么时候需慎重使用服务总线的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
