创业之路

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

CDN部署在网络提供商的机房；

反向代理则部署在网站的中心机房；

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

使用反向代理和 CDN 加速网站响应

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

使用NoSQL和搜索引擎
到这里，已经基本做到了DB层面和应用层面的横向扩展了，可以开始关注一些其它方面，例如：站内搜索的精准度，对DB的依赖，开始引入全文索引、NoSQL。

NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

使用NoSQL和搜索引擎

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

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

如何保证高可用
在做扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（也就是我们通常听别人吹牛时说的SLA、几个9）。如何保证真正“高可用”，也是个难题。

对关键应用/服务，做集群冗余负载，这也是保证高可用比较常用的手段：

文件系统、数据库系统集群；

静态内容服务器集群；

CDN服务器集群；

反向代理服务器集群；

负载均衡调度器集群；

分布式NoSQL服务器集群；

搜索引擎服务器集群；

分布式缓存服务器集群；

分布式Session服务器集群；

使用集群冗余负载 保证高可用

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

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

如果上面那些手段都用光了，还是支撑不住怎么办？不停的加机器也不是办法啊？

应用垂直拆分
随着业务越来越复杂，网站的功能越来越多，虽然部署层面是采用的集群，但是应用程序架构层面还是“集中式”的，这样会导致很多耦合，不便于开发、维护，而且容易“一荣俱损”。所以，通常会把网站拆分出不同的子站点来单独宿主。

通过分而治之的手段将整个网站业务分成不同的产品线，如首页、商铺、订单、卖家、买家等拆分成不同的产品线，分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系，也可以通过消息队列进行数据分发。

应用垂直拆分（分压，解耦）

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

业务垂直分库
应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作。

业务垂直分库 分压 解耦

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

分布式服务化
拆分应用和DB之后，其实还是会有很多问题。不同的站点，里面可能会有相同逻辑和功能的代码。当然，对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用，但是这种强依赖也很容易造成一些问题（版本问题、依赖关系等处理起来非常麻烦）。

既然每一个应用系统都需要执行许多相通的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。这样，传说中的SOA的价值就得到体现了。

分布式服务化（解耦，去重复）

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

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

消息队列（服务间异步解耦 高吞吐量）

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

分库分表
*后，再介绍一个大型互联网公司都用的绝技–分库分表。个人经验，不是业务发展和各方面非常迫切，不要轻易走这一步。

因为分库分表谁都会干，关键是拆完之后怎么办。目前，市面上还没有完全开源免费的方案，能让你一劳永逸地解决数据库拆分问题。

分库分表：

横向拆分；

纵向拆分；

分布式数据库访问层；

数据库中间件（代理）；

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

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以邮件至 chaofa_vip@126.com