支撑高并发，在初期就需要把系统进行分层，在发展过程中把核心业务进行拆分成模块单元，根据需求进行分布式部署，可以进行独立团队维护开发。
分层:将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统.根据业务场景划分层次，比如应用层，服务层，数据层。比如把电商系统分成： (具体分多少个层次根据自己的业务场景)。分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问
分割：在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元，包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展。
分布式：分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器。当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群。分布式静态资源、分布式计算、分布式数据和存储。
集群：对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。 核心业务基本上需要搭建集群，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
对于异步，设计考虑：逆向思维，压力在数据库，那业务接口就不进行数据库操作不就没压力了、数据持久化是否允许延迟？如何让业务接口不直接操作DB，又可以让数据持久化？使用消息队列，将入库的内容enqueue到消息队列中，业务接口快速响应给用户结果(可以温馨提示高峰期延迟到账)。然后再写个独立程序从消息队列dequeue数据出来进行入库操作，入库成功后刷新用户相关缓存，如果入库失败记录日志，方便反馈查询和重新持久化。
面向服务：SOA面向服务架构设计、微服务更细粒度服务化，一系列的独立的服务共同组成系统。使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。最理想化的设计是可以把一个复杂的系统抽离成多个服务，共同组成系统的业务，优点：松耦合，高可用性，高伸缩性，易维护。通过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可以让服务支撑更高的并发。
对于宕机，最理想的方式是可以通过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操作等，通过自动化可以减少人工的操作的成本，而且可以快速操作，避免人为操作上面的失误。