13518219792
这篇文章主要介绍“怎么理解微服务网关”，在日常操作中，相信很多人在怎么理解微服务网关问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么理解微服务网关”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
在和林格尔等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计制作、做网站 网站设计制作定制网站,公司网站建设,企业网站建设,品牌网站建设,全网整合营销推广,成都外贸网站建设公司,和林格尔网站建设费用合理。
网关作为流量入口，其实就是一个把HTTP请求拓展到后端服务的过程，网关封装了后端服务，还提供了一些更高级的功能，例如：身份验证、监控、负载均衡、缓存、多协议支持、限流、熔断等等。
客户端与微服务直接通信，如果涉及到的微服务数量巨大，将导致客户端代码非常复杂。
部分服务使用的协议不是Web友好协议。一个服务可能使用Thrift二进制RPC，而另一个服务可能使用AMQP消息传递协议，不管哪种协议都不是浏览器友好或防火墙友好。在防火墙之外，应用程序应该使用诸如HTTP和WebSocket之类的协议，即协议需要适配。
这种方法的另一个缺点是，它会使得微服务难以重构。随着时间推移，我们可能想要更改系统划分成服务的方式。例如，我们可能合并两个服务，或者将一个服务拆分成两个或更多服务。然而，如果客户端与微服务直接通信，那么执行这类重构就非常困难了。
接口鉴权、限流、熔断降级、隔离、日志监控等通用功能在网关统一实现，不必下沉到业务逻辑，降低分开维护的成本与风险。
前端（包括app或者其它来源）的流量，都能在统一网关层进行接入，需要做到高性能透传、高并发接入。
面对海量流量，我们怎样通过一些防刷技术，保障网关不被大流量冲垮；以及怎样通过一些像限流、降级、熔断等技术，对网关进行全方位保护。
由于在内部开发中我们都是以RPC协议(thrift or dubbo)去做开发，暴露给内部服务，当外部服务需要使用这个接口的时候往往需要将RPC协议转换成HTTP协议。
防止恶意流量，黑名单机制、限制非法IP等手段拒绝恶意流量。
接入层需要能扛特别大的并发流量。Nginx天然就是NIO异步的方式，能够非常好地支持大并发的业务需求。所以可以把一些核心的，比如降级、流控等，都放在这一层（借助lua的应用逻辑实现），让它替我们在最前端把流量防住。
对于我们统一的网关层，如何用少量的机器接入更多的服务，这就需要我们的异步，用来提高更多的吞吐量。对于异步化一般有下面两种策略：
Tomcat/Jetty+NIO+servlet3
这种策略使用的比较普遍，京东，有赞，Zuul，都选取的是这个策略，这种策略比较适合HTTP。在Servlet3中可以开启异步。
Netty+NIO
Netty为高并发而生，目前唯品会的网关使用这个策略，在唯品会的技术文章中在相同的情况下Netty是每秒30w+的吞吐量，Tomcat是13w+,可以看出是有一定的差距的，但是Netty需要自己处理HTTP协议，这一块比较麻烦。
对于网关是HTTP请求场景比较多的情况可以采用Servlet，毕竟有更加成熟的处理HTTP协议。如果更加重视吞吐量那么可以采用Netty。
对于来的请求做到异步，为了达到全链路异步所以我们需要对去的请求也进行异步处理，对于去的请求我们可以利用rpc的异步支持进行异步请求，也可以考虑采用借助RxJava采取观察者模式进行异步请求。
限流、降级、熔断降级（熔断之后就相当于降级了）
图-tomcat分离
第一个是通过NIO的方式，把请求解析的线程和后面处理的业务线程进行分离。请求由Tomcat单线程处理，在NIO模式下可以用非常少量的线程处理大量的链接情况。业务逻辑处理和生成响应都是由另外的Tomcat线程池处理，从而跟请求线程隔离。这里的业务线程池还可以进一步隔离，不同业务设置不同的线程池。
还可以采用响应式编程，借助Reactor模式，在使用很少固定数目的线程和较少的内存情况下的提高吞吐量，避免阻塞，Spring-WebFlux正是响应式的编程框架。
第二个是业务线程池分离，就是通过一个线程的隔离技术，把不同的接口或不同类型的接口进行隔离。
比如订单相关的接口，拿20个单独线程去处理；商品相关的接口，拿10个单独的线程去处理，这样的话就可以让不同的接口之间互不影响，如果订单这块有一个出了问题，最多消耗它自己，不会影响到其他接口的线程的调用。
具体的线程隔离可以根据业务来指定一组线程的数量，这几个线程是为固定接口准备的。
当这个接口出现问题，它就把自己的线程数用掉了，不会去占用其他接口的线程，这样起到了线程隔离的作用，让单个API出问题的时候不会影响到其他。
信号量隔离
信号量隔离只是限制了总的并发数，服务还是主线程进行同步调用。这个隔离如果远程调用超时依然会影响主线程，从而会影响其他业务。因此，如果只是想限制某个服务的总并发调用量或者调用的服务不涉及远程调用的话，可以使用轻量级的信号量来实现。有赞的网关由于没有自定义filter所以选取的是信号量隔离。
线程池隔离
最简单的就是不同业务之间通过不同的线程池进行隔离，就算业务接口出现了问题由于线程池已经进行了隔离那么也不会影响其他业务。在京东的网关实现之中就是采用的线程池隔离，比较重要的业务比如商品或者订单都是单独的通过线程池去处理。但是由于是统一网关平台，如果业务线众多，大家都觉得自己的业务比较重要需要单独的线程池隔离，如果使用的是Java语言开发的话，那么在Java中线程是比较重的资源比较受限，如果需要隔离的线程池过多不是很适用。如果使用一些其他语言比如Golang进行开发网关的话，线程是比较轻的资源，所以比较适合使用线程池隔离。
集群隔离
如果有某些业务就需要使用隔离但是统一网关又没有线程池隔离那么应该怎么办呢？那么可以使用集群隔离，如果你的某些业务真的很重要那么可以为这一系列业务单独申请一个集群或者多个集群，通过机器之间进行隔离。
超时设置对于一个分布式系统非常重要，没有设置超时，请求响应慢的情况下可能会累积导致连锁反应，甚至雪崩，一般包括MySQL、redis、RPC服务、HTTP服务等的超时。快速失败是非常重要的实践，不光是网关系统，其它系统也是一样，需要重点关注整个链条中的超时设置。
在设计模式中有一个模式叫责任链模式，他的作用是避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。通过这种模式将请求的发送者和请求的处理者解耦了。在我们的各个框架中对此模式都有实现，比如servlet里面的filter，springmvc里面的Interceptor。Zuul就采用了这种模式，分为前置、路由、后置和错误过滤器，一个请求会先按顺序通过所有的前置过滤器，之后在路由过滤器中转发给后端应用，得到响应后又会通过所有的后置过滤器，最后响应给客户端，在整个流程中如果发生了异常则会跳转到错误过滤器中。
到此，关于“怎么理解微服务网关”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
