微服务--网关
- 一、为什么使用网关?
- 1) 客户端的需求量与每个微服务暴露的细粒度API数量的不匹配。 (比如,移动客户端一个页面,需要请求上百个微服务,没有效率)
- 2)客户端请求微服务的协议可能并不是web友好型。(每个服务的协议可能不一样,应用应该在防火前外采用类似http协议)
- 一个服务可能是用Thrift的RPC协议,而另一个服务可能是用AMQP消息协议。它们都不是浏览或防火墙友好的,并且最好是内部使用。应用应该在防火墙外采用类似HTTP或者WEBSocket协议。
- 3)很难重构;
- 随着时间的推移,我们可能需要改变系统微服务目前的切分方案。例如,我们可能需要将两个服务合并或者将一个服务拆分为多个。但是,如果客户端直接与微服务交互,那么这种重构就很难实施。
- 二、定义:
- 一个服务器,或者说是进入系统的唯一节点;
- 封装内部系统的架构,提供api给各个客户端(facade模式(外观模式)很像。 外观模式是在适配器模式下把多个方法整合到一个对外的方法中。);
- 负责请求转发、合成和协议转换。 (比如: 可以在web协议与内部使用的非Web友好型协议间进行转换,如HTTP协议、WebSocket协议。);
- 定制化的api (客户端请求的数据需要多个服务时,它只提供一个服务点就可以,不用客户端请求多个服务)。
- 三、网关的用途:
- 负责负载均衡、缓存、访问控制、请求分片和管理、静态响应处理、授权、监控等任务;
- 四、优缺点
- 优点:
- 封装应用内部结构;客户端直接跟gatway交互更简单点。API Gateway提供给每一个客户端一个特定API,这样减少了客户端与服务器端的通信次数,也简化了客户端代码。
- 缺点:
- 是一个高可用的组件,必须要开发、部署和管理;可能成为开发的瓶颈,开发者必须更新API Gateway来提供新服务提供点来支持新暴露的微服务。更新API Gateway时必须越轻量级越好。
- 否则,开发者将因为更新Gateway而排队列。但是,除了这些缺点,对于大部分的应用,采用API Gateway的方式都是有效的。
- 优点:
- 五、实现
- 设计要求:
- 性能和可扩展性:
- 只有少数公司需要每天处理大规模(上亿)的请求;对于大部分应用,网关的性能和可扩展性是非常重要的。支持同步、非阻塞I/O的网关。
- 例子: jvm中,采用基于NIO技术的Netty; Nginx Plus提供一个成熟的、可扩展的、高性能web服务器和反向代理,它们均容易部署、配置和二次开发。
- 采用反应性编程模型:
- 因为有一些请求,需要调用多个后端服务并合并结果处理,如果发送给后端服务的请求是相互独立的,可以并发的处理这些请求;如果这些请求之间是有依赖的,必须向请求A,才能请求B。
- 比如java8 的 completableFuture,支持 多任务并发执行、支持任务完成的先后顺序,原生的api,返回每个任务的异常, api丰富。
- 如果利用传统的同步回调方法实现Api的合并会很麻烦,代码复杂且难以维护。比较好的解决方法就是: 反应性编程模型,比如java8的completableFuture 和 js 的Promise 。
- 服务调用:
- 一个基于微服务的应用是一个分布式系统,并且必须采用线程间通信的机制。两种线程间通信的方法: 1、采用异步机制,基于消息代理的方法;如JMS、AMQP;2、采用同步机制,如Thrift、Http。
- 系统会同时采用同步和异步两种机制。
- 网关将需要支持多种通信机制。
- 服务发现:
- 网关需要知道每一个微服务的IP和端口,在传统应用中,采用硬编码;在云基础的微服务应用中,采用服务发现机制。
- 两种方式: 服务端发现与客户端发现(网关需要查询服务注册处,也就是微服务实例地址的数据库)。
- 处理部分失败:
- 在分布式系统中当一个服务调用另一个服务超时或者不可用的情况,就会发生部分失败。
- 网关不应该被阻断并处于无限期等待下游服务的状态,如何处理这种失败依赖于特定的场景和具体服务。比如:
- 产品详情页中,推荐模块无响应,其他信息比如图片、价格等应该返回给用户,推荐部分可以返回空、也可以固定返回几个;如果是产品信息服务无响应,网关应该给客户端返回一个错误。
- 当缓存有效时,网关应该能返回缓存。比如,产品的价格变化并不频繁,网关在价格服务不可用时应返回缓存中的数值。这个缓存可以有网关本身实现,也可以借助redis 等这类外部缓存实现,通过
- 返回缓存数据或者默认数据,网关确保系统错误不影响用户体验。
- Netflix Hysrix 对于实现远程服务调用代码来说是一个非常好用的库。Hystrix记录那些超过预设定的极限值的调用。它实现了circuit break模式,使得可以将客户端从无响应服务的无尽等待中停止。
- 如果一个服务的错误率超过预设值,Hystrix将中断服务,并且在一段时间内所有请求立刻失效。Hystrix可以为请求失败定义一个fallback操作,例如读取缓存或者返回默认值。
- 如果你在用JVM,就应该考虑使用Hystrix。如果你采用的非JVM环境,那么应该考虑采用类似功能的库。
- 性能和可扩展性:
- 六、总结
- 对于大多数微服务基础的应用,实现一个API Gateway都是有意义的,它就像是进入系统的一个服务提供点。API Gateway负责请求转发、请求合成和协议转换。
- 它提供给应用客户端一个自定义的API。API Gateway可以通过返回缓存或者默认值的方式来掩盖后端服务的错误。
-
原文链接:https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
-
参考链接:http://dockone.io/article/482
虽然使用SpringCloud 已经很长时间,但是细细读下来这篇文章,收益匪浅。简单的翻译和整理了一下,如有错误,还望指正。
- 设计要求:
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
实践Hadoop MapReduce 任务的性能翻倍之路
作者:李万雪, eBay软件开发工程师,2017年毕业于上海交通大学。目前负责日志在大数据平台上的分析和opentracing在ebay日志平台的实现。 原文链接:https://mp.weixin.qq.com/s?__biz=MzA3MDMyNDUzOQ==&mid=2650505625&idx=1&sn=374ae0fdf7b02cf3dfdd9180580204cb&chksm 摘要 eBay的CAL(Central Application Logging)系统负责收集eBay各种应用程序的日志数据,并且通过Hadoop MapReduce job生成日志报告,应用程序开发人员与运维人员通过报告可获得以下内容: API调用响应时间的百分位值 服务调用关系 数据库操作 eBay每天产生PB量级的CAL日志,
- 下一篇
《DNS稳定保障系列4--阿里云DNS稳定性武功秘籍揭秘》
DNS自1983年诞生以来一直是互联网功能的重要组成部分,现在互联网上绝大部分软件、服务都对其有所依赖,其本身的稳定、安全、快速成为了最核心的指标。只有底层的基础打扎实了,在DNS上运行的服务质量才有保证。阿里云DNS的稳定性一直受到业界称赞和用户肯定,到底是用了什么武功秘籍,才敢给用户承诺可靠性SLA 100%呢?以下我们一一揭秘。第一招:星斗大阵--全球节点部署 20年来阿里巴巴的网络设施经过不断持续投入建设,阿里网络已经发展成超大规模的完整网络架构体系,支撑了近百万规模系统资源的业务体量,网络延伸到达六大洲,70多个国家/地区,并与全球1000+的ISP和ICP建立直接互联,如此规模的星斗大阵成为了具有全球竞争力的网络基础设施。阿里云解析也正是构建在这个基础设施之上,随着阿里网络而扩张,目前已经在12个国家部署了40多个集群,并通过不断深耕优化,在稳定、安全、快速方面达到了业界一流的指标。 第二招:乾坤大挪移—BGP+ANYCAST技术 稳定即是要保证服务的高可用,阿里云解析敢承诺100% SLA的关键秘密就在这里。虽然阿里内部的网络链路都是至少双冗余的,但是物理网络本身受到内部...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8安装Docker,最新的服务器搭配容器使用