转载

「微服务系列 07」API网关原理和实施

杨波老师打了个形象的比方，加入我们有一个公司，公司有一个大门，大门有一个门卫，每天众多的员工上下班都会经过这个门卫，这个门卫在日常会做一些安全的管控确认员工的身份，有人进来寻址的时候门卫会帮助做一些信息指导帮忙客人找到对应办事的部门，在公司举办活动的时候帮忙管理人流量，因为公司有了这样一个门卫，可以把一些统一切面的事情交给门卫去做，这样就不要放每个访客直接就能冲进去公司部门的办公室。

那么在微服务中也有网关这样的一个角色，相当与一个门卫，称之为Api gateway，微服务中也存在各个服务，它们隐藏在网关之后，例如有订单，商品，用户，购物车等等的微服务，这些模块是每个团队各自去维护，也相当于在一家公司里面的各个部门，但是我们不希望外界客户来访问的时候，客户并不需要去了解和知道这些细节，

让客户看公司的服务会认为是一个整体的服务。这个就是我们的网关所起到的作用，能够屏蔽我们内部的细节，统一输出对外的接口。

从这张图上看到有四个层次，最上层是我们用户层，第二层是我们的负载均衡器，第三层就是我们的网关，最后是我们内部的微服务，在接入网关的时候为什么需要在上面需要一个负载均衡器，因为我们想让网关无状态，无状态的网关有一个好处，可以部署很多，不会有单点，即使挂了一台，其他的网关还在，这个对整个系统的稳定性起来非常重要的作用。一般的系统会有一个LB，然后对应多个网关。

网关能起到的作用很多，

最重要的一个重要反向路由，当外面的请求进来之后，怎么找到内部具体的微服务，这个是网关起来重要职责，将外部的调用转化为内部的服务服务，这个就是反向路由
第二个是认证安全，网关像是一个门卫，有一些访问是正常的访问，有一些是恶意的访问，例如说爬虫，甚至是一些黑客行为，网关需要将其拦截在外部- 第三个重要职责是限流熔断，比方说，有一个门，外面有流量进来，正常来说流量是比较稳定的，但也有可能有突发流量，有可能网站在搞促销，这个时候可能就有流量的洪峰闯进来，如果说内部没有好的限流熔断措施，可能造成内部整个服务的服务器瘫痪，网关就要承担限流熔断的职责。
最后一个功能，网关要承担日志监控的职责，外部的访问所有的流量都要经过网关，那么可以在网关上可以对所有的流量做访问的审计，把它作为日志保存起来，另外可以通过分析日志，知道性能的调用情况，能够对整个流量情况进行监控

那么这四大功能就是微服务网关所起到的作用，对微服务集群中来说网关是必不可少的。

思考：有一些架构师会把一些业务逻辑放在网关上，那这样的好处和弊端分别是什么呢

一般来说市面上的网关解决方案有

SpringCloud-gateway
netflix zuul
nginx + lua

而nginx+lua作为一套灵活的组织方案，并没有一套明确的网关制定规则，更多了依赖大家对网关的理解针对nginx进行内嵌式模块的开发，lua本身也是一种内嵌式语言，这种方案灵活但缺少规范而且对开发人员要求高，至于性能方面其实也取决与开发人员的一个水平。

zuul是基于servlet2.5，使用阻塞API，不支持任何长链接，如websockets，不过在spring中其实大部分也是同步阻塞的变成模式，zuul 1.x是一个基于阻塞的API,zuul已经发布2.x，是基于netty，也是非阻塞和支持长连接，不过springcloud没有整合方案，应该也不会整合，因为spring在主推自己的springcloud-gateway。

springcloud-gateway是spring的亲儿子，有一种说法是因为zuul2.x的跳票和zull1.x性能表现不理想，所以spring孵化了自己的gateway项目。Gateway 中Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的开发体验。

据了解已经有一些公司在从zuul迁移至springcloud-gateway，如果是新项目需要配置网关，目前来说选择springcloud-gateway是一个比较高效省心的方案。

博客地址：「微服务系列 07」API网关原理和实施

原文 https://juejin.im/post/5cde862d6fb9a07ef443d5b1

正文到此结束