微服务架构-服务网关(Gateway)-服务网关在微服务中的应用

服务网关在微服务中的应用

我们将目光转向Spring Cloud应用的外围，讨论微服务架构下的各个模块如何对外提供服务。

1、对外服务的难题

微服务架构下的应用系统体系很庞大，光是需要独立部零的基础组件就有注册中心、配置中心和服务总线、Turbine异常聚合和监控大盘、调用链追踪器和链路聚合，还有Kafka和MQ之类的中间件，再加上拆分后的零散微服务模块，一个小系统都能轻松弄出20个左右的部署包。

我们前面都是采用localhost加端口的方式直接访问，如果这些服务一并都要提供给外部用户访问那该怎么办？

产品经理表示可以让前端程序员加班加点在各个页面给各种不同请求配置URL和端口号，人不是问题，项目完成就行。可是这一大堆URL在页面上换来换去的，用户还以为是进了钓鱼网站，有的同学会说，我们配一个URL，通过F5或者Nginx可以做路由，话是没错，可是这样就要让运维团队手工维护路由规则表，当我们新增删除节点或者因为更换机房导致IP变化的时候就很麻烦；因此我们需要引入一套机制来降低路由表的维护成本。

还有一个问题就是安全性，我们在提供外部服务的时候住往会加入一些访问控制，比如说下单接口不允许未登录用户的访问，有的服务还会通过一些JWT签名等防止客户端篡改数据。如果让每个服务提供者都实现同样的访问验证逻辑未免有些太繁琐，这样纯属是增加研发人员的怒气值，况且如果有一天我们需要更换权限认证方案，比如更换为OAuth2.0，难不成还要每个服务提供者都做变更?

我们如何对外提供服务，既能管好路由规测，还能做好访问控制呢?

在这个背景下，API网关应运而生，它就像一个传达