关键词：
文章大纲
一、演变过程思路图
二、何为大型网站
三、架构体系演进
四、架构总结
五、参考文章
一、演变过程思路图
二、何为大型网站
1. 大型网站特性
既然说的是大型网站架构，那么架构的背后自然是解决人因面对大型网站特性而带来的问题。这样可以先给大家说下大型网站的特性，这些特性带来的问题就是人要解决的问题：
（1）高并发、大流量：PV 量巨大；
（2）高可用：7*24 小时不间断服务；
（3）海量数据：文件数目分分钟 xxTB；
（4）用户分布广泛，网络情况复杂：网络运营商；
（5）安全环境恶劣：黑客的攻击；
（6）需求快速变更，发布频繁：快速适应市场，满足用户需求；
（7）渐进式发展：慢慢地运营出大型网站；
2. 大型网站架构理解
大型网站架构的概念对于每一个开发者来说很笼统、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情况下我们只是负责架构中的一小块内容，所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来，站在宏观的角度，从整体到细节实现来认识大型网站架构。
那么从宏观的角度怎么去认识大型网站架构呢？正如前面几篇《细品架构系列》所描述对架构的认识，按照问题识别—>概念认知—>架构切分的思路，来分析大型网站架构的诞生：
- 问题识别：当前什么问题、谁的问题、问题边界；
- 概念认知：通过分析问题，会产生哪些概念，统一概念认知，达成沟通交流规范；
- 架构切分：根据概念来解决问题，如何架构切分，产生哪些架构，提出具体解决方案；
PS：上面的三个步骤具体如何识别、认知、切分，请详细参考前面几篇《细品架构系列》文章，可能使你会对架构有重新的认识。
在进行分析大型网站架构的演进之路前，首先我们要明确的两个价值观：
- 核心价值：随网站所需灵活应对；大型网站不是从无到有一步就搭建好一个大型网站，而是能够伴随小型网站业务的渐进发展，慢慢地演化成一个大型网站；
- 驱动力量：网站的业务发展— 业务成就了技术，事业成就了人，而不是相反；
还有，大型网站架构演进必须避免的几个误区：
- 一味追随大公司的解决方案；
- 为了技术而技术-->常见问题；
- 企图用技术解决所有问题：技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决；
三、架构体系演进
1. 单机时代
草根时期，快速开发网站并上线。当然，通常只是先试水，用户规模也没有形成，经济能力和投入也非常有限。应用程序、数据库、文件等所有资源都集中在一台 Server上，典型案例：基于 LAMP 架构的 PHP 网站；
优点：简单、快速迭代达成业务目标；
缺点：存在单点、谈不上高可用；
技术点：应用设计要保证可扩展；
2. 缓存出场
有一定的业务量和用户规模了，想提升网站速度，于是，缓存出场了。
优点：简单有效、方便维护；
缺点：存在单点、谈不上高可用；
技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存；
如上图，缓存可以分为：
- 页面缓存：客户端缓存，减少对网站的访问；
- 本地缓存：访问速度快，但数据量有限，减少对DB查询；
- 远程缓存：远程访问，可以集群，因此容量不受限制；
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. 如何保证高可用
在做扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（也就是我们通常听别人吹牛时说的SLA、几个9）。如何保证真正“高可用”，也是个难题。
对关键应用/服务，做集群冗余负载，这也是保证高可用比较常用的手段：
- 文件系统、数据库系统集群；
- 静态内容服务器集群；
- CDN服务器集群；
- 反向代理服务器集群；
- 负载均衡调度器集群；
- 分布式NoSQL服务器集群；
- 搜索引擎服务器集群；
- 分布式缓存服务器集群；
- 分布式Session服务器集群；
优点：集群负载，保证高可用；
缺点：数据一致性、数据有状态问题；
技术点：负载调度器、集群方案；
截止目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么需要大面积的修改代码。
如果上面那些手段都用光了，还是支撑不住怎么办？不停的加机器也不是办法啊？
11. 应用垂直拆分
随着业务越来越复杂，网站的功能越来越多，虽然部署层面是采用的集群，但是应用程序架构层面还是“集中式”的，这样会导致很多耦合，不便于开发、维护，而且容易“一荣俱损”。所以，通常会把网站拆分出不同的子站点来单独宿主。
通过分而治之的手段将整个网站业务分成不同的产品线，如首页、商铺、订单、卖家、买家等 拆分成不同的产品线，分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系，也可以通过消息队列进行数据分发。
优点：降低耦合、分压；
缺点：应用架构复杂；
技术点：业务抽取拆分；
12. 业务垂直分库
应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作。
优点：降低DB耦合、分压DB；
缺点：数据访问模块复杂；
技术点：业务抽取拆分；
13. 分布式服务化
拆分应用和DB之后，其实还是会有很多问题。不同的站点，里面可能会有相同逻辑和功能的代码。当然，对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用，但是这种强依赖也很容易造成一些问题（版本问题、依赖关系等处理起来非常麻烦）。
既然每一个应用系统都需要执行许多相通的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。这样，传说中的SOA的价值就得到体现了。
优点：服务统一管理，提供重用度；
缺点：应用架构更复杂；
技术点：业务抽取拆分、服务化技术方案；
14. 消息队列
应用、服务之间还是会出现一些依赖问题，这时候，高吞吐量的解耦利器出现了。
优点：提高吞吐量、应用、服务之间解耦；
缺点：存在消息消费延迟问题；
技术点：消息队列技术方案；
15. 分库分表
最后，再介绍一个大型互联网公司都用的绝技--分库分表。个人经验，不是业务发展和各方面非常迫切，不要轻易走这一步。
因为分库分表谁都会干，关键是拆完之后怎么办。目前，市面上还没有完全开源免费的方案，能让你一劳永逸地解决数据库拆分问题。
分库分表：
横向拆分；
纵向拆分；
分布式数据库访问层；
数据库中间件（代理）；
四、架构总结
上面讲述了在网站业务发展的不同阶段，会面临不同的问题，针对不同的问题，会选择不同的架构。大型网站架构就是在不同阶段时解决不同问题的过程中慢慢演进来的。
最后几句话，送给有缘的你：
一切以解决业务目标为首要任务；
没有以业务为目标的任何架构、技术，都是毫无意义的耍流氓；
再牛逼的架构、再牛逼的技术，不能够解决业务的问题，你也只能算是会架构、会技术的工匠，而不能算是真正意义上的架构师；
业务成就了技术，平台成就了人，事业成就了人，而不是相反；
五、参考文章
https://www.jianshu.com/p/9197d8a0781b
大型网站架构演变
...术发展历程，剖析大型网站技术架构模式，深入分析大型互联网架构设计。这篇文章我们只关注架构的演变历程。通过电商业务为例，该系统的功能有用户模块【用户注册和管理】、商品模块【商品展示和管理】、交易模块【创... 查看详情
高并发大访问量架构设计演进之路归纳总结
...色的编程能力：优秀的代码深刻领悟主流技术产品模式；互联网架构的关键技术：缓存，异步，分布互联网架构的核心要素：性能，可用，安全架构设计方案：系统，框架，数据库架构师的成长：搞定问题的攻略大型分布式架构... 查看详情
中型创业公司的技术管理案例
...理,产品管理,团队建设有参考作用,您可能感兴趣的文章:互联网电商购物车架构演变案例互联网业务场景下消息队列架构互联网高效研发团队管理演进之一消息系统架构设计演进互联网电商搜索架构演化之一企业信息化与软件工... 查看详情
架构学习分享：软件架构设计的三大原则
...原则。合适原则：原则宣言：“合适优于业界领先”现在互联网时代，技术的迭代非常快。很多架 查看详情
dubbo项目架构演变过程
...务架构架构演变过程dubbo是一款高性能的javarpn框架。随着互联网的发展，用户群体逐渐壮大，网站的流量成倍增长，常规的单体架构已无法满足请求压力暴增和业务的快速迭代，架构的变化势在必行。单体架构单... 查看详情
dubbo项目架构演变过程
...务架构架构演变过程dubbo是一款高性能的javarpn框架。随着互联网的发展，用户群体逐渐壮大，网站的流量成倍增长，常规的单体架构已无法满足请求压力暴增和业务的快速迭代，架构的变化势在必行。单体架构单... 查看详情
ued视觉交互设计与流程介绍
...－习惯发生范围变更前端性能核对表Checklist-2018大型电商互联网性能优化案例国际化环境下系统架构演化微服务架构设计视频直播平台的系统架构演化微服务与Docker介绍Docker与CI持续集成/CD互联网电商购物车架构演变案例互联网... 查看详情
企业架构的演变
...，支持企业方方面面的经营运作。不论是传统企业，还是互联网公司，发展到一定阶段，都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险，而混乱的、不合理的... 查看详情
智能系统中间件性能测试
...－习惯发生范围变更前端性能核对表Checklist-2018大型电商互联网性能优化案例国际化环境下系统架构演化微服务架构设计视频直播平台的系统架构演化微服务与Docker介绍Docker与CI持续集成/CD互联网电商购物车架构演变案例互联网... 查看详情
软件开发团队管理与项目经理
...台的系统架构演化微服务与Docker介绍Docker与CI持续集成/CD互联网电商购物车架构演变案例互联网业务场景下消息队列架构互联网高效研 查看详情
整理软件工程篇
...略如何设计一个网关？来自天猫精灵的架构供你参考大型互联网架构演化简史软件交付的演进历程技术人如何通过了解业务，获取晋升机会？设计模式大杂烩Web演变模式前端和后端是如何交互的优秀的API接口都是如何设计的接口... 查看详情
系分&架构-软件架构设计
...架构风格闭环控制架构（过程控制）C2架构风格富互联网RIA架构MVC架构风格MVP架构风格MVVM架构风格软件架构风格-相关题目基于/面向服务的（SOA）SOA特点SOA的实现方式-WebServiceSOA的实现方式-服务注册表SOA的实现方... 查看详情
微服务架构的前世今生：技术架构演变
...一篇我们讲了微服务架构的前世今生（一）：传统行业向互联网行业的转型，本文接着3讲述微服务技术架构演变。下图表示从单体应用逐渐转变为微服务应用。一、单一应用架构通俗地讲，“单体应用（monolithapplication）&rdquo... 查看详情
dubbo项目架构演变过程
...务架构架构演变过程dubbo是一款高性能的javarpn框架。随着互联网的发展，用户群体逐渐壮大，网站的流量成倍增长，常规的单体架构已无法满足请求压力暴增和业务的快速迭代，架构的变化势在必行。单体架构单... 查看详情
2022全新互联网java架构技术体系路线，已拿offer
前言：Java是现阶段中国互联网公司中，覆盖度最广的研发语言，掌握了Java技术体系，不管在成熟的大公司，快速发展的公司，还是创业阶段的公司，都能有立足之地。有不少朋友问，成为Java架构... 查看详情
[架构之路-94]：《软件架构设计：程序员向架构师转型必备》-4-软件架构设计的通用过程
...构设计之前，需要根据部分关键性需要，确定好技术方向，并进行粗略的概念架构设计。概率架构，不关注详细的功能模块和模块之间的接口，它关注的是宏观层面的模块划分以及采用什么样的技术方案选型... 查看详情
[架构之路-94]：《软件架构设计：程序员向架构师转型必备》-4-软件架构设计的通用过程
...构设计之前，需要根据部分关键性需要，确定好技术方向，并进行粗略的概念架构设计。概率架构，不关注详细的功能模块和模块之间的接口，它关注的是宏观层面的模块划分以及采用什么样的技术方案选型... 查看详情
分布式架构进阶:如何应对高并发的用户请求
本文已收录GitHub，更有互联网大厂面试真题，面试攻略，高效学习资料等互联网应用以及云计算的普及，使得架构设计和软件技术的关注点从如何实现复杂的业务逻辑，转变为如何满足大量用户的高并发访问请求。一个简单的计... 查看详情