前面在谈微架构的时候，我博客上转过chris richardson 微服务系列中对微服务网关的描述：
通常来说，使用 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。
文章转载至 http://blog.sina.com.cn/s/blog_493a84550102x6zu.html
