“
大型网站的架构设计，涉及到的面非常多，并不像大家想象的那样，就是一个网站这么简单，今天抛砖引玉，希望能给想从事互联网行业的同学一点初步的概念。
架构设计，其实就要清楚整个大型网站技术架构的演变历程，知道每个阶段的瓶颈在哪里，以及对应的解决方案。很多公司都是小做到大，特别是创业公司，如果一步步发展起来，网站架构演变都会经历这些步骤，请重点注意顺序。
大型网站架构演变过程
架构演变第一步：物理分离webserver和数据库
架构演变第二步：增加页面缓存
架构演变第三步：增加页面片段缓存
架构演变第四步：数据缓存
架构演变第五步： 增加webserver（集群）
架构演变第六步：分库（首先考虑）
架构演变第七步：分表、DAL和分布式缓存
架构演变第八步：增加更多的webserver
架构演变第九步：数据读写分离和廉价存储方案
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
由于篇幅的关系，今天不重点讲如何一步步演变的历程，我们倒序来查看，先看森林，再看树木。
大型分布式应用架构组件
分布式缓存
高并发环境下，大量的读写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提高系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。由于单台机器的内存资源以及承载能力有限，并且，如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此，才催生出了分布式缓存。
分布式缓存系统
memcached ,redis，动态、静态数据的缓存，这里会涉及到：一致性hash算法、分布式session、数据复制多份、单台缓存失效、集群间能够自动复制和备份等知识点。
CDN
全称:Content Delivery Network或Content Ddistribute Network，即内容分发网络基本。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
现在大型互联网公司都建立由属于自己的CDN基站，也有第三方专注于CDN的基站等。
持久化储存
具体说就是以IBM为代表的主机、以ORACLE为代表的关系型数据库，以及以EMC为代表的高端存储设备，被新型的云计算技术所替换，也就是我们常说的“云化”，也就是廉价存储方案。
IBM的产品，在我国的金融行业中占据着绝对的优势，Oracle的数据库，在电信、证券行业占着相当大的份额，EMC的存储，在银行、电信、证券等垄断行业，都占据着较大的份额，要知道，EMC是全球最大的存储公司。
由于互联网技术发展日新月异，扩展速度十分迅速，这是传统的电信、金融、证券、保险、电力等行业所不能比的。因此互联网企业的后台架构，需要具备很强的可扩展性。比如，假设一个网站，今年的活跃用户数量只有10万，明天就有可能上升到1000多万，这就需要后台架构具有很强的扩展性，可以根据用户的数量进行灵活的扩展。
所以才有了阿里从2008年开始的轰轰烈烈的去IOE事件。
数据库拆分
一般先分库，如果分库后查询仍然慢，于是按照分库的思想开始做分表的工作数据库采用分布式数据库（所有节点的数据加起来才算是整体数据），文件系统采用分布式文件系统任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
比如淘宝中期开始的数据库端按照业务垂直拆分：按照业务交易数据库、用户数据库、商品数据库、店铺数据库等进行拆分。
还有就是水平扩展，分库分表，再结合读写分离一起。当然，分库分表需要涉及到对应的SQL路由规则主库备库等，淘宝设计了一套TDDL来解决这些问题，应用端只需配置对应的规则即可，对应用端的没有任何侵入的设计。
消息系统
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。
消息系统使用场景
典型的异步处理，应用解耦，流量削锋和消息通讯四个场景。
除了以上还要设计运维（掌握分布式并行计算、报表、监控技术以及规则策略），安全、运营、服务、存储、业务拆分、机房容灾等等，要做好一个大型的网站真的很不容易。
