软件系统架构这样设计，系统想崩溃都难。
在软件系统发展到如今，系统的支撑能力已经大大的提升，比如电商行业，每天都是几亿的浏览量，几亿的交易量，都能够实现支持，均来源于软件技术的深入发展。
首先来说一下系统软件发展的几个阶段。
最早初期的单机阶段，那个时候，我们系统就是一台单体的服务器。
在单体服务器时代，每一个服务器都有物理上的瓶颈，比如4C8G，所谓的4C8G就是有4个内核和8个G的内存的服务器，假如我们一个人的信息登录会占用两兆的内存，那么8个G的内存就只能支持四五万人的登录，这便是所谓的硬件瓶颈。
逐渐发展的第二个阶段，分布式服务。
分布式服务的时候，相当于会将一个系统的软件功能逐步划分到很多服务器，上面有多个服务器协同作业，形成一套完整的服务。
在这个阶段的时候，比较消耗内存或者CPU的机器会单独的分离出来，扩张物理资源，进行一个独立的功能模块提供。
这样的设计大大提升了系统服务的供应能力，最初有阿里巴巴，京东等一线互联网大厂采用过此服务设计。
只是这个时候服务瓶颈达到了一个更高级的上限，并没有从根本上解决并发上限的问题。
如今逐渐演变成为第三个阶段云化微服务阶段，也就是现在的容器化服务阶段。
微服务阶段只是分布式服务的一个升级版，只是在原来的系统架构上划分的更为细节，也就是说拥有了更多的服务器支撑一个服务，而容器化服务更是一个跨时代的划分。
在容器化服务里面，所谓的动态扩容就是当一台服务器遭受了物理瓶颈之后，由系统自动升级新增一台服务来支撑这一个模块功能的使用。
所以系统有高并发需求的时候，我们可以这样去设计它，当有物理并发瓶颈的服务模块单独由一群服务器来支撑并且形成动态扩容的服务架构。
并在此基础上，提供队列机制，其次在其基础上提供一套查询缓存服务，此查询服务单独由服务器供应形成，动态容器化模式。
其次在结果的返回上进行包装，加工模块单独列为一块，其中以缓存作为配置服务，比如市场通用的rdis集群服务等技术，用作为它的一个支撑组件。
最后在数据库读取存储方面，可以采用最先进的大数据、数据集市等应用组件进行数据的存储交互。
最后输出数据的使用在这几个环节，我们也把它拆成一个一个的节点，放入到容器的每一个虚拟服务器中，设定如果当某一个节点服务达到一定的标准，系统自动扩容，形成动态扩容效果，保持系统的一个弹性伸缩，既不浪费资源，也保持了服务的供应。
当然这是系统高并发系统设计基础物理架构，真正实现高并发还需要在很多代码实现上有一定的使用优化，但肯定能够支撑起几千万的并发量。
愿互联网能造福民生，愿广大的程序研发者能够持续提升自己的研发能力，将更好的技术服务于民，供应于民，希望能够持续深入开发技术，提升科技生活，引领幸福民生。