在整个的微服架构中，我们将传统的单体拆分为多个微服以后，微服和微服之间的调用，我们一般叫它是去中心化的调用，整个去中心化的调用的实现，就是通过我们的服务的注册和发现中心来实现。
这些微服务之间本身有相应的接口交互,这个接口的交互,我们就叫直接的去中心化的点对点交互,但是用户微服务是怎么知道订单服务的一个订单查询接口在哪里的呢,所有这个时候各个微服务需要首先注册到注册中心里面去,然后从注册中心拿到接口的地址再对订单服务发起具体的微服务调用
对于这些服务之间完全是一种去中心化架构.
那为什么需要微服务网关呢?
如果想要将这些服务暴露出来那完全用微服务的注册发现中心就够了,但是当我们在建微服务的过程中还要去做前端的BS应用或者是前端的APP，在这种场景就涉及到需要把我服务的能力接口暴露给前端的APP使用。
由于做了前后端分离,就不能够用传统的这种服务注册,前端通常只能调用标准化的http接口地址,这样也方便去穿过相应的硬件防火墙控制,所以这个时候APP首先要去调用微服务网关提供的接口，那么在这种场景下
你可以看得到。它是间接的起了一个内部微服务的作用，那网关怎样去找到你具体要调的地址？app请求过来是一个具体的微服务的地址连接,网关拿到这个东西以后仍然是要去注册中心去寻址去找到到具体的调用地址以后再去直接调用下面的微服务
如果我用微服网关，可以看到微服务网关本身会和注册中心协助，使用它除了寻址以外，它还会间接的起到负载均衡的作用。也就是说，如果用户服务这个模块，我可能不止部署了这么一个模块，我可能还部署了B模块,C模块，在一个标准的微服务工程下面，当我新部署了C这个模块儿的时候，可以看得到我在对微服网关发起调用的时候，整个的寻址,负载均衡过程，它是完全自动化的实现，但是如果我没有用微服网关，我只是用了nginx的服务器，意味着你要在nginx反向代理中维护相当多的服务地址,随之而来的还有负载均衡,心跳等相关问题。