转载

接口转服务

前面很多文章都谈到过，在进行服务架构规划和服务识别的时候，不是简单的将历史遗留接口映射为服务，而是需要从跨系统流程分析，数据CRUD分析和对历史遗留接口对应的业务场景分析多方面来考虑如何来规划和识别服务，以保证服务本身的粗粒度和可复用能力。下面举一些场景来说明接口转服务的一些分析过程。

异步多接口-》归并为同步单服务

注意，如果原来在业务系统间集成的时候采用类似MQ这种消息中间件，那么任何一个消息或数据的集成都会涉及到消息推送和消息结果反馈两个消息接口。对于这种场景需要单独拿出来分析，即如果对于消息接收方，当接收到消息后可以实时的处理（对于消息的内部处理业务规则和逻辑不复杂），那么对于这类消息发送和回写接口可以考虑转化为同步的一个web service服务来实现。

同步接口-》异步服务

对于原来的同步接口，当需要对接口涉及的源系统和目标系统彻底解耦的时候，即我们不希望由于目标系统本身的故障而导致消息分发失败。在这种情况下需要考虑将同步接口转化为基于JMS消息的两个异步服务。对于这种服务可以称为异步准实时，一方面是可以充分利用消息中间件的高可靠性和消息重试能力，一方面可以利用消息中间件的排队机制减少在大并发请求场景下对目标系统的性能压力。

数据接口-》拆分为多个业务服务

传统进行数据集成的时候，我们并不会太多的考虑业务场景，而是更多的考虑传递的数据对象本身。因此往往存在不同的业务场景由于数据对象本身差异不大而采用相同的数据接口。如对于采购订单和采购冲红单等，在传统数据接口设计中可能采用的是一个数据接口。但是在转化为服务的时候，即使两种场景传递的数据对象差异不大也建议不要合并，而分拆为不同的业务服务。即采购订单分发和采购冲红单分发两个业务，即让服务本身有明确的业务场景和业务含义，而不是单纯的数据集成和数据服务。

还有一种场景可以看到，往往一个数据接口覆盖了多种业务场景，对于每种业务场景虽然有数据对象差异，但是差异全部传递在接口的xml或json字符串对象里面，导致一个接口本身的复杂度和耦合性相当大。对于这种场景也需要根据不同的业务实现拆分为不同的业务服务或数据服务。

注意对于传统的数据接口和数据集成，其本质已经是同一份基础主数据或共享数据已经会通过数据接口或传统的数据交换平台在多个业务系统中落地。由于数据多点落地带来的最大影响就是数据本身在某个时点在多个系统中的数据不一致性和数据实时性。对于这种场景可以考虑对于一些数据有传统的数据集成和传递，转换为直接由数据拥有方提供数据查询服务能力，消费方在业务场景中根据实际需要实时查询而不具体落地和存储数据。这虽然增加了两个系统的耦合性，并带来业务系统本身的逻辑改造，但是带来了真正SOA服务能力开放思想。

不同数据接口-》合并为相同的服务

对于同一个数据对象，往往可以看到在不同的业务系统之间传递的时候，往往由于历史遗留原因可能采用了不同的数据或消息集成方式，传递不同格式和内容的数据对象，如订单对象在多个业务系统间的传递。同时也可能看到当我们在进行流程交互分析过程中，一个源系统在和多个目标系统对接的时候，对于同一个业务能力提供往往采用了不同的接口和数据交换标准。对于这些场景我们需要考虑合并为同一个数据或业务服务，对于这种协同采用同样的服务契约和接口标准，以提升服务本身的可重用性。

多接口-》消息发布订阅服务机制

对于原有的同一数据或业务对象的分发类消息或数据接口，原有业务场景往往是需要做多个接口点对点集成和连接。对于这种场景需要考虑这类数据分发转化为消息发布订阅模式，即充分利用ESB本身的消息和事件管理能力，对于源系统只需要将消息分发给ESB，而由ESB再根据消息订阅情况进行消息的服务分发。

以上谈到的就是在接口转化为服务过程中涉及到的去重，拆分，转换，合并等常见的接口转服务方法。虽然服务本身也包括了数据服务和业务服务，但是一定要注意到了服务层会更加关注业务服务，每一个业务服务都应该有明确的业务价值和能力实现，而不是底层简单的数据集成和传递。

正文到此结束