服务架构设计
高并发支撑思考
我们先来看看这张图，首先我们可以思考一下，这个架构中，哪些地方可以做负载均衡，来承载更高的 QPS 呢？
首先，我们可以在 Nginx 外层，做负载均衡。举个例子，如果产品部署在阿里云，那么可以用阿里云的 NAT 网关，结合 ALB 来对 Nginx 做负载均衡。
我们可以看到，在 NAT网关 的最外层，是 EIP ，也就是阿里云的弹性公网ip，它最大的优点，我觉得就是“灵活”。然后在整个 VPC 外面，做 ALB 负载均衡。最后，请求来到了我们部署在 ECS 上的 Nginx ，这里的 Nginx ，到底是一台还是多台，肯定是根据当前业务的 QPS 来了，如果产品刚上线，每天的用户并不多，其实可以只放单台。然后我们的 Nginx ，将后端请求转发给 Gateway 网关，好了，这时候请求已经到了网关了，后面的也不用多解释了吧？
也就是说，从请求到服务器经历了三层负载均衡：
- 应用型负载均衡ALB：支持加权轮询和最小连接数调度算法，可根据自身需求选择相应算法来分配用户流量。支持根据不同的域名和URL进行流量调度，提升应用系统灵活性。支持包含TCP协议和UDP协议的四层负载均衡；支持HTTP协议和HTTPS协议的七层负载均衡。由于本身是支持弹性伸缩的，所以单实例支持100万
QPS。 - NAT网关：是一款企业级的公网网关，提供NAT代理（SNAT和DNAT）功能，具有10 Gbps级别的转发能力和跨可用区的容灾能力。跟我们理解的不太一样，但是也可以做一定的负载均衡，毕竟它拥有灵活易用的转发能力，还可以充当防火墙。NAT网关会将所有访问EIP的请求都转发到目标ECS实例上，同时会将以指定协议和端口访问EIP的请求转发到目标ECS实例的指定协议和端口上。
- Nginx 负载均衡：
Nginx应该没有小伙伴不熟悉的吧？一块高性能的 http 代理/反向代理服务器，一般在 Java 开发中，也经常用来做“负载均衡”。Nginx实现负载均衡的方式主要有三种:轮询、加权轮询、ip hash轮询。详细的我们在后面的文章中介绍。 - Gateway 网关负载均衡：这个应该是接触过 Spring Cloud 的小伙伴们都知道是啥了。在 Gateway 中，以
lb://开头的请求, 会被全局过滤器 RetryLoadBalancerClientFilter 拦截并进行负载均衡处理, 所有的动态路由都会自动负载均衡。
业务架构设计
回到最上面的那张图片，用户最先访问网站的时候，加载的静态资源通过 CDN 进行分发，这里当然也包括图片了。然后在未命中缓存等一些情况下，肯定需要回源到 Nginx 来，所以专门的静态资源服务器是必须的，也可以用诸如阿里云OSS、腾讯云COS、AWS S3等来托管，设置回源地址。
然后发往后端的请求，通过上面我们介绍的方式，最终请求到我们后端的服务，进行处理。 MySQL 则是我们的数据仓库， redis 和 elasticsearch 则用来做数据中间件。同时也可以用 ELK 来进行日志分析处理。
Nacos 作为系统中的服务注册于发现中心和配置中心，在必要情况下也是可以做集群的。mq就是最基本的消息队列了，然后部署的话，自然得化自动起来，结合 DevOps ，易于交付和维护。
最后，服务集群也可以做进一步的优化。比如说网关的黑/白名单、非入侵监控设计、数据库路由组件、服务治理、调用限流等等，都可以抽出来做中间件，这样能一定程度的解耦，而且便于以后的维护。
