【转载】大型互联网网站架构演变

这篇文章来自网络，我只写了一些批注以及我自己的一些感想而已。

一、分

我们知道，对于一个大型网站来说，可伸缩性是非常重要的，怎么样在纵向和横向有良好的可伸缩性，就需要在做架构设计的时候考虑到一个分的原则，我想在多个方面说一下怎么分：

首先是横向的分：

1. 大的网站化解为多个小网站：当我们一个网站有多个功能的时候，可以考虑把这个网站拆分成几个小模块，每一个模块可以是一个网站，这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。

   批注： 现在很多网站他运营着多个域名就比如CSDN，他的博客是blog.csdn.net ，写博客是用的write.blog.csdn.net，主站用www，每个站之间独立运营，让整个服务器的前面，Nginx负载均衡压力不会特别大，因为ng的负载每秒最大是3万多也有人说5万10万的，但是到最后限制最大的不是机器本身的性能反而是带宽。之前在博客上有看到有人，有人测redis最大连接是10万+的连接数时，那么需要的带宽1000G以上。所以连接数3万每秒吓人的一个并发量，那么每日的访问量就可以支持9个亿+。

2. 静态动态分离：静态文件和动态文件最好分离开成2个网站，我们知道静态网站和动态网站对服务器来说压力的侧重不同，前者可能重IO后者重CPU，那么我们在选择硬件的时候也可以有侧重，而且静态和动态内容的缓存策略也不一样。典型的应用，我们一般会有独立的文件或图片服务器。

   批注：通常我们处理动静资源都有不同的处理方法如果是静态文件，我们建议推送到cdn，用户也可以更快的获取到静态资源（html,css,js,image,video,file），查询数据源一定要放缓存（可以解决很多问题）。

3. 按照功能来分：比如有一个模块是负责上传的，上传操作很消耗时间，如果和其它应用混在一起的话很可能，一点点访问就会使服务器瘫痪，这种特殊的模块应该分开。安全的不安全的也要分开，还需要考虑到以后SSL的购买。

4. 我们不一定要全部用自己的服务器，搜索、报表可以依靠别人的服务，比如google的搜索和报表服务，自己做的不一定比得过别人，服务器带宽都省了。

   批注： 我觉得这句话就是真谛，自己写的不一定有别人好，有现成的，一定要拿来就用不要重复造轮子啊！专业的人做专业的事。

其次是纵向的分：

1. 文件也相当于数据库，IO的流量可能比数据库还大，这也算是纵向级别的访问，上传的文件图片一定要和WEB服务器分开。当然，数据库和网站都放在一个服务器上的很少了，这是最基本的。

   批注： 从一个小，流量网站到一个大流量网站分离业务模块这是一个必备的过程。

2. 对于涉及到数据库访问的动态程序来说，我们可以使用一个中间层（所谓的应用层或逻辑层）来访问数据库（部署在独立的服务器上），最大的好处就是缓存和灵活性。缓存的内存占用比较大，我们要把它和网站进程分开，而且这样做我们可以很方便的去改变一些数据访问的策略，即使到时候数据库有分布的话在这里可以做一个调配工作，这样灵活性就很大了。还有好处是中间层可以做电线网通桥梁，可能网通访问双线再访问电信会比网通直接访问电信服务器快。有人说我不分，我可以做负载均衡，对，是可以的，但是如果分的话，同样的10台机器肯定比不分10台机器可以承受更多的访问量，而且对硬件的需求可能不会很高，因为知道需要哪个硬件特别好。争取让每一个服务期都不空闲，又都不是太忙，合理进行组合调整和扩充，这样的系统伸缩性就高了，能根据访问量来调整的前提就是之前有考虑到分，分的好处是灵活性、伸缩性、隔离性以及安全性。

   批注： 这里有一个访问顺序，有缓存时读缓存，有本地文件或数据库时尽量读取本地文件或数据库，最后再通过网络socket连接访问网络缓存或数据库。这里是有一个读取时间的一个差别的，每个之间都是几个数量级的差别。

观察服务器找出瓶颈：

1. CPU：动态文件的解析需要比较多的CPU，CPU出现瓶颈就要看是不是哪个功能过长时间占用线程，如果是就分出去。或者就是每一个请求处理时间不长，但是访问量很高，那么就加服务器。CPU是好东西，不能让他干等，不做事情。
2. 内存：缓存从IIS进程独立出去，一般对WEB服务器来说内存不够的情况不是很多。内存比磁盘快，要合理利用。
3. 磁盘IO：用性能监视器找到哪些文件IO特别大，找到了就分到独立的一组文件服务器上去，或者直接做CDN。磁盘慢，大规模读取数据的应用靠缓存，大规模写入数据的应用可以靠队列来降低突发的并发。
4. 网络：我们知道，网络的通讯是比较慢的，比磁盘还慢，如果是做分布式缓存，分布式计算的话，要考虑到物理服务器之间网络通讯的时间，当然，在流量大了以后，这可以提高系统的接纳能力一个等级。静态内容可以借助CSD分担一部分，在做服务器假设的时候还要考虑中国特色的电信网通情况以及防火墙。
   

   批注：这里要说的就是我们众所周知的木桶效应，一个系统的健壮性是由这个系统的短板来决定的，找出短板并解决短板问题，是最快解决系统的问题的方法。也是敏捷开发里面常用的一些方法。

数据库服务器：

其实还是水平分割和纵向分割，一个二维表，水平分割就是横过来切一刀，纵向分割就是竖直切一刀：1、纵向分割就是，我们不同的应用可以分到不同的DB中，不同的实例中，或者说把某个拥有很多字段的表拆分成小表。2、横向分割就是，某些应用可能不负载，比如用户注册，但是用户表会非常大，可以把大表分开。可以采用表分区，数据存储在不同文件上，然后再部署到独立物理服务器增加IO吞吐以改善读写性能，土一点的做法就是自己定期把老的数据存档。表分区的另外一个优势可以增加数据查询速度，因为我们的页索引可以有多层了，就像一个文件夹中的文件不要太多，多分几层文件夹一样。3、还可以通过数据库镜像、复制订阅、事物日志，把读写分开到不同的镜像物理数据库上，一般来说够用，如果还不行可以用硬件来实现数据库的负载均衡。当然，对于BI，我们可能还会有数据仓库。架构上考虑到了这些之后，流量大了，就可以在这个的基础上再去调整或者做WEB服务器或者应用服务器的负载均衡。动态WEB服务器配好点的CPU，静态WEB服务器和文件服务器磁盘好点应用服务器内存大点，缓存服务器也是，数据库服务器当然内存和CPU都要好。很多时候我们都是在重复 **发现问题**–>**找到瓶颈**–>**解决问题** 这个过程。

批注：数据库处理要注意几点，读写分离，合理使用缓存，分库分表，使用索引和存储过程，数据记得备份。还有就是服务器有他的处理极限值，不要真的压干服务了很容易挂的。

二、并

为什么要分？是因为我们希望通过分来提高系统的承载能力，那并又是并什么呢？我想了一下有几个方面可以并：

1. 合并用户请求，最基本的就是合并CSS/图片/脚本，还可以合并页面。不过合并就可能产生流量的浪费，需要有一个平衡点。

   批注： 前端优化有 雅虎的优化黄金规则34条（也叫军规34条），建议大家看一看里面的第一条叫做减少http请求，为什么呢？因为，从建立请求到发送请求到接收请求，然后解析数据这个是一个很耗时间的过程。你有兴趣的请看chrome开发者工具里面的network 的Timeline。

2. 合并接口的粒度，如果做分布式应用的话，我们可能不会直接访问数据库而是调用应用层提供的接口，由于是网络调用，代价比较大，因此在设计的时候尽量提供粒度比较粗的接口，一次调用返回比较多的数据，而不是细化到添加删除修改的层次。

3. 合并接口的部署，对于频繁的跨机器调用可以考虑有一些数据冗余，把跨网络的服务编程进程间通讯，甚至转到客户端来做。比如论坛发贴时候脏词的过滤，直接调用应用层提供的接口（跨机器）是可以的，但是可能代价比较大，可以把这个接口使用IPC方式部署在本机。

三、转换思路

时间换空间，空间换时间是常见的做法，具体一点说：

1. 缓存。缓存的重要性早计算机的硬件中就有重要的体现。对于网站，有很多种缓存，可以是客户端资源的缓存，可以是页面输出缓存，也可以是应用层的数据缓存，目的都是一样的，或是减少了服务器请求次数，或是减少了请求的处理过程，或是减少了数据库的访问次数。当然，生成静态文件也可以算是一种缓存。不访问磁盘固然不可能，但是我们要极大限度降低磁盘访问的机会。

2. 有的时候为了获取极快的响应，我们还会不惜代价采用重复计算。比如，我们的某个操作很可能会由于网络问题等原因响应比较慢，在设计的时候可以有一个统一的处理接口，由这个接口分发到不同的服务器去异步实现这个操作，哪个服务器先返回了结果我们就用这个结果，然后杀死其他服务器的冗余操作。

3.网站一般追求比较快的响应，一般不太会在比较高的层次用时间来换取空间，但是在一些用户独有数据的处理算法上可能还是会考虑到空间的节省问题。

1. 有的时候我们会用一些聚合表来存放聚合数据，也就是进行一些预计算提高复杂计算（比如报表）的性能。当然，对于数据分析，构建多维数据库也是一种不错的选择。

有很多网友留言说说的比较粗，没有什么具体的东西。我觉得架构这个东西很难去说具体怎么做，因为具体实施的时候要看情况去应用的，由于没有完美的东西，所以做架构通常是去做一个平衡，很可能某一个侧重不同会影响到架构的实施。希望我的这些文章能给大家一个提示的作用，看了之后如果你觉得“这点我倒没有考虑到，以后要注意”那或许就是最大的帮助了，下面我想说一些其它方面的问题，每一条都很零散，算是一个补充吧：

1.到底是采用已有的东西还是自己去做需要详细考虑的，采用别人的东西可能比较稳定，但是自己的控制少了一点，采用自己做的东西可以很灵活，但是可能会问题比较多。不管怎么样，我们在采用一个第三方框架的时候务必要进行缜密的调查，看到他的不足，否则项目很可能在后期被这个框架制约，反之，决定自己去做一个框架的时候也要看到自己需要什么其他框架不能提供的东西。

2.数据传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO（磁盘，带宽，传输能力）和CPU之间有一个平衡的考虑。

3.理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。在使用一个统一的调度中心来调度这些服务器，分配请求的时候，我们要考虑一下调度服务器能承受多少流量。

4.使用大量的廉价服务器还是少量的高配服务器？如何根据需求来组合服务器发挥最大作用。

5.对于分布式构架，我们尽量让每一个节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，另外。需要有统一的地方来管理所有的节点。

6.功能分解、使用异步进行整合、故障转移、失效保护。

7.软件的架构升级和计算机硬件的架构升级很像，可能有一段时期，我们是在慢慢提高整体能力，2年也才提高了几倍，之后发现只有通过某种彻底的架构改变才能提高数十倍的能力，升级之后，我们或许又会遇到其他问题。就像CPU，是简单提高主频还是彻底更换架构。

8.数据方面，读写分离、数据库分隔、功能划分、缓存、镜像。

9.硬件网络上的架构很重要，但软件开发中的一些细节不可忽略，好的架构不意味着不需要代码审阅。

---

读后感
文章里写的很多点都是我们现实中遇到的以及实际处理方法。当我们的程序压干了服务器的资源，就得考虑分离业务、增加服务、换新的技术方案。其实我们现在处理的这些技术里面横向或纵向扩展最难过的一关就是人为因素。服务器少的时候，代码是很重要的。服务器多了之后，自动化管理很重要的部分。通常我们是在出了问题我问题呈现之后才去修改。不管是刚开始编码的菜鸟，还是编码十多年的老鸟，都会出现代码上的问题，只是多少而已。当然太鸟，出现这种问题的可能性，要大很多。遇到过很多菜鸟，写的一些计算机算法，sql查询，逻辑代码都很烂。直接导致了程序的很难维护。现在想起来很多，像代码审计这个确实是非常重要的也是很必要的。

---

本文来源于网络未找到署名，我读后感觉很好所以添加了批注和读后感，如果谁知道原作者请联系我加上。谢谢！