cjh的博客

从架构设计上来说，高可扩展性是一个设计的指标，它表示可以通过增加机器的方式来线性提高系统的处理能力，从而承担更高的流量和并发。你可能会问：“在架构设计之初，为什么不预先考虑好使用多少台机器，支持现有的并发呢？” 答案是峰值的流量不可控。一般来说，基于成本考虑，在业务平稳期，我们会预留30%～50%的冗余以应对运营活动或者推广可能带来的峰值流量，但是当有一个突发事件发生时，流量可能瞬间提升到2～3倍甚至更高，我们还是以微博为例。

这里将探讨高并发系统设计的第二个目标——高可用性。是你在系统设计时经常会听到的一个名词，它指的是系统具备较高的无故障运行的能力。我们在很多开源组件的文档中看到的HA方案就是提升组件可用性，让系统免于宕机无法服务的方案。比如，你知道Hadoop 1.0中的NameNode是单点的，一旦发生故障则整个集群就会不可用；

高并发的系统通常是业务逻辑相对复杂的系统，那么在这类系统中出现的性能问题通常也会有多方面的原因。因此，我们在做性能优化的时候要明确目标，比方说，支撑每秒1万次请求的吞吐量下响应时间在10ms，那么我们就需要持续不断地寻找性能瓶颈，制定优化方案，直到达到目标为止。在以上四个原则的指引下，掌握常见性能问题的排查方式和优化手段，就一定能让你在设计高并发系统时更加游刃有余。

软件架构分层在软件工程中是一种常见的设计方式，它是将整体系统拆分成N个层次，每个层次有独立的职责，多个层次协同提供完整的功能。我们在刚刚成为程序员的时候，会被“教育”说系统的设计要是“MVC”（Model-View-Controller）架构。它将整体的系统分成了Model（模型），View（视图）和Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。

以方法调用为例，同步调用代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。异步调用在大规模高并发系统中被大量使用，

高可用设计通常从和2 个层面来着手突破。