架构设计的高可扩展性表示可通过加机器线性提高系统处理能力，承担更高流量和并发。

由于峰值的流量不可控，不可能在系统架构设计初期就考虑好机器数量以支持并发。

一般基于成本考虑，在业务平稳期，会预留30%～50%冗余机器应对运营活动或者推广可能带来的峰值流量，但当有突发事件时，流量可能瞬间提升几倍。莫过于明星公布恋情，大家都会到两人微博下互动，微博流量短时内迅速增长，微博信息流也短暂出现无法刷新消息，系统一时间不可用。

所以如何应对突发的流量呢？

最快的方式就是堆机器。不过能保证扩容三倍机器后，系统也能支撑三倍的流量吗？

系统瓶颈在哪里？

通过在单机系统中增加处理核心，可增加系统的并行处理能力，但当并行任务数较多时，系统会因为争抢资源而达到性能拐点，处理能力不升反降。

集群系统也是这样。不同的系统分层上可能存在一些“瓶颈”，这些瓶颈点制约着统的横向扩展能力。

比如系统流量1000 QPS，对DB也是1000 QPS。若流量增加10倍，虽然系统可通过扩容正常服务，DB却成瓶颈。或单机网络带宽50Mbps，若扩容到30台机器，前端负载均衡带宽就超过千兆带宽限制，也会成为瓶颈点。

所以系统中存在哪些服务会成为系统扩展的瓶颈呢？

无状态的服务和组件很易于扩展，但是MySQL这种存储服务有状态，较难扩展。因为向存储集群中增减机器时，涉及大量数据迁移，一般关系型DB都不支持。

DB、缓存、依赖的第三方、负载均衡、交换机带宽等都是系统扩展时需考虑因素。得清楚系统并发达到某量级后，哪个因素会成为系统瓶颈点，从而对症下药。

高可扩展性设计

拆分，把庞杂系统拆分成独立、单一职责的模块。

注意对不同类型模块，拆分原则不同。假如设计一个知乎，那么会有几个模块呢？至少5个模块。

用户：负责维护社区用户信息，注册，登陆等；

关系：用户之间关注、好友、拉黑等关系的维护；

内容：社区发的内容，就像朋友圈或者微博的内容；

评论、赞：用户可能会有的两种常规互动操作；

搜索：用户的搜索，内容的搜索。

部署方式遵照最简单三层部署架构

负载均衡负责请求的分发

应用服务器负责业务逻辑的处理

数据库负责数据的存储落地

所有模块的业务代码混合，数据也都存在一个库。