微服务网关和OpenAPI平台

对微服务网关和OpenAPI能力开放平台两者做一个简单的比较

首先我们看下微服务网关，微服务网关本身是应用在微服务架构中，实现对微服务接口的统一注册，接入，监控和管理的一个组件。可以将微服务网关理解为轻量的ESB总线，其重点是实现服务的注册接入，服务的监控和服务管理，其中服务管理本身重点又在安全，流控，负载均衡，路由等几个关键内容上面。

通过微服务网关可以多微服务架构中，多个微服务模块间的API服务接入实现统一的管理，统一的监控，同时实现基本的SOA服务治理能力。类似淘宝的Dubbo我们也可以认为是一个微服务网关组件。注意微服务网关在实现中，更多的模式是控制流和消息流分离，本质仍然是去中心化的，以提升整个架构的容错性，同时微服务网关由于不承载服务调用的数据流，本身也不存在性能瓶颈。

微服务网关中的服务接口，基本都是以Rest接口方式实现并注册。

其次再看下OpenAPI能力开放平台，对于OpenAPI开放的服务能力也是Http Rest接口服务为主。但是对于OpenAPI能力开放平台更加强调了内部各个业务系统或微服务模块已有的能力朝外部的一种能力开放，而并不是指内部业务系统之间的接口集成。类似可以看到类似京东，淘宝构建的各种能力开放平台，都是其内部电商多个子系统或能力的朝外暴露。

对于OpenAPI平台更加强调了消费端系统的自服务能力，因此可以看到能力开放平台都会有面向开发者的自服务门户，里面包括了服务的详细查看，服务的订阅，服务的开发指南和详细说明，服务的注册接入流程等各种自服务流程说明。即通过OpenAPI平台外部开发商可以很方便的自助申请和开通各种服务接口并进行消费使用。

能力开放平台更强调了内部已有的API接口服务能力，如何能够更加方便的发布出去，供外部使用，这本质也是类似微服务网关中的服务注册和接入。但是这里更加强调了自服务性质，通过接入流程就可以自服务完成。

对于基础的服务流量控制，服务安全校验，路由等能力，OpenAPI能力开放平台同样需要具备。

两者之间的一些关键对比分析

微服务网关更多是多个微服务模块开发团队自己使用，方便查看和监控微服务API接口的运行情况。在DevOps下往往还需要提供微服务API的自动发现和注册功能。OpenAPI能力开放平台往往仅仅是对外接口服务暴露，提供自服务能力进行服务接入，更多的是给外部系统或合作伙伴使用。

微服务网关暴露的接口本身是微服务模块间相互沟通和讨论清楚的接口，实现方式本身也可以查询，导入或读写多种模式。而对于OpenAPI平台，则更多是思考内部有哪些能力，这些能力如何开放出去，因此接口都是以自身提供服务进行思考，将自己的能力暴露出去，OpenAPI平台并不会去考虑你外部消费系统自身是如何运转的。

微服务网关产品本身可以做为构建OpenAPI平台的底层技术，但是仍然需要再次基础上增加类似开发者门户，服务接入流程，服务消费和订购流程等各种自服务能力和功能。

对于微服务网关一般应用在微服务架构体系中，而OpenAPI平台一般会用在对外系统或合作伙伴上。那举个场景来说企业信息通过微服务架构实现，一共包括了20个微服务模块，涉及到200个微服务API接口。那么这200个接口本身会注册在微服务网关上，但是这200个接口可能只有50个需要对外进行能力开放，那么这50个接口就需要进一步封装接入到OpenAPI平台对外暴露。

如我们可以在DMZ区部署OpenAPI平台，提供50个API接口服务，再将50个服务的访问请求路由回内部。当然企业如果已经实施了ESB服务总