面试造航母系列之面对千万级、亿级流量怎么处理？

这是一道很常见的面试题，但是大多数人并不知道怎么回答，这种问题其实可以有很多形式的提问方式：

• 面对业务急剧增长怎么处理？
• 业务量增长10倍、100倍怎么处理？
• 系统怎么支撑高并发的？
• 怎么设计一个高并发系统？
• 高并发系统都有什么特点？

... ...

诸如此类，问法很多，但是面试这种类型的问题，看着无处下手，但是可以有一个常规的思路去回答，就是围绕支撑高并发的业务场景怎么设计系统才合理？如果能想到这一点，那接下来就可以围绕硬件和软件层面怎么支撑高并发这个话题去阐述了。本质上，这个问题就是综合考验对各个细节是否知道怎么处理，是否有经验处理过而已。

面对超高的并发，首先硬件层面机器要能扛得住，其次架构设计做好微服务的拆分，代码层面各种缓存、削峰、解耦等等问题要处理好，数据库层面做好读写分离、分库分表，稳定性方面要保证有监控，熔断、限流、降级该有的必须要有，发生问题能及时发现处理。

 

微服务架构演化

 

在互联网早期的时候，单体架构就足以支撑起日常的业务需求，大家的所有业务服务都在一个项目里，部署在一台物理机器上。

所有的业务包括交易订单、会员、库存、商品、营销等等都夹杂在一起，当流量一旦高起来之后，单体架构的问题就暴露出来了，机器挂了所有的业务全部无法使用了。

于是，集群架构的架构开始出现，单机无法抗住的压力，最简单的办法就是水平拓展、横向扩容。这样，通过负载均衡把压力流量分摊到不同的机器上，暂时是解决了单点导致服务不可用的问题。

但是随着业务的发展，在一个项目里维护所有的业务场景使开发和代码维护变得越来越困难，一个简单的需求改动都需要发布整个服务，代码的合并冲突也会变得越来越频繁，同时线上故障出现的可能性越大，微服务的架构模式就诞生了。

把每个独立的业务拆分开独立部署，开发和维护的成本降低，集群能承受的压力也提高了，再也不会出现一个小小的改动点需要牵一发而动全身了。

以上的点从高并发的角度而言，似乎都可以归类为通过服务拆分和集群物理机器的扩展提高了整体的系统抗压能力，那么，随之拆分而带来的问题也就是高并发系统需要解决的问题。

 

通信

 

微服务化的拆分带来的好处和便利性是显而易见的，但是与此同时各个微服务之间的通信就需要考虑了。

对于SOA、微服务化的架构而言，就对部署、运维、服务治理、链路追踪等等有了更高的要求。

基于此，无论选用何种框架Spring Cloud、Spring Cloud Alibaba、Dubbo、Thrift、gRpc其实都一样。

于现在国内的技术栈选择来说，大厂基本都是自研，中小厂更多采用如Dubbo这类框架，现在来说，Spring Cloud Alibaba应该是未来一段时间的主流方向。

但是无论使用何种框架，一些基本原理都是应该了解的。此处以Dubbo举例。

Dubbo工作原理

1. 服务启动的时候，provider和con