【网站架构】从简单到复杂，一步步演变

前言：最近想看看大型网站是怎么一步步演变过来的，看到了一篇写的很好，特此转发，仅供学习

 

1、大型网站的特性

一、高并发、大流量：PV 量巨大；
二、高可用：7*24 小时不间断服务；
三、海量数据：文件数目分分钟 xxTB；
四、用户分布普遍，网络状况复杂：网络运营商；
五、安全环境恶劣：黑客的攻击；
六、需求快速变动，发布频繁：快速适应市场，知足用户需求；
七、渐进式发展：慢慢地运营出大型网站；

 

2、大型网站架构目标

 

3、如何大型网站架构

说明：按照问题识别—>概念认知—>架构切分的思路，来分析大型网站架构的诞生：
    一、问题识别：当前什么问题、谁的问题、问题边界；
    二、概念认知：经过分析问题，会产生哪些概念，统一律念认知，达成沟通交流规范；
    三、架构切分：根据概念来解决问题，如何架构切分，产生哪些架构，提出具体解决方案；

 

4、网站架构价值观

一、核心价值：随网站所需灵活应对；大型网站不是从无到有一步就搭建好一个大型网站，而是可以伴随小型网站业务的渐进发展，慢慢地演化成一个大型网站；
二、驱动力量：网站的业务发展— 业务成就了技术，事业成就了人，而不是相反；

 

5、网站架构几个误区

一、一味追随大公司的解决方案；
二、为了技术而技术-->常见问题；
三、企图用技术解决全部问题：技术是用来解决业务问题的，而业务的问题，也能够经过业务的手段去解决；

 

架构体系演进

1、单机时代

草根时期，快速开发网站并上线。固然，一般只是先试水，用户规模也没有造成，经济能力和投入也很是有限。应用程序、数据库、文件等全部资源都集中在一台 Server上，
典型案例：基于 LAMP 架构的 PHP 网站；

优势：简单、快速迭代达成业务目标； 缺点：存在单点、谈不上高可用； 技术点：应用设计要保证可扩展；

 

2、使用缓存

有必定的业务量和用户规模了，想提高网站速度，因而，缓存出场了。

优势：简单有效、方便维护； 缺点：存在单点、谈不上高可用； 技术点：客户端（浏览器）缓存、前端页面缓存、页面片断缓存、本地数据缓存/数据库缓存、远程缓存；

如上图，缓存能够分为：

1. 页面缓存：客户端缓存，减小对网站的访问；
2. 本地缓存：访问速度快，但数据量有限，减小对DB查询；
3. 远程缓存：远程访问，能够集群，所以容量不受限制；

 

3、数据服务与应用分离

市场反响还不错，用户量天天在增加，数据库疯狂读写，逐渐发现一台服务器快撑不住了。因而，决定把数据服务和APP作分离。

优势：简单有效、方便维护、提升不一样Server对硬件资源的利用率；
缺点：存在单点、谈不上高可用；
技术点：文件服务器部署、数据库服务器，扩展数据访问模块；

分离后三台 Server 对硬件资源的需求各不相同：

    一、应用服务器：须要更快更强大的 CPU；  
    二、数据库服务器：须要更快的硬盘和更大的内存；
    三、文件服务器：须要更大的硬盘；

 

4、数据库读写分离

单台数据库也感受快撑不住了，通常都会尝试作“读写分离”。因为大部分互联网“读多写少”的特性所决定的。Salve的台数，取决于按业务评估的读写比例。

优势：简单有效、下降数据库单台压力；
缺点：读写分离，增长程序难度，架构变复杂，维护难度增长；
技术点：数据库主从同步部署，扩展数据访问模块，实现读写分离；

 

5、应用服务集群

数据库层面是缓解了，可是应用程序层面也出现了瓶颈，因为访问量增大，加上早期程序员水平有限写的代码也很烂，人员流动性也大，很难去维护和优化。因此，很经常使用的办法仍是“堆机器”。

优势：增长服务器和HA机制，系统性能及可用性获得保证
缺点：应用之间缓存、Session一致性问题；
技术点：负载均衡；

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

 

6、集中式缓存，session集中式存储

加机器谁都会加，关键是加完以后得有效果，加完以后可能会引起一些问题。例如很是常见的：集群应用之间页面输出缓存和本地缓存一致性的问题，Session保存的问题......。

优势：应用之间缓存、Session一致，存储无限制，能够扩展；
缺点：不如本地缓存访问快，缓存服务器、Session服务器等仍存在单点问题；
技术点：缓存服务器部署、Session集中存储方案；

 

7、动静分离

动静分离也是提升网站响应速度的一种经常使用方式。将动态请求与静态请求分离开，尽可能减小对应用服务器的压力。同时，能够再进一步对静态请求，进行缓存，以加快响应速度。

能够须要开发人员配合（把静态资源放独立站点下），也能够不须要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。

优势：减轻应用负载压力，针对静态文件缓存；
缺点：静态文件缓存更新失效问题；
技术点：动静分离、静态文件缓存方案；

 

8、反向代理、CDN加速

使用反向代理和CDN加速网站响应：CDN 和反向代理的基本原理都是缓存，区别在于：

    一、CDN部署在网络提供商的机房；
    二、反向代理则部署在网站的中心机房；

使用 CDN 和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另外一方面也减轻后端服务器的负载压力。

优势：减轻应用负载压力，异地缓存有效解决不一样地方用户访问过慢的问题；
缺点：成本大幅增长，架构进一步复杂化，也维护难度进一步增大，静态文件缓存更新失效问题；
技术点：CDN、反向代理方案；

 

9、使用NoSQL、搜索引擎

 

到这里，已经基本作到了DB层面和应用层面的横向扩展了，能够开始关注一些其它方面，例如：站内搜索的精准度，对DB的依赖，开始引入全文索引、NoSQL。
NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具备更好的支持。应用服务器则经过一个统一数据访问模块访问各类数据，减轻应用程序管理诸多数据源的麻烦。

 

 

 

优势：下降DB依赖；
缺点：单点问题，谈不上高可用；
技术点：NoSQL、搜索引擎、分布式；

到目前为止，一个可以承载日均百万级访问量的中型网站架构基本介绍完了。

 

10、如何保证高可用

保证高可用比较经常使用的手段：
    一、文件系统、数据库系统集群；
    二、静态内容服务器集群；
    三、CDN服务器集群；
    四、反向代理服务器集群；
    五、负载均衡调度器集群；
    六、分布式NoSQL服务器集群；
    七、搜索引擎服务器集群；
    八、分布式缓存服务器集群；
    九、分布式Session服务器集群；

优势：集群负载，保证高可用；
缺点：数据一致性、数据有状态问题；
技术点：负载调度器、集群方案；

截止目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么须要大面积的修改代码。

 

11、应用垂直拆分

随着业务愈来愈复杂，网站的功能愈来愈多，虽然部署层面是采用的集群，可是应用程序架构层面仍是“集中式”的，这样会致使不少耦合，不便于开发、维护，并且容易“一荣俱损”。因此，一般会把网站拆分出不一样的子站点来单独宿主。
经过分而治之的手段将整个网站业务分红不一样的产品线，如首页、商铺、订单、卖家、买家等 拆分红不一样的产品线，分归不一样的业务团队负责。各个应用之间能够经过创建一个超连接创建关系，也能够经过消息队列进行数据分发。

优势：下降耦合、分压；
缺点：应用架构复杂；
技术点：业务抽取拆分；

 

12、业务垂直分库

应用都拆了，因为单个数据库的链接，QPS，TPS，I/O处理能力都很是有限，DB层面也能够去作垂直分库操做。

优势：下降DB耦合、分压DB；
缺点：数据访问模块复杂；
技术点：业务抽取拆分；

 

十3、分布式服务化

拆分应用和DB以后，其实仍是会有不少问题。不一样的站点，里面可能会有相同逻辑和功能的代码。
固然，对于一些基础的功能咱们能够封装DLL或者Jar包去处处提供引用，可是这种强依赖也很容易形成一些问题（版本问题、依赖关系等处理起来很是麻烦）。
既然每个应用系统都须要执行许多相通的业务操做，好比用户管理、商品管理等，那么能够将这些共用的业务提取出来，独立部署。这样，传说中的SOA的价值就获得体现了。

优势：服务统一管理，提供重用度；
缺点：应用架构更复杂；
技术点：业务抽取拆分、服务化技术方案；

 

十4、消息队列出场 

应用、服务之间仍是会出现一些依赖问题，这时候，高吞吐量的解耦利器出现了。

优势：提升吞吐量、应用、服务之间解耦；
缺点：存在消息消费延迟问题；
技术点：消息队列技术方案；

 

十5、分库分表

 

最后，再介绍一个大型互联网公司都用的绝技--分库分表。我的经验，不是业务发展和各方面很是迫切，不要轻易走这一步。
由于分库分表谁都会干，关键是拆完以后怎么办。目前，市面上尚未彻底开源免费的方案，能让你一劳永逸地解决数据库拆分问题。

分库分表：
    一、横向拆分；
    二、纵向拆分；
    三、分布式数据库访问层；
    四、数据库中间件（代理）；

 

 

网站架构总结

 

上面讲述了在网站业务发展的不一样阶段，会面临不一样的问题，针对不一样的问题，会选择不一样的架构。大型网站架构就是在不一样阶段时解决不一样问题的过程当中慢慢演进来的。

 

经验之谈： 一、一切以解决业务目标为首要任务； 二、没有以业务为目标的任何架构、技术，都是毫无心义的耍流氓； 三、再牛逼的架构、再牛逼的技术，不可以解决业务的问题，你也只能算是会架构、会技术的工匠，而不能算是真正意义上的架构师； 四、业务成就了技术，平台成就了人，事业成就了人，而不是相反；

 

本文思惟导图

 

以上内容仅供学习

 

参考连接：https://www.jianshu.com/p/9197d8a0781b

做者：猿码道