客户端需要多次提出要求，要求不同域名对应的服务，增加了通信成本和维护客户端代码的复杂性。

每一项服务都会单独进行服务验证，如果每一项服务验证的逻辑不同，就会导致客户端反复验证。

此外，如果每个服务都采用不同的协议，那么对客户来说就是灾难性的。

基于以上，我们需要一个中间层，让客户端要求中间层。至于需要请求的服务，我们需要请求中间部分，最后把结果总结回客户端。这个中间层是网关。

为何使用网关？

使用网关有几个功能：

统一鉴权

一般来说，我们在网关上评估权利有两种:1。它是对客户端身份的认证。2.访问权限控制是在确认用户身份后，判断是否有访问某一资源的权限。曾经我们在单个应用中，客户端要求验证身份和对资源权限的约束相对简单，相应的用户和权限信息可以通过要求的session获得。但是在微服务架构下，所有的服务都被拆分成单个微服务，集群部署会变得复杂，因为如果我们仍然使用session，我们将在每个分布式平台上寻求相同的效果。

日志记录

当客户端要求进入时，我们需要记录当前要求的时间依赖于来源、地址、ip等信息，这样我们就可以在网关层面统一拦截获取，然后通过ELK组件输出到日志文件中，记录内容可以在不分别记录的情况下，在多维度、多信息统一记录。网关模块方案

要求分发和过滤

对于网关来说，匹配和分发这个请求是最重要的功能。事实上，我们常见的nginx有一个请求转发和过滤的功能。对于网关来说，请求可以前后过滤。

请求分发:接受客户端的请求，将请求与后面的微服务相对应，并请求微服务。因为微服务的粒度比较细，这个网关可以整合各种微服务的功能，最后还给客户端。

过滤器：网关将拦截所有请求，相当于spring中AOP的一个横截面，在此截面上进行鉴权、限流、认证等操作。

灰度发布

一般来说，公司的互联网产品迭代非常快，基本上是小步快跑。基本上每周发布一次版本迭代。在这种情况下，会出现兼容性、功能完整性、bug最终发生事故等风险。一般来说，当我们发布它时，我们会将新功能发布到指定的机器上，并划分过去的一小部分流量来观察具体情况。因此，这个功能可以通过网关作为请求的入口来完成。