作者回复: 你好，反向路由或者代理(reverse proxy)，主要针对前向路由和代理(forward proxy)来讲的，都是技术术语。 举例，如果我们X要访问国外的一个网站Z，但是被墙了，这可以时候可以通过找代理Y来翻墙访问，这个代理就是前向代理，它帮助我们去访问目标服务（这个目标服务我们是知道的，只是被墙了），X->Y->Z。 对于企业内部的服务，一般躲在如nginx这样的反向代理后面，当我们X去访问企业的服务Z时候，我们并不知道具体服务部署在那里，反向代理Y知道并且会反向帮我们去转发，X->Y->Z这就是反向代理的作用，屏蔽内部服务的部署和实现细节。 两者的地位有点类似，但是具体作用不同。可以进一步参考stackoverflow上的详细解释：https://stackoverflow.com/questions/224664/difference-between-proxy-server-and-reverse-proxy-server

作者回复: 对后端微服务做负载均衡可以是网关的一个主要功能（也有不靠网关做负载均衡的做法）网关一般无状态布部署多个，且可横向扩展，网关本身靠前置LB做负载均衡。

作者回复: 有状态分为两种，一种是全局状态，一种是局部状态，局部状态相当于每个节点有一份自己的状态，这个不影响横向扩展。比方说，zuul gateway + ribbon + eureka 实现负载均衡，每个zuul有一个ribbon配合实现负载均衡，微服务启动时注册到eureka，之后每一个zuul上的ribbon会同步eureka中的服务实例列表，然后基于这个服务实例列表实现负载均衡和调用，这个服务实例列表就是局部状态，zuul仍然可以横向扩展，全局状态则在eureka中，eureka有自己的状态复制机制实现集群和HA。zuul前置可以有硬件负载均衡器(LB)，这样可以实现对zuul的负载均衡访问，硬件LB一般采用主备，或者DNS roundrobi机制实现HA和扩展。

作者回复: 1，haproxy可以做成网关，但是门槛比较高，需要深度定制，你有没有研发资源可以hold住？ 2，haproxy -> GW -> Service，中间再加一层网关也可以，haproxy相当于只做四层转发，对GW做负载均衡，现在不少是这样做的 3，聚合层一般是一种前端service，对后端服务进行聚合的，haproxy -> GW -> aggregator service -> backend service，这种模式用得也挺多 4, http绝对性能应该比不上tcp，但是要看场景，大部分互联网应用（比如电商）http足够 5，如果你求绝对性能，可以直接haproxy（tcp）-> service，开销最小，haproxy上可以扩展网关功能，需要定制自研能力，有研发资源能hold住

作者回复: 可以，术语没有明确规范，各家叫法可能不同，方便理解和沟通即可。

作者回复: 网关有路由表(服务名 or id <> 后台服务地址的映射)和路由逻辑，路由逻辑和业务逻辑不同，前者偏技术，后者偏业务。

作者回复: 不是说接了负载均衡以后就保证了网关无状态，而是说网关本身需要无状态多份部署，这样一方面可以按需水平扩容，另一方面可以保证高可用。无状态多份部署以后，就需要前置负载均衡设备，将流量按一定的负载均衡策略分发到不同的网关实例上。

作者回复: 1，一种部署方式为：硬件LB(或云端SLB)->nginx->gateway->app services，硬件LB(或云端SLB)对nginx做负载均衡，nginx对gateway做负载均衡，gateway对app services做负载均衡，上述是一个简化模式，实际使用中还有很多变体。 2，gateway是无状态部署，但是它可以连有状态服务，例如，gateway可以连redis进行登录态校验。

作者回复: 网关上面的LB可以是硬件LB，比如F5，也可以是如nginx这样的软件LB，还可以是硬件+软件两层结构，LB一般做成高可用（比如主丛+故障自动切换），不会随便挂，LB要真挂了服务肯定都访问不了了