API 网关亿级流量架构与技术选型
Part 1 什么是网关
很多人会把网关类比成'门'，这个理解不算错，但要先分清网关和网桥的区别。
网桥工作在数据链路层，负责在不同或相同类型的 LAN 之间存储并转发数据帧，必要时还会做链路层协议转换。它更像是把两个网络段连起来。
网关则是一个更大的概念，并不特指某一类产品。只要能连接两个不同网络的设备或软件，都可以叫网关。它通常不只是转发，还可能承担协议转换、请求包装、路由分发等职责。
通俗理解
还是拿'去找老板'做个例子。
假设你要进集团总部找老板，大楼门口这道门，就是网关的角色。它会做几件很关键的事：
- 所有请求都从这里进入，也就是统一入口。
- 门卫会先看证件，相当于做鉴权，判断你这个请求能不能放行。
- 如果你要办的事不该找老板，门卫会把你转去投资部，这就是动态路由。
- 放行之前，门卫可能还会给你一张访问证，告诉你怎么走，这就像对请求做了包装。
所以，网关的本质其实很清楚：它在客户端和服务端之间加了一层缓冲和控制，把原本直接耦合的调用关系拆开，让系统更稳，也更容易演进。
为什么需要网关
在单体应用时代，客户端通常只需要调用一个后端应用，事情比较简单。到了微服务架构下，系统被拆成多个服务，如果这些服务直接暴露给外部，问题会一下子冒出来：安全边界变得模糊，客户端也会被后端服务的细节绑得很死。
客户端直接访问每个微服务，常见的问题有这些：
- 客户端的需求和微服务暴露的细粒度 API 不匹配。
- 有些服务使用的协议并不适合直接给 Web 或移动端调用，比如 Thrift、AMQP。
- 微服务一旦要拆分、合并或重构，客户端就会跟着大面积改动。
网关与服务器集群
在分布式系统里，网关可以放在不同层级：可以细到给每个服务实例单独配置一个 Gateway，也可以粗到为一组服务配置一个，甚至整个系统只保留一个统一入口。这样一来，系统的复杂度会明显下降，流量也更容易控制。
上面这类架构里，最外层是统一接入的流量网关，负责把外部流量分发到不同子系统；内层是面向业务系统的业务网关，更贴近具体服务。网关的价值就在于把原本分散的服务组织成一个更清晰的星型结构，让路由、隔离和治理都变得可控。
Part 2 网关设计思路
一个成熟的网关，通常要具备下面这些能力。
请求路由
这是网关最基础的功能。调用方不需要知道后端服务的真实地址，只要把请求发到网关，后续该去哪里、怎么走，由网关来决定。
服务注册
网关要能代理后端服务，就必须知道服务实例在哪里。通常服务会把自己的地址、URI、方法、HTTP 头等信息注册到网关，网关据此完成路由匹配。
负载均衡
一个网关背后往往挂着多个服务实例，所以它还要能在这些实例之间做负载均衡。简单一些的可以轮询，复杂一些的可以按权重分配，甚至做 session 粘连。
弹性能力
重试、幂等、限流、熔断、监控这些能力，网关都可以提前做掉。这样应用服务就只管业务本身，不必在每个服务里重复实现一遍控制逻辑。
安全能力
SSL、证书管理、Session 校验、授权、数据校验、恶意请求防护，这些都适合放在网关这一层。因为错误处理越靠前越好，越能减少后端服务的压力。
进一步的能力
除了基础治理，网关还常常承担这些任务：
