重温《大型网站技术架构》一书，做一下读书笔记。

大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题。

1.初始阶段的网站架构

大型网站，都是从小型网站发展，逐步演化而来的。

最开始访问量小，应用程序、数据库和文件等都在同一台服务器上。

2.应用服务和数据服务分离

随着越来越多用户的访问，单台服务器可能出现内存不足、磁盘空间不足、CPU使用率过高等问题。

因此，我们将应用和数据进行分离：

随着用户的增多，数据库压力太大，导致访问延迟，影响网站整体体验。

由于大部分的业务访问集中在一小部分数据上，可以将这部分数据缓存起来。提升查询性能，降低数据库的访问压力。

单一应用服务器的处理能力有限，通过增加服务器来分担访问压力，使用负载均衡进行请求分发。

在网站的用户数达到一定规模后，全部的写操作，和部分读操作（缓存不命中、过期），将会导致数据库负载过高。

通过数据库的主从热备，主从数据同步，实现对数据库访问的读写分离。为了使读写对应用透明，通常会使用专门的数据访问模块。

由于中国复杂的网络环境，不同地区的用户访问网络时，速度差别极大。

有研究表明，网站访问延迟和用户流失率正相关。

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。

当数据库和文件系统遇到了瓶颈，我们需要使用分布式数据库和分布式文件系统。

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。

通过引入NoSQL和搜索引擎，可以更灵活高效的存取数据和对网站内容进行快速搜索。

为了应对日益复杂的业务场景，通常会将网站分成不同的产品线。

根据产品线将网站分成许多不同的应用，每个应用进行独立部署。

随着业务拆分得越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。所有应用和所有数据库进行连接，导致数据库连接资源不足。

解决办法是，将共用的业务抽出来独立部署，提供共用的业务服务给上层应用系统调用。

例如将用户管理、商品管理等抽取出来，由这些服务来连接数据库，上层应用系统负责管理与用户界面相关的业务逻辑。

如果能控制住并发访问的量，很多棘手的技术问题也就不是什么问题了。

技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。

通过理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢，直击要害。

开了个免费的知识星球。谈技术，也聊人生，欢迎加入交流学习。

题图：pixabay.com

《大型网站技术架构》

更多文章，请关注公众号：二进制之路