大型网站从0到壮大系列--分布式进化

最近拟将知识系统疏理一下，从大型网站从0到壮大的演进过程是漫长的演进，不能一蹴而就，合适自己企业的系统就是最好的系统。

一、纵向横向扩展

典型的小型网站系统，基本从LAMP开源架构起步或闭源windows+IIS+MSSQL系统起步，随着业务流量增加，会发生两种变化。

横向扩展主要靠硬件能力及扩展。单台服务器的能力有限，一般会采用购买更强的服务器进行替换，或者靠云计算的多台服务器来承载。就像人长胖主要靠“多吃脂肪”。

纵向扩展主要靠软件架构的分层、分布。单个业务功能需要拆分至多台服务器，软件系统可以向MVC等架构延展，一般会有展现层、业务逻辑层、数据层。就像人长高主要靠“多吸收钙”。

WEB接入层的主要核心是LVS负载均衡；服务层的核心主要是RPC远程调用框架（Dubbo等）；数据层的主要核心是分布式可扩展。

二、服务层的分布式调用

服务层存在同一种业务由多台服务器分担处理的现状，以保障业务系统的稳定性、并发性，而分布式框架成为解决服务之间相互调用的协作者。

如上图，某web前端需要查询用户的有效性，通过Dubbo等服务框架，有两种获取服务者（验证用户有效性的业务模块）的方式。一种通过web前端主动拉取，从注册服务器获取可以验证用户有效性的服务器列表，另一种则是服务器主动将服务器列表推送给web前端。方式一可以降低注册服务器的压力，但如果某台业务服务器故障，则无法快速告诉web前端；另一种则是增加了注册服务器的压力，但好处同样也是可以及时将服务器的状态告诉web前端。

三、服务调用的缓冲池

服务调用者获取到服务提供者的地址后，一般不会直接将数据发送给服务提供者，否则在业务高峰期容易造成服务提供者的压力过载。

在项目中，消息队列产品（MQ）用得非常广泛。

一种方式是将消息放入消息队列后，消息队列直接将消息发送至接收者，也称为点对点的模式。

另一种方式是将消息放入消息队列后，多个消息接收者主动根据topic来接收消息。

消息队列，除了用于高峰期的业务数据储存转发外，还可以用于延时业务场景。如30分钟内订购未处理则删除订单的业务场景，消息队列将消息暂存30分钟后，再发送给订单校验模块，如果未付款，则调用订单删除模块删除订单。

今天的第一章先讲到这里，未完待续。