SOA服务集成场景和实现技术分析

　　今天重点谈下不同集成场景下的服务实现。对于集成场景的分析重点还是从业务交互的实时性需求，并发量，数据量等关键维度进行分析，以确定最适合采用的技术手段。SOA服务集成场景概述
　　首先再看一下两个概念，一个是 一个是ESB服务总线，一个是 服务总线，一个是SOA集成平台 集成平台，要注意ESB服务总线更多的是解决业务服务和消息集成问题，而SOA集成平台则是一 个更加笼统的概念，可以解决技术，数据(包括大数据和文件），业务，消息各类接口和服务的集成问题。
　　对于ESB服务总线，估计大家都清楚更多的是适合承载业务服务，而有业务服务的一个典型特点就是粗粒度，业务并发量可能很大，但是服务本身本次传递的数据量不大，而是调用时间快的话连接资源和内存资源都可以做到快速释放，因此不会对ESB总线本身造成太大的性能压力。
　　业务交互的实时性
　　如果ESB总线更多的是承载业务服务和应用集成的话，那么大部分服务都应该是实时调用和交互，其中又有两个场景，一个是业务单据在生效后实时分发到下游的业务系统（该情况下数据落地）；另外一个场景就是实时的查询其它业务系统的外部服务能力（在这种情况下数据不落地）。
　　对于实时交互的服务往往数据量都不应该太多，完全属于ESB服务总线采用WS服务能够解决的范畴，当然你既可以使用SOAP WS也可以使用Rest WS都可以。对于模糊查询数据不落地场景，则可能数据量大，在这种情况下往往采用分页服务的方式来解决性能问题。
　　对于没有业务实时性要求的场景，往往更多走的是数据集成和同步，类似传统的数据交换，因此这类服务更多的是走数据服务模式，不论是查询服务或者导入服务，都可以作为定时服务进行。这也是传统企业在业务系统间进行接口集成最常用的方式，但是带来最明显的问题就是业务实时性无法满足要求，并可能导致同一时点数据在多个系统间不一致的情况。
　　服务调用并发量和数据量
　　服务调用并发量也是我们衡量服务实现方式的一个关键考虑因素，对于大并发调用的服务虽然也可以采用类似ESB服务中的缓存机制提升性能。但是更多的仍然要考虑在大并发情况下对端目标系统本身的承载能力。对于并发量大的服务调用，如果数据量小往往响应时间容易控制。但是如果数据量很大，则整个服务连接保持时间长，同时JVM内存消耗巨大，这样很容易导致ESB JVM内存溢出的场景错误。
　　因此对于数据量大的服务调用往往并不推荐走ESB，而是走ESB+ETL结合的模式，即实际的数据传输走传统的ETL点对点传输完成，而ESB接入服务的只负责通过服务接口调用实时发起数据传输任务。
　　还有一种服务大并发调用，对于目标系统无法做到及时响应的场景，在这种情况下可以通过ESB的消息中间件进行服务调用流量控制和削峰处理。其实现本身又有两种方式，一种是走类似JMS消息中间件的基本处理，变同步服务为异步消息集成服务，另外一种就是仍然走同步WS服务，但是在出口端对ESB服务进行流量控制。
　　对于大文件传输，类似在Oracle SOA 12c版本中已经单独新增加了MFT文件传输模块来实现大文件传输，以及传输过程的端到端监控能力。当然MFT文件传输本身也是可以和ESB服务进行集成的，通过ESB服务来触发实时的文件传输，这和ESB服务和ETL传输是一个道理。集成场景详细分析
　　集成平台本身是一个技术平台，提供服务，消息，数据，文件各类集成技术和能力即可。而集成平台实施本身是一个从接口服务识别，定义，设计，开发， 测试，部署上线，运维的接口服务全生命周期流程管理，也就是说服务实施方法论仍然是可标准化和流程化的。
　　那服务实施的难点在哪里？ 那服务实施的难点在哪里？
　　集成平台建设和服务实施真正难点在于基于不同的集成场景需求，采用最合适的集成方法和技术来完成集成，以满足性能，可靠性，数据一致性，接口 基于不同的集成场景需求，采用最合适的集成方法和技术来完成集成，以满足性能，可靠性，数据一致性，接口 服务可管理多方面的业务需求。 服务可管理性多方面的业务需求。
　　对于集成场景分析，最简单的可以从实时性，数据量和并发量三个方面进行场景分析。
　　场景1：实时性：高；数据量：大；并发量：大 ：实时性：高；数据量：大；并发量：大
　　一般业务系统交互很难出现这种场景，最典型的容易出现这种场景的是类似CIM和MES生产和制造执行类系统，里面涉及到大量生产数据的实时采集和集成 ，数据量大，并发量大，而且需要实时采集和处理。
　　这种场景下最好的方式仍然是采用高性能消息中间件 高性能消息中间件，变同步为异步后进行削锋和缓冲，并通过消息中间件本身的能力提供彻底解耦和高可靠性要求。
　　场景2：实时性：高；数据量：小；并发量：大 ：实时性：高；数据量：小；并发量：大
　　这是典型的是ESB服务总线处理 服务总线处理的场景，即这类服务大部分为实时调用的业务服务，直接走ESB服务总线接入即可，ESB总线完全能够满足这种小数据量 ，大并发下的业务服务访问和集成需求。
　　对于ESB服务总线集成，即可以采用SOAP WS服务接口 服务接口，也可以采用更加轻量的Restful WebService服务接口 服务接口。即对于契约规范没有强要求，对于技术 服务等能力开放模式接口发布和接入，都可以采用更加轻量的Rest接口进行服务接入。
　　场景3：实时性：高；数据量：大；并发量：小 ：实时性：高；数据量：大；并发量：小
　　举个最简单的例子，业务系统实时跟进某个查询条件查询批量数据实时返回，但是不会出现大并发调用，对于这种集成场景是典型的类似Oracel ODI技术解 技术解 决的场景 决的场景。即WS+ETL技术的结合来实现这种大批量数据的实时访问后返回。同时很好的实现了业务控制流和数据传输流的分离。 如果是对于实时查询类服务，也可以通过WS服务 服务+分页 分页来解决大数据量的查询和传输问题。
　　场景4：实时性：低；数据量：大；并发量：小 ：实时性：低；数据量：大；并发量：小
　　这是最典型的定时类数据集成和同步场景，对于这类场景每次同步的数据量很大，但是并发量不大，一般都是在每天或一个固定时间段定时同步数据。对于这 类场景是典型的传统 传统ETL技术 技术解决的集成问题，即通过ETL或ELT实现数据采集和传输，并可灵活地配置为定时的调度任务或计划。
　　场景5：实时性：低；数据量：小；并发量：大 ：实时性：低；数据量：小；并发量：大
　　同样的道理，对于这类场景，由于对实时性要求不高，但是接口服务调用并发量大，为了减少本身的性能压力，可以采用消息中间件 消息中间件进行集成，通过消息中间件缓冲解决大并发量访问和数据传输问题。
　　场景6：实时性要求高，小文件传输场景 ：实时性要求高，小文件传输场景
　　对于这类场景，最好的方法就是将文件转变为二进制流后直接在消息体里面进行传输。比如通过SOAP WebService（消息头通过MIME传输)，对于1M以下 所有文件都可以采用该种方法将结构化数据和非结构化文件信息通过一个WS服务进行传输和集成。
　　场景7：实时性要求高，大文件传输场景 ：实时性要求高，大文件传输场景
　　对于这类场景，最好的方法就是WS+MFT组合 组合来解决，既通过MFT来实现大文件的高性能和高可靠性传输，同时又通过WebService服务来实现对文件传输 请求的实时发起。
　　场景8：消息的 ：消息的1对多分发集成场景 对多分发集成场景
　　这是典型的消息中间件 消息中间件基本能力，即实现消息集成，消息的发布订阅，因此直接采用类似JMS消息发布订阅来解决即可。但是在实现的时候，对于消息的发 送可以采用WS服务，而对于消息的接收和订阅走JMS消息接口。大数据服务集成
　　在Oracle SOA套件里面可以看到有类似于Oracle ODI的大数据服务集成方案，其本质仍然是WS+ETL的能力组合，在我们自研的ESB中准备集成大数据服务能力，即考虑底层采用最新的DataX来进行集成。
　　其集成的核心思路仍然是将WS和ETL能力进一步结合，同时实现服务调用消息控制流和实际大数据传输数据流的分离。同时通过对服务的调用来实现ETL的实时按需触发和参数化服务调用。
　　其核心思路如下，在设计期：1. 需要设计一个SOAP Web Service服务，该服务的输入有标准的开始时间和截至时间段输入信息，输出有同步完成的数据量，同步Flag状态标准，日志异常信息字段。 2. 将设计完成的Web Service服务在大数据服务总线平台进行注册。 3. 在底层通过DataX来实现TL作业任务，该作业任务使用参数化查询SQL语句对源数据库符合条件的数据进行查询。而具体的参数可以通过在服务调用的时候传入。 4. 具体设计详细的ETL作业任务，包括源和目标数据库的配置，数据映射。 5. 通过配置界面设计服务查询输入和参数化查询SQL之间的数据映射。 6. 通过配置界面设计ETL作业任务结果同服务输出字段之间的数据项映射。
　　在运行期的调用逻辑如下：1. 服务消费方调用 ESB总线发布的Web Service服务，传入时间段条件。 2. ESB总线在接收到服务调用请求后，将服务的输入根据已经配置的数据映射传递给ETL作业的参数化查询中。 3. 在完成数据映射后实时启动ETL任务的执行，ESB服务调用过程处于等待状态。 4. ETL任务执行，将数据从源数据库抽取并同步到目标数据库,整个数据流的集成将在源数据库和目标数据库之间完成，即数据流不通过ESB服务总线以减少ESB总线压力。 5. 在ETL任务完成后获取ETL任务结果信息，并将结果信息返回给ESB服务的服务调用输出中。 6. ESB服务将服务调用输出返回给服务消费方。
　　整个设计过程我们通过前台可配置的界面来配置完成，即主要是配置服务的输入输出，数据源，数据目标，数据源和数据目标之间的映射关系。根据这些配置信息一方面是进行WS服务的封装和发布，另外一方面则是生成DataX需要的Json配置文件。
　　当然整个完成的DataX任务也可以通过CronTab来配置定时作业任务进行定时调度。消息集成
　　当前ESB企业服务总线有部分本身即从消息中间件的基础上发展起来的，在传统企业的EAI应用集成中消息中间件是一个主流的使用产品，在后续SOA架构发展演进后更多出现了数据不落地和接口服务实时调用的需求，因此出现了更多的WS服务集成的场景。
　　当前的消息中间件仍然分为两类，一类是基于AMQP高级消息协议的，一类是基于JMS消息协议的。对于互联网使用较多的RabbitMQ，Kafka等基本都基于AMQP高级消息协议。而对于Weblogic JMS，IBM MQ则是基于JMS消息协议的消息中间件产品。
　　对于Weblogic而言是一个企业级的应用服务器中间件，同时Weblogic JMS也是企业级的消息中间件产品，该产品是一个企业级消息中间件产品，具备了高可靠，高可用，高扩展，高性能基础特性。支持主流的各种消息模型，消息发布订阅，消息持久化，事务处理，集群等核心特性。
　　消息中间件的使用场景，具体包括了如下几个方面：1.消息通知：单据状态变化后的事件通知，数据传输完成后的事件通知 2.异步集成：服务消费方只需要将数据送到OSB即实时返回，通过异步集成实现彻底解耦 3.目标系统削峰：大并发数据导入而目标系统处理性能受限的场景 4.消息发布订阅：基础主数据通过JMS实现1对多的实时数据分发 5.高可靠性场景：确保在数据集成中不出现任何丢失的情况
　　对于采用Weblogic JMS来实现消息集成， 可以采用采用OSB标准的代理服务+Weblogic JMS集成来完成，实现过程描述如下：1. 准备好相应的业务系统提供服务源地址，WSDL资源文件 2. 创建和配置JMS连接池，Topic主题和MQ消息队列 3. 创建代理服务，业务服务（适配到JMS），进行消息流和路由绘制           4. 服务封装打包，并进行测试和验证
　　消息通知场景
　　数据变化通知：举例来说，如果主数据系统在新增或变更了主数据后，需要将变化信息实时分发到业务系统里面，那么常规的做法就是业务系统提供一个主数据导入服务，在MDM系统出现数据变化后实时调用该服务接口进行数据导入。
　　其次还有一个做法就是MDM系统仍然提供主数据查询服务，但是增加一个消息通知场景，即将主数据变化的消息通过JMS消息通知接口实时的通知到各个业务系统，需要这些通知的都可以进行消息订阅。对于这类消息通知，至少需要推送的消息体包括了：变化的业务对象编码，业务对象名称，业务对象ID变更类型（新增或修改或删除） 消息发送时间，消息发送方 获取变更信息的查询服务接口名
　　在业务系统获取到消息通知后，则调用主数据提供的查询服务接口将增量数据信息查询过去。当然也可以根据变更对象ID对变化的数据进行精确同步。
　　异步处理结果回写：在采用JMS进行异步消息分发的时候，由于接收方式异步接收和处理消息，因此必须有一个接收方接收和处理结果的回写消息接口。这个接口本身也可以作为JMS消息接口，但是由于回写的更多仅仅是处理结果状态，处理异常情况反馈等信息，因此完全可以由消息发送方实现一个同步的WS消息回写接口。
　　目标系统削峰
　　在目标系统同步接收和处理消息存在性能瓶颈的时候，为了减少消息发送方的同步等待时间，可以采用消息中间件将原来的同步接口转变为异步接口。大并发的消息发送可以到JMS消息中间件的MQ消息队列中进行排队，再异步缓慢推送到目标系统中（流控机制等）。
　　在异步消息写入的场景，务必要注意减少写入的消息由于完整性校验或者业务规则校验不通过而无法成功导入的场景，如果这类场景很多那么大部分消息都会存在即使发送成功，在目标端也无法处理成功的情况。特别是在异步消息集成的时候，如果这类场景多，将极大地增加业务系统间问题和故障的排查时间。
　　要注意虽然JMS消息中间件能够起到缓存作用，但是MQ本身的JVM内存也是有限的，如果目标端长时间段无法处理完请求，或者是大并发消息发送长时间段持续，那么都可能导致消息中间件本身内存溢出问题。即消息中间件对目标系统的削峰更多的解决的是短周期峰值问题（例如10分钟左右的秒杀活动等）。
　　消息持久化机制
　　消息持久化的使用场景主要是对于关键的消息集成和分发，及时服务器宕机或订阅方重连也保证消息不丢失。Weblogic JMS消息中间件本身提供消息持久化机制，可以将消息持久化到数据库，也可以将消息持久化到本地的文件系统中。
　　具体实现内容描述如下：1.采用Weblogic JMS Server的消息持久化配置和定义机制 2.创建JMS Store，可以持久化到文件，也可以是数据库 3.将JMS Store关联到JMS Server上的订阅Topic上 4.持久化机制和参数详细配置(重写间隔，重写模式等）