【架构认知】关于提供无状态的网关入口的必要性

背景

之所以专门针对网关入口的必要性来聊，是因为线上出现了，【因为网络攻击，大量面向80端口的连接被创建，在网络攻击故障期间，报出了 too many open file的问题，也就是连接数瓶颈问题】。连接数的增加，体现在【非法客户端到宿主机的nginx的连接】【nginx到业务服务的proxy-pass连接】

这个问题反映出，【业务机器，应该完全绝缘公网，哪怕只开放独立端口，也能被迫建立非法的连接数，导致业务波动】。

架构方式调整

应用上线时，原架构流程为:
![在这里插入图片描述](https://img-blog.csdnimg.cn/4a407c5a0836495883a20b4673fbbee0.png

该类架构，在cvm1的80端口被攻击时，cvm1上的服务，可能出现不稳定的情况。

修改后的架构为

架构调整后，业务cvm端口一律关闭，也就断掉了业务服务器直连的风险。

将服务的对外入口开关，放在lb上。也就是，目前lb可能被攻击。

当lb被攻击时，通过lb的预警，决策是否下掉一个lb，使用备选lb。

最终，从【cvm】变更，调整为【lb】变更。很显然lb的变更成本是最低的，因为他是无状态。而cvm上可能存在很多有状态的服务。

lb在apisrv服务中，就起到了无状态的网关入口能力，特性为:

• 无状态，可以任性切换备选节点。
• 作为应用集群的对外窗口, lb开放公网访问，lb对业务机器，通过内部访问。