大型网站的架构设计，涉及到的面非常多，并不像大家想象的那样，就是一个网站这么简单，今天抛砖引玉，希望大家正确看待架构设计。
什么是架构设计的本质？
任何系统，自然情况下，都是从有序到无序，这是有科学依据的， 按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”来保证自身有序，继续生存。
同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。
架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。
分的过程是把系统拆分为各个子系统/模块/组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。
拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。
架构设计的能力
我们要想做好一个架构的话需要哪些能力？我觉得最重要的是架构师一个最重要的能力就是你要有分解能力。
第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。
第二， 分类能力。做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。
第三， 算法（性能），它的价值体现在提升系统的性能，所有性能的提升，最终都会落到CPU，内存，IO和网络这4大块上。
架构设计的演变过程
架构设计的演变，其实就要清楚整个大型网站技术架构的演变历程，知道每个阶段的瓶颈在哪里，以及对应的解决方案。
很多公司都是小做到大，特别是创业公司，如果一步步发展起来，网站架构演变都会经历这些步骤，请重点注意顺序。
架构演变第一步：物理分离webserver和数据库
架构演变第二步：增加页面缓存
架构演变第三步：增加页面片段缓存
架构演变第四步：数据缓存
架构演变第五步： 增加webserver(集群)
架构演变第六步：分库(首先考虑)
架构演变第七步：分表、DAL和分布式缓存
架构演变第八步：增加更多的webserver
架构演变第九步：数据读写分离和廉价存储方案
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
架构知识体系
随着互联网技术迅速发展和演变，不断改变的商业化应用系统越来越复杂，由单一的应用架构到垂直的应用架构，但还是面临的扩容的问题。
流量分散在各个系统中，虽然体积可控，但对开发人员和维护人员带来极麻烦。此时，将核心的业务单独提炼出来作为单独的系统对外提供服务。达成业务之间复用，系统也将演变成分布式系统架构。
大型网站最终都会走向大型分布式业务场景
分层：横向分层：应用层，服务层，数据层
分割：纵向分割：拆分功能和服务
分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
集群：提高并发和可用性
缓存：优化系统性能
cdn
方向代理访问资源
本地缓存
分布式缓存
异步：降低系统的耦合性
冗余：冷备和热备，保证系统的可用性
自动化：发布，测试，部署，监控，报警，失效转移，故障恢复
安全等。
分布式缓存
高并发环境下，大量的读写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提高系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。由于单台机器的内存资源以及承载能力有限，并且，如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此，才催生出了分布式缓存。
分布式缓存系统
memcached ,redis，动态、静态数据的缓存，这里会涉及到：一致性hash算法、分布式session、数据复制多份、单台缓存失效、集群间能够自动复制和备份等知识点。
CDN
全称:Content Delivery Network或Content Ddistribute Network，即内容分发网络基本。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
现在大型互联网公司都建立由属于自己的CDN基站，也有第三方专注于CDN的基站等。
主要特点：
1、本地Cache加速，提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性
2、镜像服务消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。
3、远程加速 远程访问用户根据DNS负载均衡技术 智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度
4、带宽优化 自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。
5、集群抗攻击 广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量 。
说了这么多，你也可以理解为自动分发的缓存系统，把图片等消耗资源的都从CDN进行访问。
持久化储存
Hbase、MySQL、Redis传统的IOE方案： IBM小型机Oracle数据库 EMC持久储存成本很高。
以后会涉及到廉价存储方案(小型机太贵了)，这块以后我会讲到。
数据库拆分
一般先分库，如果分库后查询仍然慢，于是按照分库的思想开始做分表的工作数据库采用分布式数据库（所有节点的数据加起来才算是整体数据），文件系统采用分布式文件系统任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
比如淘宝中期开始的数据库端按照业务垂直拆分：按照业务交易数据库、用户数据库、商品数据库、店铺数据库等进行拆分。
还有就是水平扩展，分库分表，再结合读写分离一起。当然，分库分表需要涉及到对应的SQL路由规则主库备库等，淘宝设计了一套TDDL来解决这些问题，应用端只需配置对应的规则即可，对应用端的没有任何侵入的设计。
消息系统
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。
消息系统使用场景
典型的 异步处理，应用解耦，流量削锋和消息通讯四个场景。
除了以上还要设计运维(掌握分布式并行计算、报表、监控技术以及规则策略)，安全、运营、服务、存储、业务拆分、机房容灾等等，要做好一个大型的网站真的很不容易。
/images/layermodel.jp)
