在互联⽹早期的时候，单体架构就⾜以⽀撑起⽇常的业务需求，⼤家的所有业务服务都在⼀个项⽬⾥，部署在⼀台物理机器上。所有的业务包括你的交易系统、会员信息、库存、商品等等都夹杂在⼀起，当流量⼀旦起来之后，单体架构的问题就暴露出来了，机器挂了所有的业务全部⽆法使⽤了。
于是，集群架构的架构开始出现，单机⽆法抗住的压⼒，最简单的办法就是⽔平拓展横向扩容了，这样，通过负载均衡把压⼒流量分摊到不同的机器上，暂时是解决了单点导致服务不可⽤的问题。
但是随着业务的发展，在⼀个项⽬⾥维护所有的业务场景使开发和代码维护变得越来越困难，⼀个简单的需求改动都需要发布整个服务，代码的合并冲突也会变得越来越频繁，同时线上故障出现的可能性越⼤。微服务的架构模式就诞⽣了。
把每个独⽴的业务拆分开独⽴部署，开发和维护的成本降低，集群能承受的压⼒也提⾼了，再也不会出现⼀个⼩⼩的改动点需要牵⼀发⽽动全身了。以上的点从⾼并发的⻆度⽽⾔，似乎都可以归类为通过服务拆分和集群物理机器的扩展提⾼了整体的系统抗压能⼒，那么，随之拆分⽽带来的问题也就是⾼并发系统需要解决的问题。
