日用户流量大，但是比较分散，偶尔会有用户高聚的情况；
通过服务器架构和代码分流，系统架构设计保证它能够同时并行处理很多请求
高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率 QPS（Query Per Second）,每秒事务处理量(TPS),并发用户数等
1. Apache Jmeter 2.Visual Studio性能负载测试 3.Microsoft Web Application Stress Tool
1. 分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器
2. 当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群
3. 分布式静态资源，比如：静态资源上传cdn
4. 分布式计算，比如：使用hadoop进行大数据的分布式计算
5. 分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据。
分析:高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中. 高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）。 结论:缓存将是一个不错的选择。浪费内存。
分析:在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的 。当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况 。 结论:异步将是一个不错的选择
1.分层，将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统.
2.分隔，在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元.
3.包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展. 比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等。
使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能
分析:对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持
应用服务器集群
数据库集群
对于大型网站来说，网站可用性越高越好。 可用性量化指标：系统能正常运行的时间占总时间的百分比。99%的可用性就表示系统保证在99%的时间内正常服务。
如：通常99.99%四个九称为高可用，载人航天中，这一标准是99.9999%。
互联网架构的高可用设计可以从物理层、服务层、测试层三个方面去考虑
对于业务逻辑服务，一般会设计成无状态化的服务，无状态化也就是服务模块只处理业务逻辑，而无需关心业务请求的上下文信息。所以无状态化的服务器之间是相互平等和独立的。
故障转移就是在某一个应用服务器不能服务用户请求的时候，通过一定的技术实现用户请求转移到其他应用服务器上来进行业务逻辑处理
同时有三台服务器组成一个集群来对外提供服务，三台服务器之间是相互备份的关系，只是三台服务器是在同一机房。
为了达到更高的可用性，我们还可以考虑通过多机房的冗余备份，如左图所示。正常情况下，负载均衡器将请求都分发到机房1的服务器上去，在机房1处理故障，或者处理性能比较高时，负载均衡器可以将请求切换到机房2上来，从而达到机房之间的容灾备份。
冗余备份可以达到避免单点，系统容量备份，多方式容灾等目的。
一般网站服务都会有主调服务和被调服务之分。超时设置就是主调服务在调用被调服务的时候设置一个超时等待时间Timeout，主调服务发现超时后，主动进入超时处理流程。
例如：主调服务A调用被调服务B时，设置超时等待时间为3秒，可能由于B服务宕机、网络情况不好或程序BUG而导致B服务不能及时回复A服务的调用，此时A服务在等待3秒后，将触发超时逻辑而不再关心B服务的回复情况。A服务的超时逻辑可以依据情况而定，比如可以采取重试，或到另一个对等的B服务去请求，或直接放弃直接对外进行回包。
超时设置的好处在于当某个服务不可用时，不至于整个系统发生连锁反应。快速失败。
采用异步调用的方式调用被调服务，有利于将主调服务和被调服务进行解耦，同时提高系统的处理性能。
例如：当你在微信发布朋友圈时，微信APP的后台服务器需要把文字和图片存储到不同的服务模块上去，这时后台服务收到请求后，将两种不同的数据以异步调用的方式分发到不同的功能模块，这样的后台服务处理会更高效，同时即使图片存储模块响应时间长也不会影响到文字存储过程。
在一个大系统中，一般会有核心服务和次要服务之分，那么对于不同的服务可以采用不同的处理方案，出现故障时应该优先保证核心服务的运行。
大型网站系统的服务模块众多，经常会因为各种原因出现进程core掉，网络质量不好，机器宕机等现象，我们设计的系统应该具备监控上报和告警的能力，运维和开发能够通过监控报表实时的查看系统的运行状态。服务一旦出现问题能够及时发现，通过自动化处理，或者人工介入处理，从而达到缩短系统的不可用时间，提高可用性。
常见的监控指标有：CPU、带宽、内存使用率、网络连接状态，系统调用错误，成功率，PV，UV等。
对于设计的任何一个系统，都需要进行容量的预估和最大容量设置，当外部请求量超过最大容量时，应该启动防雪崩机制，以避免大量外部请求把服务压跨而不能对外提供服务。
例如A服务的最大QPS是5W/S，那么当外部请求达到5W/S时，A服务只服务5W/S的QPS，超过的部分直接拒绝服务，而不是强吞下导致A服务完全不可用。
在服务内可以建立队列，当流量过大时，储存一定的用户请求到队列，当流量偏小时再拿出来快速处理，从而达到削峰填谷的作用。在请求数据库时，这个方案使用得很多，避免写入高峰时压跨数据库。
对于每一次代码的提交，都能通过自动测试程序对整个服务进行整体的回归测试，这样可以快速地避免代码修改引入新的问题，而导致服务不稳定
对于网站系统要发布的服务，可以采用灰度发布的方式来进行发布。所谓灰度发布就是先在生产环境中选取一小部分机器进行发布，然后再测试验证，验证成功后再继续加大发布范围。如果遇到发布的版本存在重大BUG需要能快速的启动服务回滚机制，迅速恢复到发布前的稳定版本
对于大型系统来说，一般会有多个团队或者工程师同时进行开发。需要对相同的代码库进行版本管理和发布管理。目前大部分开发团队都采用SVN和Git等工具来进行代码管理和发布。
如：GitLab/GitEE/GitHub
什么是分布式架构：简单的说，“分工协作，专人做专事”。
分布式架构怎么实现高可用：软件系统架构分层冗余。
架构分隔的好处：简单的说，“分工协作，以时间换空间”。读写分离/削峰，为了高可用而生
分布式架构怎么实现高并发：软件系统架构通过异步或缓存削弱并发波峰。
微服务的高并发：简单的说，“分布式架构，功能分工协作”。
微服务的高可用： 1.服务冗余。 2.优雅服务降级/熔断 3. 服务缓存 4.服务自愈(容器)
微服务
高并发：阿里云slb，网关控制，核心业务冗余，多级缓存。微服务适度拆分。 核心业务，拆分细化，分流
高可用：熔断，nginx负载均衡，降低，CQRS架构，docker集群【反向代理】， docker【监控—杀dokcer---重启docker】【监控—杀domain--重启domain】
原文：https://www.cnblogs.com/qingyunye/p/13159652.html