微服务--网关

网关

五、实现

• 设计要求：
  • 性能和可扩展性：
    • 只有少数公司需要每天处理大规模(上亿)的请求；对于大部分应用，网关的性能和可扩展性是非常重要的。支持同步、非阻塞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/
• 虽然使用SpringCloud 已经很长时间，但是细细读下来这篇文章，收益匪浅。简单的翻译和整理了一下，如有错误，还望指正。