通常来说，使用 API 网关是更好的解决方式。API 网关是一个服务器，也可以说是进入系统的唯一节点。这与面向对象设计模式中的 Facade 模式很像。API 网关封装内部系统的架构，并且提供 API 给各个客户端。它还可能还具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能。下图展示了一个适应当前架构的 API 网关。
API 网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过 API 网关，然后由它将请求路由到合适的微服务。API 网关经常会通过调用多个微服务并合并结果来处理一个请求。它可以在 web 协议（如 HTTP 与 WebSocket）与内部使用的非 web 友好协议之间转换。
API 网关还能为每个客户端提供一个定制的 API。通常，它会向移动客户端暴露一个粗粒度的 API。以产品详情的场景为例，API 网关可以提供一个端点（/productdetails?productid=xxx），使移动客户端可以通过一个请求获取所有的产品详情。API 网关通过调用各个服务（产品信息、推荐、评论等等）并合并结果来处理请求。
对于API 网关，虽然网上有类似Netfix Zuul和Kong等的开源实现，但是本篇重点还是想再思考下网关应该具备的一些关键功能点。主要还是是服务接入，服务运维，服务运营，服务安全，服务管控治理等几个方面来思考下一个完整的API网关应该具备或后续扩展的能力。
服务注册和服务接入能力
1.直接将Java API接口发布为服务，即内部可以用Java API或RPC，跨模块访问走Rest接口服务注册到网关
2.将已有的Rest API接口通过代理方式注册和接入
3.将已有的Soap WS服务接入通过协议转换和数据格式转换后发布为Rest API服务接口
4.将内部基于JMS或AMQP的消息适配后发布为Rest API服务接口
5.提供服务自动化注册和接入的能力
网关接入和发布核心功能
1.协议转换：重点是支持SOAP，JMS，Rest间的协议转换
2.数据转换：重点是支持XML和Json之间的报文格式转换能力（可选）
3.负载均衡：注意是网关本身的负载均衡，可以部署多个API网关形成Cluster集群
4.路由：基础能力，基本的服务路由支持
服务安全
1.基于Token的客户端访问控制和安全策略
2.传输数据和报文加密，到服务端解密，需要在客户端有独立的SDK代理包
3.基于Https的传输加密，客户端和服务端数字证书支持
4.基于OAuth2.0的服务安全认证(授权码，客户端，密码模式等）
服务管控和治理
1.服务消息和日志监控能力，能够查看详细的服务消息日志，在取中心化的网关中需要单独处理
2.服务流量控制，限流和熔断能力，可以设置不同的流量控制策略
3.服务链的监控和跟踪，可以跟踪多个服务间的调用链，需要进一步规约Trace_id的使用
面向开发者的自服务能力
1.提供开发者门户和面向开发者的各种自服务能力
2.提供API服务目录，服务详细说明，服务调用示例，在线测试等基础功能
3.提供服务接入，服务订购关键自服务流程
4.提供详细的服务开发案例代码，开发框架，本地SDK包，接入指南帮助文档等
当前开源的API网关产品-Zuul和Kong产品
Spring Zuul: Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它的主要功能有：认证、压力测试、金丝雀测试、动态路由、负载削减、安全、静态响应处理和主动/主动交换管理。spring zuul 是spring Cloud的组件，可以和spring cloud的各个组件结合使用。
SpringCloud的整体组建包括：Zuul、Ribbon、EureKa、Fein、Hystrix等。其中Zuul就是一个类似APIGateway的组建，Ribbon是类似于Nginx的代理服务器，Eureka用于注册和发现服务，Hystrix可以作为整个架构的断路服务，用于服务降级。Fein可以作为一个Rest服务的提供者，可以供内部服务之间相互调用
Kong：Kong 是一个现成 的Api Gateway 的解决方案，它在 nginx 上进行了开发。Api gateway 的实现方式有很多种，比如说 JVM 上可以用基于NIO 的框架比如Netty，Vertx，Spring Reactor，JOSS Undertow。现在一个比较流程的没有基于 JVM 的就是 NodeJs。其他的还有 Nginx Plus。