微服务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
阅读更多
个人分类: 架构设计
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭