前言
時至今日，大型网站的架构演化方案已经非常成熟，各种技术方案也逐渐产品化，许多大型网站已经不需要再经历大型网站经历过的架构演化之路就可以逐步发展壮大， 因为现在越来越多的网站从建立之初就是搭建在大型网站提供的云计算服务基础至善，所需要的一切技术资源: 计算，存储，网络，都可以按需购买，先行收缩，不需要自己 一点一点的去拼凑各种资源，综合使用各种救赎方案逐步去完善自己的网站架构了。
正因为网站技术演化过程难以重现，所以我们更应该对这个过程深入了解，理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢，直击要害
初始阶段的网站架构
在初始阶段，访问量并不大，所以应用程序、数据库、文件等所有的资源都在一台服务器上。
应用服务和数据服务分离
随着业务的发展，就会发现一台服务器抗不过来了，所以将应用服务器与数据（文件、数据库）服务器分离。
三台服务器对硬件资源的要求各不相同：
应用服务器需要更快的CPU处理大量的业务逻辑
文件服务器存储大量的文件因此需要更大的磁盘和带宽；
数据库服务器需要更快速的磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存。
分离之后，三个服务器各司其职，也方便针对性的优化。
使用缓存改善网站性能
“世界上没有什么问题是加一级缓存解决不了的，如果有那就再加一级缓存” —尼古拉斯.赵四
缓存的使用无处不在，缓存的根本目的是加快访问速度。当数据库的访问压力过大的时候，就可以考虑使用缓存了。网站使用的缓存可以分为两种: 缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。
使用应用服务器集群改善网站的并发处理能力
随着业务的发展，单个应用服务器一定会成为瓶颈，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。后面也会提到，将应用服务器设计为无状态的（没有需要保存的上下文信息），就可以通过增加机器，使用负载均衡来scale out。
数据库读写分离
即使使用了缓存，但在缓存未命中、或者缓存服务时效的情况下，还是需要访问数据库，这个时候就需要数据库的读写分离：主库提供写操作，从库提供读服务。注意，在上图中增加了一个数据访问模块，可以对应用层透明数据库的主从分离信息。
使用反向代理和CDN 加速网站晌应
CDN和反向代理其实都是缓存，区别在于CDN 部署在网络提供商的机房；而反向代理则部署在网站的中心机房。使用CDN 和反向代理的目的都是尽早返回数据给用户， 一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
使用分布式文件系统和分布式数据库系统
单个物理机的磁盘是有限的，单个关系数据库的处理能力也是有上限的，所以需要分布式文件存储与分布式数据库。当然，也需要”统一数据访问模块“，使得应用层不用关心文件、数据的具体位置。值得一提的事，关系型数据库自身并没有很好的水平扩展方案，因此一般都需要一个数据库代理层，如cobar、mycat。
使用NoSQL 和搜索引擎
web2.0的很多应用并一定适合用关系数据库存储，更加灵活的NoSql能更加方便的解决一些问题，而且NoSQL天然就支持分布式。专门的搜索引擎在提供更优质服务的同时，也大大减轻了数据库的压力。
业务拆分
将一个网站拆分成许多不同的应用， 每个应用独立部署维护。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址) ，也可以通过消息队列进行数据分发， 当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统
分布式服务
既然每一个应用系统都需要执行许多相同的业务操作， 比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。
通过服务的分布式，各个应用能更好的独立发展，实现了从依赖模块到依赖服务的过渡。将通用的公共服务独立出来，也方便做服务管控，比如对各个应用的服务请求进行监控，在高峰时期限制、关闭某些应用的访问等。
复用的功能抽离成微服务
如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。
不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，
此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱
引入企业服务总线ESB屏蔽服务接口的访问差异
通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。
如何部署
引入容器化技术实现运行环境隔离与动态服务管理
目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。
在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在3.14节之前，服务运行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被破坏）。
使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低
以云平台承载系统
系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。
所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：
IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。
至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论
最后
不要一味追随大公司的解决方案
不迷信大厂，只借鉴，不盲从，坚持自我
不要为了技术而技术
一味追求时髦的技术，脱离了业务，路只会越走越窄
不要企图用技术解决所有问题
技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决
參考:
