大型网站架构设计

网站架构的演化

1，原始时代，一台服务器解决所有，经典的LAMP，廉价服务器+开源软件，网站就建起来了。

→ 等到访问量越来越大，数据存储空间吃紧了，所以。。。

2，使用三台服务器，应用，文件，数据库分开。应用服务器加CPU，文件服务器加大容量硬盘，数据库服务器用更贵更快的硬盘。

→ 80%的访问集中在20%的数据上，成为瓶颈

3，应用服务器加本地缓存。

→ 本地缓存和应用争内存

4，加远程独立服务器放缓存，再不行上分布式缓存服务器，要多大有多大。

→单台应用服务器应对请求数量有限，限制了并发能力

5，使用应用服务器集群，可伸缩性大大增强，再多用户都不怕。

→用户操作频繁，高频率的写操作让数据库不堪重负

6，数据库读写分离，配置主从数据库，读从从库读，写就写到主库，利用主从复制让数据一致

→网站内容越来越丰富，响应时间变长

7，上CDN服务，静态数据或者不频繁更新的数据都到CDN。再利用反向代理，选择距离用户最近响应最快的应用服务器，大大加快响应时间。

→写数据操作量级上来了，数据服务器真的又撑不住了

8.1有钱，上分布式文件系统和分布式数据库系统，还慢就继续加机器，总有快的时候。省心省力

8.2没钱，花点心思，根据业务对数据库进行拆分，将不同细分业务数据放到不同的数据服务器上，重点数据用更好的服务器。

→数据量大，检索和生成报表巨慢

9，使用NoSQL放需要检索的数据，减轻原来数据库服务器压力

→业务复杂，技术开发难度提高

10，业务拆分，根据不同的产品线拆分技术开发，看起来是一个网站，其实是不同的应用来共同提供数据的

→业务拆分粒度越来越小，服务部署维护困难

11，分布式服务，统一运维

架构模式

模式，描述了一个不断重复发生的问题和该问题解决方案的核心。这样，你就能一次次的使用该方案而不必做重复工作。

网站架构要解决的问题，就这几种:

• 高性能。就是要快！

• 高可用。7*24在线可用，挂了就不好了。

• 易伸缩。能随访问量，数据处理量的大小。进行扩容降容，不再门庭若市时候奔溃，不在人去楼空时浪费钱。

• 可扩展。师傅师傅大师兄又加需求了！好的架构，要随业务的发展，无痛加功能加服务。

• 安全。不安全，以上都是白搭。
  以上这些问题重复的出现，也就形成了解决的模式。

常见的模式:

1.分层。横向切割。应用层靠近用户，负责具体业务和页面展示，也就是常说的后台和前端那部分，现在都是前后端分离了，也是分层的一种方法。服务器提供具体服务支持，比如订单结算，购物车服务等，我现在工作大概就是在这一层，所以不要再问我后台后端差别了啊啊啊。数据层，最后面，提供数据存储的。

2.分割。纵向切割。将不同业务进行分割，例如淘宝，购物车，搜索，广告分割成不同的应用，由独立团队进行负责。

3.分布式。不同应用放不同物理机子，分布式部署可以对不同的应用服务做到资源的有效分配。

4.集群。多台服务器部署相同的应用，通过负载均衡对外提供服务，集群再提高更好的并发特性的同时，也能提供系统的可用性，一台挂了还有一台嘛。

5.缓存。CDN，redis等等。缓存主要是两个难点，怎样提供缓存命中率和设置过期时间避免脏读。

6.异步。这一块是重点，异步架构是典型的生产者消费者模式，应用使用队列进行消息传递而不直接互相调用。好处有二，可用性提高，如果后面的应用挂了，前面的应用还能继续接收用户请求，数据堆入队列，等挂了的应用重启继续消费队列就可以了。消除访问波峰，突然的一波访问，如果没有异步处理，后端压力会骤增，很可能就崩了，异步处理能将消息放进消息队列，后端依次处理，就不会有太大问题。

7.冗余。服务器随时会挂，多备一台服务器，数据多做一份备份，总是好事。虽然有点费钱。

8.自动化。发布过程自动化，人为操作很容易出错，当然，需要自动发布系统足够好用。

9.安全。加密，验证码，风险控制。

异步的问题

和人不同的是，网站系统，任何可以晚点再做的事情都应该晚点再做。

一般就是使用消息队列将调用异步化，一个应用接一个应用的处理数据，上游处理完了丢到下游，上游无需下游立即甚至压根不用下游进行反馈。

消息队列的应用，使系统的灵活性大大提高，起到很好的削峰作用。前面的应用将短时间内大量的请求存入消息队列，推迟处理时间，使到后面吃大量内存CPU的应用不至于被压垮。固定的消费速率也使数据库服务器的并发数得到控制。

但是，异步也会带来很多麻烦的事情。

由于数据操作被异步化了，所以很难确定数据究竟处理完了没有，也很难保障数据的一致性，前端应用认为处理完了，后端其实还没好，就会出现很多问题，导致数据不一致，处理结果出现异常。这经常需要额外的同步操作来进行核实数据，带来额外的开销。

另一个问题是，异步会导致数据的更新不及时，当然，这是异步的目的，同样也是缺点，看不同的场合。比如每日卖家报表，推迟个几分钟再统计出来没有任何问题，但是像秒杀系统，推广限额系统，就不能容忍数据统计延迟。在应用了异步处理的架构里，这些需求也就都需要额外处理，提供系统的复杂性。

不是任何网站都需要异步化的，也不是异步架构里每个环节都需要异步化的。技术用到正确的地方才是好的技术。