# 1.1 分什么布 我尽量不把这本书写成软件工程专业的死板教学用书。但是每章第一节的确都是构建一个健全系统不可或缺的概念知识。 其实在前言中,我就已经叨叙了为什么要使用分布式架构。简而言之,就是要采用“**分而治之**”的思想,将网站这个大系统分成不同的子系统,每个子系统各尽其职,承担负载。 分布式系统实际上是一个很广泛的概念,不仅指网站的构架。因为这本书主要是讲PHP网站(实际操作更是ThinkPHP5) 如何进行分布式系统的构建和配置,所以本书提到的分布式系统主要是指PHP网站的常见分布式架构。要更了解这个分布式系统,我们得先来看看现在互联网上大多数小网站采用的是什么样的“单主机架构”。 ## 1.1.1 70%的网站 某乎上有这样的说法,互联网上90%的网站都是用PHP写成的(认真脸)。那么我们再估约,互联网上70%的网站可能都是用的一个主机这样的配置环境。那做为一个PHP程序员,LAMP / LNMP 这样的环境应该是再熟悉不过。我们这里就简单介绍一下,方便我们与分布式系统对比。 ![图1.1.1](https://box.kancloud.cn/36632158bb1fce9231ab19cdcd9b34da_908x432.png) 上图就很清晰地展现了一个最常见的PHP网站所运行在的环境。从客户端浏览器请求到收到页面的大致流程: > 1. 客户端向域名/IP的80端口通过HTTP协议发出请求,请求指定url; > 2. Nginx/Apache分析请求url,判断是静态资源则直接返回静态资源,判断是PHP脚本则向PHP请求解释PHP脚本; > 3. PHP脚本解释时,如果需要操作数据库,则会通过MySQL扩展与数据库产生链接; > 4. PHP将解释渲染而成的HTML(也可能是JSON等)返回给Nginx/Apache; > 5. 再由Nginx/Apache交回给客户端浏览器,用户就看到页面了。 没错,静态资源的存储、PHP脚本解析、MySQL数据库等等,这个网站的一切都在一个主机上发生了。当然,小网站使用这样的环境搭建没有任何错;但如果访问量到一定量级的网站仍旧使用这样的方式,那么其中任何一块的崩溃都可能导致整个网站宕机,没有Backup(备用)方案。并且如果要进行升级,那么不能针对瓶颈所在系统进行升级而只能对整个主机进行升级。这是**不安全**的,也是**不划算**的,况且单机性能是有极限的。 ## 1.1.2 我们要做的20% 本书所讲的分布式系统其实也是基于这样简单的单主机的结构,毕竟我们网站主要跑的还是PHP程序。但是我们要针对这样的基础构架进行升级,把这整个系统的各个组成成分(比如数据库、比如静态资源)划分到更多的主机上去。于是,我们来看一个典型的PHP网站采用的分布式系统架构: ![](https://box.kancloud.cn/f0f6bec51c9d0f90bae2e9633ff2018d_962x717.png) 图上的具体机制,第一节就不做赘述,这里只总体了解架构。垂直拆分与水平拆分的概念也会在第三节讲到。 仔细对比这张图与上面的“单主机架构”图。可以发现,下图中的**每一部分都是从原来的单个主机上剥离开来,形成单独的子系统**。正是这样的子系统分走了不同服务该承受的负载压力。如果其中的一个主机出现了故障,通常比如是Web服务器或数据库,那么我们有很多其他的平行服务器继续提供服务,这样更加**安全可靠**。在遇到下一次瓶颈时,分析瓶颈所在子系统,为对应子系统升级(添加机器数量、增加配置)即可,新机器到子系统的**添置、部署十分简单**。 当然,不是对于每一个网站都要求各个子系统都一应俱全,这有时是不必要的。比如,大多数网站的瓶颈在于数据库,而在计算方面问题不大,那么就可以只采用分布式数据库解决当下的问题。这一点,在下一节的瓶颈分析中会讲到。而具体每个瓶颈的应对措施其实就是接下来几章的分章内容。 同样,每个子系统的位置、关联也不是按上图那样死板固定,而是有很**灵活**的方案可供选择。比如,做为静态资源的分流,既可以选择自己搭建静态资源服务器也可以选择云服务商提供的CDN服务,或者甚至资源文件很少不需要分流直接部署在Web服务器上;Redis也可以不仅仅作为Session的共享,在大规模访问的情境下还可以作为数据库缓存使用。一切都可以根据网站的实际情况进行定制,前提是了解各系统的运行互联机制,这些都会在后期章节Cover到。