微服务gateway介绍

用 Spring Cloud 微服务实战中，大家都知道用 Zuul 作为智能网关。API 网关（API Gateway）主要负责服务请求路由、组合及协议转换。下面是大家的总结：

一、最佳回答

网关的技术选型

1. SpringCloud-Zuul :

   社区活跃,基于 SrpingCloud 完整生态, 是构建微服务体系前置网关服务的最佳选型.

2. Kong : 基于OpenResty的 API 网关服务和网关服务管理层.

3. 自建网关服务: 如 谈谈基于 OpenResty 的接口网关设计

网关的设计要素

系统级别

• 高可用性
• 均衡负载: 容错,防止雪崩.
• 并发控制 : 错峰流控
• 动态路由制定和修改

应用级别

• 监控统计
• 版本控制
• 认证 鉴权
• 数据安全: 防篡改,参数脱敏…
• 协议转换: 如 HTTP => RPC协议.

其他(个人 YY)

• 基于机器学习, 预测流量高峰.

二、此时此刻的总结

1. 网关（API Gateway）技术选型

   • zuul
   • kong
   • nginx+lua

2. 网关（API Gateway）的设计要素

   • 限流：实现微服务访问流量计算，基于流量计算分析进行限流，可以定义多种限流规则。
   • 缓存：数据缓存。
   • 日志：日志记录。
   • 监控：记录请求响应数据，api耗时分析，性能监控。
   • 鉴权：权限身份认证。
   • 灰度：线上灰度部署，可以减小风险。
   • 路由：路由是API网关很核心的模块功能，此模块实现根据请求，锁定目标微服务并将请求进行转发。

3. 简单介绍下你的网关实施方案

   • 开发语言：java + groovy，groovy的好处是网关服务不需要重启就可以动态的添加filter来实现一些功能；
   • 微服务基础框架：springboot；
   • 网关基础组件：netflix zuul；
   • 服务注册中心：consul；
   • 权限校验：jwt；
   • API监控：prometheus + grafana；
   • API统一日志收集：logback + ELK；
   • 压力测试：Jmeter；

比如限流 你需要缓存一些限流的策略，主要是缓存网关功能用到的一些数据，不涉及业务数据。 路由主要是做转发

三、IronCity 的总结

目前，我们业务代码是多语言的环境，网关则是用go写的，目前主要是做到了对于HTTP和Thrift的业务服务的转发（HTTP利用了fasthttp，Thrift用的网关启动客户端调用业务服务端的形式）过滤器是环绕的，系统统一的过滤和针对API级别的过滤。虽然用了go比较轻巧，但是目前功能还很值得完善

四、XuChuangfeng 的总结

设计要素：#1，高可用非常重要；#2，网关需要支持动态修改路由规则；#3，与服务注册中心整合，通过注册中心实现路由转发；#4，过滤器链适配不同的路由。

五、fudali113 的总结

选型

• 所使用的网关架构必须灵活，因为我们可能需要很多与我们业务相关的定制话的东西
• 有平台背书，获取有足够的证据证明他是一个能抗的住我们需求的并发的性能
• 根据需求选择最好的方案

  设计要素

• 结构必须灵活，方便扩展
• 基础的功能应该由框架提供或者抽象，比如动态路由，权限校验，限流

  我的

  我们使用zuul作为网关并对他进行了一定定制化的开发，因为我们使用springcloud技术栈，同时zuul基于filter来处理一切的结构也是非常灵活的，并且由netflix背书。我们在网关利用filter加入权限校验，统一访问日志记录，访问异常请求记录，聚合请求处理器等相关功能

负载均衡可以通过在之前加入一个nginx或者dns解析来做，高可用可以通过keepalived加虚拟ip与nginx结合或者直接与zuul结合来做

六、Ascend 总结

1. 能处理一些公共的逻辑，比如获取token
2. 能支持动态的修改路由规则
3. 对各服务结果和异常进行统一处理后返给调用方
   目前实施了几套方案，自己封装的gateway层，准备用zuul进行替代

七、曼陀罗 总结

网关的技术选型

1. SpringCloud-Zuul :社区活跃,基于 SrpingCloud 完整生态, 是构建微服务体系前置网关服务的最佳选型.
2. Kong : 基于OpenResty的 API 网关服务和网关服务管理层.
3. Nginx+Lua：成熟度也算可以
4. 自建网关：成本较高

网关（API Gateway）的设计要素（高可用，安全）

• 性能：API高可用，负载均衡，容错机制。
• 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
• 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
• 缓存：数据缓存。
• 监控：记录请求响应数据，api耗时分析，性能监控。
• 限流：流量控制，错峰流控，目前有漏桶算法、令牌桶算法也可以定制限流规则。
• 灰度：线上灰度部署，可以减小风险。
• 路由：动态路由规则。
• 静态：代理

简单介绍下你的网关实施方案

• 微服务基础框架：springboot；
• 网关基础组件：zuul；
• 服务注册中心：consul；
• API监控：prometheus + grafana or 自建；
• API统一日志收集：时序db + ELK；
• 压力测试：Jmeter，AB，阿里压测；

转载自：http://www.spring4all.com/article/336

用 Spring Cloud 微服务实战中，大家都知道用 Zuul 作为智能网关。API 网关（API Gateway）主要负责服务请求路由、组合及协议转换。下面是大家的总结：

一、最佳回答

网关的技术选型

1. SpringCloud-Zuul :

   社区活跃,基于 SrpingCloud 完整生态, 是构建微服务体系前置网关服务的最佳选型.

2. Kong : 基于OpenResty的 API 网关服务和网关服务管理层.

3. 自建网关服务: 如 谈谈基于 OpenResty 的接口网关设计

网关的设计要素

系统级别

• 高可用性
• 均衡负载: 容错,防止雪崩.
• 并发控制 : 错峰流控
• 动态路由制定和修改

应用级别

• 监控统计
• 版本控制
• 认证 鉴权
• 数据安全: 防篡改,参数脱敏…
• 协议转换: 如 HTTP => RPC协议.

其他(个人 YY)

• 基于机器学习, 预测流量高峰.

二、此时此刻的总结

1. 网关（API Gateway）技术选型

   • zuul
   • kong
   • nginx+lua

2. 网关（API Gateway）的设计要素

   • 限流：实现微服务访问流量计算，基于流量计算分析进行限流，可以定义多种限流规则。
   • 缓存：数据缓存。
   • 日志：日志记录。
   • 监控：记录请求响应数据，api耗时分析，性能监控。
   • 鉴权：权限身份认证。
   • 灰度：线上灰度部署，可以减小风险。
   • 路由：路由是API网关很核心的模块功能，此模块实现根据请求，锁定目标微服务并将请求进行转发。

3. 简单介绍下你的网关实施方案

   • 开发语言：java + groovy，groovy的好处是网关服务不需要重启就可以动态的添加filter来实现一些功能；
   • 微服务基础框架：springboot；
   • 网关基础组件：netflix zuul；
   • 服务注册中心：consul；
   • 权限校验：jwt；
   • API监控：prometheus + grafana；
   • API统一日志收集：logback + ELK；
   • 压力测试：Jmeter；

比如限流 你需要缓存一些限流的策略，主要是缓存网关功能用到的一些数据，不涉及业务数据。 路由主要是做转发

三、IronCity 的总结

目前，我们业务代码是多语言的环境，网关则是用go写的，目前主要是做到了对于HTTP和Thrift的业务服务的转发（HTTP利用了fasthttp，Thrift用的网关启动客户端调用业务服务端的形式）过滤器是环绕的，系统统一的过滤和针对API级别的过滤。虽然用了go比较轻巧，但是目前功能还很值得完善

四、XuChuangfeng 的总结

设计要素：#1，高可用非常重要；#2，网关需要支持动态修改路由规则；#3，与服务注册中心整合，通过注册中心实现路由转发；#4，过滤器链适配不同的路由。

五、fudali113 的总结

选型

• 所使用的网关架构必须灵活，因为我们可能需要很多与我们业务相关的定制话的东西
• 有平台背书，获取有足够的证据证明他是一个能抗的住我们需求的并发的性能
• 根据需求选择最好的方案

  设计要素

• 结构必须灵活，方便扩展
• 基础的功能应该由框架提供或者抽象，比如动态路由，权限校验，限流

  我的

  我们使用zuul作为网关并对他进行了一定定制化的开发，因为我们使用springcloud技术栈，同时zuul基于filter来处理一切的结构也是非常灵活的，并且由netflix背书。我们在网关利用filter加入权限校验，统一访问日志记录，访问异常请求记录，聚合请求处理器等相关功能

负载均衡可以通过在之前加入一个nginx或者dns解析来做，高可用可以通过keepalived加虚拟ip与nginx结合或者直接与zuul结合来做

六、Ascend 总结

1. 能处理一些公共的逻辑，比如获取token
2. 能支持动态的修改路由规则
3. 对各服务结果和异常进行统一处理后返给调用方
   目前实施了几套方案，自己封装的gateway层，准备用zuul进行替代

七、曼陀罗 总结

网关的技术选型

1. SpringCloud-Zuul :社区活跃,基于 SrpingCloud 完整生态, 是构建微服务体系前置网关服务的最佳选型.
2. Kong : 基于OpenResty的 API 网关服务和网关服务管理层.
3. Nginx+Lua：成熟度也算可以
4. 自建网关：成本较高

网关（API Gateway）的设计要素（高可用，安全）

• 性能：API高可用，负载均衡，容错机制。
• 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
• 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
• 缓存：数据缓存。
• 监控：记录请求响应数据，api耗时分析，性能监控。
• 限流：流量控制，错峰流控，目前有漏桶算法、令牌桶算法也可以定制限流规则。
• 灰度：线上灰度部署，可以减小风险。
• 路由：动态路由规则。
• 静态：代理

简单介绍下你的网关实施方案

• 微服务基础框架：springboot；
• 网关基础组件：zuul；
• 服务注册中心：consul；
• API监控：prometheus + grafana or 自建；
• API统一日志收集：时序db + ELK；
• 压力测试：Jmeter，AB，阿里压测；

转载自：http://www.spring4all.com/article/336