大型网站架构演进流程

大型网站架构演进流程

---

一、架构演进1.0版本：用户 --> 浏览器 --> 服务器

在很早以前，用户会通过浏览器，输入对应的网址，进入对应的页面（页面一般有HTML、CSS、JS）构建的，此时访问是单向的，仅为服务器向浏览器单方向传输。

二、架构演进2.0版本：用户-->浏览器-->服务器-->数据库-->服务器-->浏览器-->用户

之前是用户通过浏览器向服务器单方面申请页面数据，现在服务器和用户之前可以有交互的信息，现在这块交互信息都是存在数据库中的。

三、架构演进3.0版本：单体MVC架构：

用户-->浏览器->单台服务器（war + 文件服务器 + 数据库服务器）

首先还是一样，用户还是会申请到浏览器，通过浏览器申请到服务器，那么此时服务器上部署的是war包，此时war包会包含Model、View、Controller,这块就是所谓的MVC架构模式，这种模式适合最开始是没有太多人访问的。那么这个模式还会用到文件服务器，用于存储用户上传的文件，例如头像、用户上传的一些文件等，所有的用户数据依旧存在数据库里面。

四、架构演进版本4.0：服务器分离模式（提升数据库）

用户 -> 浏览器 -> 服务器(war) -> 文件服务器 -> 数据库服务器

随着网络应用的发展，单台服务器的话是不能支持用户的访问需求的·。那么最强烈的问题是可能会导致空间不足，随着大量用户的信息上传，也会影响服务器的性能。一旦单体的服务器宕机了，那么我们服务器上的文件、数据、页面等信息都无法实现访问，这对于中小型企业来说，影响是巨大的。 所以，随之演变的进程变成了使用多台服务器分担访问的压力，页面服务器仅仅存放页面数据，文件服务器仅存放用户文件信息，数据库进存放用户数据，这样的话访问压力被三台服务器进行了分担。这也就是服务器降压。

五、架构演进版本5.0：服务器分离模式 添加缓存结构

用户 -> 浏览器 -> 服务器 |-> 文件服务器

                                        |-> 缓存中间件 -> 数据库服务器

随着时间的推移，用户的请求量或者说我们的用户量会成倍成倍的增加，企业网站这会又会遭遇到另一个问题，数据库的请求会随着这个问题导致请求的延时，这个问题的话就是用户请求的增加，那么这个时候我们会引入一个缓存的中间件，他其实就是一种防护机制，那么用户去请求的时候是不会直接落在数据库的，那么请求会落在我们请求的中间件里面，他会去我们缓存里面查询一下有没有这个数据，有的话会直接返回数据，没有的情况下才会去请求数据库。这样就会为我们数据库提供了一个良好的保护机制。

六、架构演进版本6.0：负载均衡+应用集群+缓存集群+主从数据库（主从数据库数据互通模式，主从数据库单体模式）

虽然我们使用了缓存，我们还是会受到一些量的读操作落到数据库服务器上，当然同时还有所有的写操作也会全部落在数据库上，所以当网站用户达到百万，千万级别时，那么我们数据库的一个负载能力，就会成为我们网站架构一个瓶颈，那么如何来解决这样的问题呢，大约有70%-80%的请求来自读请求，20%-30%的请求来源于写请求，这就是所谓的二八原则。所以我们可以通过数据库读写分离设置主从数据库，主数据库负责写操作，从数据库负责读操作，这样能极大的降低数据库读写产生的压力，读写分离需要注意是主从数据库数据的同步性，也就是定时进行数据更新交换，这样就能保证数据库的负载能力。

七、架构演进版本7.0：数据库集群演进

集群主从分离架构基于上个版本演进 主从数据库集群演进（哨兵模式也可以理解为三人投票机制 (两人投票胜出) ）

1、主数据负责写入，从数据库集群负责读取

2、分库及分表

大型网站业务急剧增长的情况下，数据库依旧负载不了日渐庞大的数据访问量，那么这里就会设置分库和分表分担不同访问的操作，那么这块的主数据库集群主要负责写操作，从数据库集群负责读取的操作。主从数据库分离的话同样需要注意数据的同步性，那么这块就需要通过一些算法和规则将数据均等分布在不同的数据库服务器中。只有当我们数据量极其庞大的情况下，我们才会考虑使用这种架构模式，即当我们单表的数据量达到7百万到8百万的情况下，就要开始启用数据分离架构了。在分库分表的情况下，我们也要考虑到数据的唯一性，这块就需要通过雪花算法等方式生成分布式唯一主键。

八、集群演进版本8.0：添加数据检索中间件

随着我们网站业务的一个持续发展，用户对于我们数据检索可能会出现多样化，我们数据库是可以模糊查询的，那么模糊查询可能就满足不了用户，也可以解决不了相应的需求，这时候就需要引入相应的搜索引擎（Solr或者ElasticSearch）,那么这样就不需要让用户的搜索信息到达数据库了，这样也对数据库提供了一定的措施（保护）。

九、集群演进版本9.0：微服务演进版本

俗话说，合久必分，这是一个永恒不变的定理，我们这块就会引入一个分布式微服务的概念。不同的系统业务逻辑就会被拆分成一个个子系统，以电商来举例，我们可以将商品业务逻辑单独拆分成一个服务，订单也可可以拆分成一个服务，那么还有很多的功能，用户服务，库存服务，消息服务等等等等。一旦进行拆分，那么数据库也会根据业务进行拆分，这样的话每个系统就可以交给不同的团队来维护，那么这块对于开发、运维、测试等工作人员也是一个巨大的挑战。因为业务也变得复杂了。那么这样不同的个体整合到一起，就是一个大型的系统。那么当然他也会有一些优缺点，优点就是复杂度会降低，业务分离，开发人员和开发团队就可以单独开发相应的模块。缺点就是代码就会变得相对复杂，运维相对于也繁琐。那么还有一个必须要考虑的问题，就是分布式事务，用户的请求可能同时到达多个数据库，这时就要保证数据的一致性。

十、架构演进版本10.0：拆分公共服务资源，性能调优

       我们往往会有一些通用的API或者接口，比如说短信，邮件，推送等服务，在整体系统中是作为公共服务资源进行使用的，我们在不同服务之间相互通用的时候，我们都会使用到一些分布式的服务中间件，比如说zookeeper,那么它就可以处理一些分布式锁。那么当然在我们分布式系统里面，我们还会有一个分布式会话，与此同时，我们分布式系统中互相调用的时候还会有一个异步通信，主要是异步调用的一种方式。那么在这里，我们会调用异步队列MQ消息队列。同时，分布式锁，分布式事务，分布式会话，都是我们需要在系统交互中考虑的问题。其实当我们网站架构演变到这里的时候，我们系统基本上能解决大部分的需求和性能问题。当然我们的JVM,Tomcat，数据库等都需要根据我们出现问题的日志分析进行对应的性能调优。这样就能保证我们系统架构能成为一个大型的网站架构了。

总结：

1、架构演进版本不必跟着当前版本编号进行，可以根据公司系统业务需要进行合适的项目演进

2、以上内容属于个人编写，如有问题敬请提出。

如果各位小伙伴想了解更多内容，

欢迎加群讨论:群号：834223478