1. 大型站技术架构论述

2017-1-4 之前就拜读就阿里李智慧老师的大作《大型站技术架构核心原理与案例分析》，之前只是简单的通读了一下，最近正好抽出时间，再次精读一下并做个总结。

1. 大型站架构演化

大型站都是从小型站发展而来，站架构也是一样的，都是从小型站架构逐步发展而来。最开始的小型站访问人数不多，一台服务器绰绰有余，这时的站架构如下图：

应用和数据分离后，不同服务器承担不同的角色，并发处理能力和数据存储空间得到很大改善。但是随着进一步发展，用户逐渐增多，面临新的挑战：数据库压力太大导致访问延迟，进而影响整个站的性能，这时需要进一步优化：

站访问的特点遵循二八定律：80%的业务逻辑集中访问20%的数据。比如微博的热点访问。既然如此，如果我们把这一小部分集中访问的数据缓存在内存中，而不是每次都从数据库中读取，就可以减少数据库访问的压力了、从而提高整个系统数据访问速度。

站的缓存有两种：
1. 缓存在应用服务器的本地缓存；
2. 缓存在专门的分布式缓存服务器上。
本地缓存速度快，但受到本地内存大小极限的限制。远程分布式缓存使用集群的形式。部署大内存的专门缓存服务器，理论上可以做到不受内存大小的限制。架构图如下所示：

在应用服务器前通过一台负载均衡调度服务器，将来自用户的浏览器的访问请求分发到应用服务器集群中任何一台服务器上。更多的用户只需要增加更多应用服务器即可，应用服务器的负载压力不再是整个站的瓶颈。

在使用了缓存之后，大部分的热点数据都可以直接从缓存中获得，不需要查询数据库。但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库。当用户数达到一定的数量级了之后，数据库因为负载压力过大而成为站的瓶颈。

目前大部分主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另外一台服务器上。我们可以利用这一特点，实现数据库的读写分离，从而改善数据库的负载压力。架构如下所示：

不管是CDN还是反向代理的目的都是为了尽早的把数据返回给用户，一方面加快用户访问速度，也能减轻后端服务器的负载压力。

任何单一的服务器都不能满足日益增长的也无需求。数据库经过读写分离拆成2台服务器但是随着业务发展仍然不能满足需求，这时就要使用分布式数据库和分布式文件系统。

分布式数据库是站数据库拆分的最后手段了，只有在单表数据规模非常庞大的时候才使用，不到万不得已时，站更加常用的数据库拆分是业务的拆分，将不同的业务的数据库部署在不同的物理数据库服务器上。

架构图如下：

这里，项目一般都是使用一个统一的数据访问模块来访问各种数据，减轻应用程序管理诸多数据源的麻烦。

大型站为了应付日益复杂的业务场景，通过分而治之的方法，将整个站的业务拆分成不同的产品线，比如大型电商购物平台会将首页、上铺、订单、买家、卖家等拆分成不同产品线，分归不同的业务团队负责。

将一个站拆分成许多不同的应用，每个应用独立部署维护。应用之间通过超链接建立关系；也可以通过消息队列进行数据分发。当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。架构如下图：

大型站架构技术演化到此结束。基本上大多数问题都能解决。

千万记住一点：驱动大型站技术发展的主要力量是站的业务发展。
技术是用来解决业务问题的，而业务的问题也可以通过业务的手段来解决。比如12306 抢票这个，除了提高并发能力还可以通过分时段抢票的业务手段解决。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！