api接口开放平台推荐 api网关设计原则( 三 ) _微服

ESB总线和API网关两级集成在前面我就谈到，传统企业在进行微服务架构转型过程中，是一个逐步迁移和改造的过程，因此往往存在新微服务架构采用API网关，遗留系统集成仍然是ESB服务总线的业务集成场景。
那么在这种集成场景下，就存在ESB服务总线和API网关两级集成和协同的场景。
我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线，而对于新建设的一个微服务应用采用API网关，那么就存在两者协同和集成的过程，整体集成架构如下：
可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线，形成两级服务集成的方式。
在这种两级服务集成模式下好处包括
微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ESB内部微服务间的Rest API交互仍然可以走注册中心，而且对外透明可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配虽然两级集成模式下增加了一定的性能损耗，也拉长了整个服务调用链路。但是在新旧架构并存的过程中，这种两级集成仍然是我们推荐采用的方式。既满足了微服务应用内部的微服务治理要求，又实现了和外围系统间的集成。
如果站在微服务应用角度来看，那么我们完全可以将外部遗留系统都作为对微服务通过API网关暴露的接口的消费方，不同点仅仅在于这些对API网关发起的消费都统一通过ESB服务总线进行了路由和中转。
通过ESB总线代理的作用一方面是实现对所有接口的管控治理，另外一个重点就是解决老接口协议调用方式和新接口之间的适配和转换问题，如下图：
我们可以举例来进一步说明。

在传统遗留集成架构中，全部采用SOAP WS进行服务集成，接口全部注册接入到ESB总线。对于遗留系统A我们进行微服务改造和微服务化，那么遗留系统A原来暴露的SOAP WS接口，在进行微服务改造后全部采用标注的Http Rest API接口。

但是原来的遗留系统B，或C并不希望由于A的微服务化改造而导致原来对SOAP WS接口服务的消费端进行全部改造并增加工作量。那么这个时候就存在通过ESB总线进行适配问题。
场景一：遗留系统访问微服务提供的接口
微服务模块提供Http Rest接口并注册接入到API网关。ESB服务总线适配API网关的Http Rest接口并将其暴露为SOAP WS接口。对于遗留系统仍然消费和原来已有的SOAP接口，因此无须改造场景二：微服务需要访问ESB总线提供的SOAP接口
注意在这种场景下，API网关往往并不具备对SOAP服务进行接入和适配的能力，因此在这种场景下，具体的协议转换和适配仍然需要ESB总线完成。

api接口开放平台推荐 api网关设计原则( 三 )

猜你喜欢