概述
这种问题其实有很多形式的提问方式：
- 面对业务急剧增长你怎么处理？
- 业务量增长10倍、100倍怎么处理？
- 系统怎么支持高并发的？
- 怎么设计一个高并发系统？
- 高兵系统都什么特定？
- …
- 这种问题我们可以有一个常规的思路去回答，就是围绕支撑高并发的业务场景怎么设计系统才合理？接下来我们就可以围绕硬件和软件层面怎么支撑高并发这个话题区阐述了。本质上，这个问题就是综合考验你对各个细节是否知道怎么处理，是否有经验处理过而已。
- 面对超高的并发，首先硬件层面机器要能抗的住，其次架构设计做好微服务的拆分，代码层面各种缓存、消峰、解耦等待问题要处理好，数据库层面做好读写分离、分库分表，稳定性方面要保证有监控、熔断、限流降级该有的必须要有，发生问题能及时发现处理。这样从整个系统设计方法就会有一个初步的概念。
微服务架构演化
在互联网早期的时候，单体架构就足以支撑起日常的业务需求，大家的所有业务服务都在一个项目里，部署在一台物理机器上。所有的业务包括你的交易系统、会员信息、库存、商品等待都夹杂在一起，当流量一旦起来之后，单体架构的问题就暴露出来了，机器一旦挂了所有的业务全部无法使用了。
于是，集群架构开始出现，单机无法抗住的压力，最简单的办法就是水平扩展横向扩容。这样，通过负载均衡把压力分摊到不同的机器上，暂时是解决了单点故障导致服务不可用的问题。
但随着业务的发展，在一个项目里维护所有的业务场景使开发和代码维护变的越来越困难，一个简单的需求变动都有发布整个服务，代码的合并冲突也会变的越来越频繁，同时线上故障出现可能性越大。微服务架构模式就诞生了。
把每个独立的业务拆开独立部署，开发和维护的成本降低，集群能承受的压力也提高了，再也不会出现一个小小的改动需要牵一发而动全身了。
以上的点从高并发的角度而言，似乎都可以归纳为通过服务拆分和集群物理机的扩展提供了整体的系统抗压能力，但是，随着拆分而带来的问题也就是高并发系统需要解决的问题。
RPC
- 微服务化的拆分带来的好处和便利性是显而易见的，但是于此同时各个微服务之间的通信就需要好好考虑了。传统HTTP的通信方式性能首先并不太好，大量的请求头之类无效的信息是对性能的浪费，此外，对服务治理、追踪和易用性的要求也更高，这时候就需要引入诸如Dubbo类的RPC框架。
我们假设原来来自客户端的QPS是9000的话，那么通过负载均衡策略分散到每台机器上比如是3000，而HTTP改为RPC之后接口的耗时缩短了，单机和整体的QPS就提升了。而RPC框架本身一般都是自带负载均衡、熔断降级的机制，可以更好的维护整个系统的高可用性。