大型网站架构进化阶段

1、 最开始，由于某些想法或者爱好，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于我们先关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了。

初始阶段网站架构：一台Server满足刚需，应用程序、数据库、文件等所有资源都集中在一台Server上，典型案例：基于LAMP架构的PHP网站。

2、 经过一段时间的运营后，由于网站具备一定的特色，吸引了部分人访问，逐渐发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题。

于是进入了第一步演变阶段：将应用服务、文件存储、数据库从物理上分离，变成3台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用抢占资源而形成互相的影响。

应用和数据服务分离：三台Server平天下—业务发展，单台不再适应业务的发展，将应用和数据分离后成三台Server（应用服务器、文件存储服务器与数据库服务器）。分离后三台Server对硬件资源的需求各不相同：应用服务器需要更快更强大的CPU，而数据库服务器需要更快的硬盘和更大的内存，文件服务器则需要更大的硬盘；

3、 好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接池竞争激烈，响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此，马海祥建议你可以考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力。

这个时候首先也许会选择采用Squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，更好的方案是将页面静态化），这样程序上可以不做修改，就能够很好的减少对Web Server的压力以及减少数据库连接资源的竞争。

使用缓存改善网站性能：3+X的Server模式—减少数据库访问压力，提高网站的数据访问速度。缓存又可以分为：本地缓存、分布式缓存，本地缓存访问速度快，但数据量有限；远程分布式缓存可以集群，因此容量不受限制；

4、 运营给力的情况下，发现随着系统访问量的再度增加，Web Server机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台Web Server，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了。

在做了这些考虑后，决定增加多台Web Server，增加多台Web Server时，会碰到一些问题，典型的有：

（1）、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或者将Web服务升级为Ngnix这类同时实现HTTP和反向代理负载均衡的方案。

（2）、如何保持状态信息的同步，例如用户Session等，这个时候会考虑的方案有写入数据库、写入存储、Cookie或同步Session信息等机制等。

（3）、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存。

（4）、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等。在解决了这些问题后，终于是把Web Server增加为了多台，系统终于是又恢复到了以往的速度。

应用服务器集群实现负载均衡：集群—解决高并发、海量数据问题的常用手段，实现系统的可伸缩性。通过负载均衡调度器，可将用户访问分发到集群中的某台Server上，应用服务器的负载压力不再成为整个网站的瓶颈。

这一步涉及到的知识体系：负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、Linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于ARP欺骗、Linux Heart-Beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。

 

5、 享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢？

经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢？

此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。

数据库读写分离：使用缓存后绝大部分都可以不通过DB就能完成，但仍有一部分（缓存访问不命中、缓存过期）和全部的写操作需要访问DB，在网站的用户达到一定规模后，DB因为负载压力过高成为网站的瓶颈。大部分主流DB都提供主从热备功能，利用这一功能就可以配置两台DB主从关系，一台数据更新同步到其它Server上。网站利用DB的这一功能，实现DB读写分离，从而改善DB负载压力。

这一步涉及到的知识体系：这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。

 

6、 经过不断的产品优化和运营，网站的访问量也在平稳的增长当中，前端访问的过程中，逐渐也感觉响应速度也越来越慢，检查服务器的资源使用状况，服务器一直处于比较高的负载运行当中，其中I/O吞吐量比较大，这时就需要考虑对一些静态内容实现CDN部署，同时增加方向代理技术来缓存用户常用的资源。

反向代理和CDN加速网站响应：CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理则部署在网站的中心机房。使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

 

7、 随着信息时代的到来，网站收集的数据呈指数倍在增长，包括结构化数据和流媒体数据等内容数据，还包括海量用户的行为操作数据，单纯的通过增加硬盘来扩展服务系统的存储容量，只能解决容量大小的问题，但是在I/O访问、数据备份、数据安全方面，还需要引入分布式文件系统和分布式数据库集群来解决数据存储和管理的问题；

分布式文件系统和分布式数据库系统：将单台文件存储的Server，扩展到多个文件Server集群，众多的Server组成一个文件系统网络。应用服务在读取分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点从获取的，由分布式文件服务系统提供文件读写和任务跟踪服务；分布式数据库集群也是相同的原理，将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。

 

8、 随着分布式文件服务集群和分布式数据服务集群的部署，数据存储和访问的速度有了很明显的改善，用户体验得到了提升，但是随之而来的是多重数据种类的快速检索带来了庞大的计算量，非关系型数据的存储容量越发庞大，急需引入NoSQL集群解决以下问题：

1)      不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。

2)      无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。

3)      弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。

4)      分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。

5)      异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。

6)      BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。

使用NoSQL和搜索引擎：NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

 

9、 系统拆分和解耦是单体应用系统向分布式网站应用系统演变的关键一步，也是很重要的一步，拆分和解耦的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等，拆分工作不难理解，但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统：高可用、可扩展、可维护、可伸缩的分布式系统。

业务拆分与解耦：拆分过程需要遵循一个基本的原则，就是“高内聚，低耦合”，拆分的实际工作就是解耦，过程还需要遵守一些原则：

1)      业务优先：系统都会按业务功能分成多个模块，每个模块又包含许多业务相关的功能，在系统拆分时，我们就可以优先考虑按照业务边界进行切割，切割完成后再针对每个模块进行拆解，循序渐进，逐渐迭代深入，最终完成系统的拆解。

2)      循序渐进：系统拆分过程中包含两个非常重要的工作：拆分和测试。二者缺一不可，并且二者是并行进行的，一定要边拆分边测试。每一步拆分完成都要保证系统功能是完整的，保证系统的测试是完整的。

3)      兼顾技术：重构技术，拆分过程不仅仅是业务梳理的过程，也是系统进行重构的过程。通过系统的重构可以使用一些模式让代码结构更清晰，具有更好的可读性，并且方便日后的修改；分层：拆分可以让系统分解为许多功能单一的系统，这些系统可以根据需要使用不同的技术和架构进行实现，可以让熟悉不同技术的人做不同的事，工作更高效，产品质量也可以提高。

10、       如果需要进化到这个阶段，说明这个网站已经进入超大型体量阶段了，用户可以按千万甚至是亿来计量，数据存储可以达到PB级别了。

如果说拆分和解耦，将应用程序的不同功能单元拆分，并通过良好的接口和契约模型，可以实现分布式应用系统的架构优化，实现大型网站系统的分布式应用集群，但是随着应用系统的不断开发和建设，越来越多的新功能重复叠加开发和部署，应用变成一个又大又复杂的庞大怪物，敏捷开发和部署都将是举步维艰。

微服务架构模型：为了解决敏捷开发的困惑，提升迭代开发和维护的效率，改善部署对大型网站系统稳定性的影响，采用微服务架构是可以为带来新的思路，一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。

微服务架构模式有很多好处：

首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。

其次，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。

再次，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。