小谈大型网站架构设计

正确的业务架构远比正确的技术架构重要
---- 斯沃.资基索德

经验尚浅，不敢妄议大神写的《大型网站技术架构》，所以前面写成学习笔记的形式，后面会聊些思考。希望能有所帮助。

作者在阿里当过架构师，现在就职英特尔。写这本书的时候正值12306刚出来，频频奔溃。所以就写了这本书，希望分享下相关经验。前半部分细讲了网站架构的要素和解决方案，后半部分分析了淘宝维基百科等的具体案例，并且分享了如何做架构师的一些经验。对刚入门后端开发或者想深入学习架构设计，进行系统优化的同学都是不错的学习书籍。

网站架构的演化

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

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

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

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

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

→ 本地缓存和应用争内存

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构模式

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

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

1. 高性能。就是要快！
2. 高可用。7*24在线可用，挂了就不好了。
3. 易伸缩。能随访问量，数据处理量的大小。进行扩容降容，不再门庭若市时候奔溃，不在人去楼空时浪费钱。
4. 可扩展。师傅师傅大师兄又加需求了！好的架构，要随业务的发展，无痛加功能加服务。
5. 安全。不安全，以上都是白搭。

以上这些问题重复的出现，也就形成了解决的模式。常见的模式:

1. 分层。横向切割。应用层靠近用户，负责具体业务和页面展示，也就是常说的后台和前端那部分，现在都是前后端分离了，也是分层的一种方法。服务器提供具体服务支持，比如订单结算，购物车服务等，我现在工作大概就是在这一层，所以不要再问我后台后端差别了啊啊啊。数据层，最后面，提供数据存储的。
2. 分割。纵向切割。将不同业务进行分割，例如淘宝，购物车，搜索，广告分割成不同的应用，由独立团队进行负责。
3. 分布式。不同应用放不同物理机子，分布式部署可以对不同的应用服务做到资源的有效分配。
4. 集群。多台服务器部署相同的应用，通过负载均衡对外提供服务，集群再提高更好的并发特性的同时，也能提供系统的可用性，一台挂了还有一台嘛。
5. 缓存。CDN，redis等等。缓存主要是两个难点，怎样提供缓存命中率和设置过期时间避免脏读。
6. 异步。这一块是重点，异步架构是典型的生产者消费者模式，应用使用队列进行消息传递而不直接互相调用。好处有二，可用性提高，如果后面的应用挂了，前面的应用还能继续接收用户请求，数据堆入队列，等挂了的应用重启继续消费队列就可以了。消除访问波峰，突然的一波访问，如果没有异步处理，后端压力会骤增，很可能就崩了，异步处理能将消息放进消息队列，后端依次处理，就不会有太大问题。
7. 冗余。服务器随时会挂，多备一台服务器，数据多做一份备份，总是好事。虽然有点费钱。
8. 自动化。发布过程自动化，人为操作很容易出错，当然，需要自动发布系统足够好用。
9. 安全。加密，验证码，风险控制。

这本书主要就是围绕以上内容进行讲解，涉及的具体技术细节这里就不详述了，技术栈一直在变，书里介绍的有些也有可能已经过时了，但万变不离其宗，应当朝着正确的方向，不断学习。下面简单聊一些个人书后的思考。

异步的问题

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

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

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

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

从前，有一个程序员，他有一个问题，他想用异步来解决，现在两个他问题了有。

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

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

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

应用服务无状态化的价值

墨菲定律，如果一个服务有几率会挂，那它终有一天一定会挂给你看。

无状态应用服务，就是此应用不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理。部署两台服务器，请求无论被哪台处理了，结果都是一样的。这里可以联想对比下函数式编程，道理有点类似。

无状态的应用，对整体的架构设计有非常大的帮助。不用考虑宕机时会影响到业务数据处理和业务数据丢失。挂了，排查问题后重启直接继续干活，不用做任何额外的数据纠正，这让和它配合的应用都省心很多。

微服务做到无状态，需要编程经验，和对业务流程有清晰的认识，这些还要继续研究。

不要企图用技术解决所有问题

网站的价值，在于能为用户做什么，而不在于它是怎么做的。业务成就技术，而不是相反，一个快速发展的网站，才能驱动技术架构不断改进。

正确的业务架构，远比正确的技术架构重要。产品认识到位，业务逻辑清楚，对技术的开发往往起到事半功倍的作用。

前面提到的分层分隔，怎样分，和业务是密切相关的。都说程序员需要严密的逻辑思考能力，其实，产品或者业务人员同样需要严密的逻辑能力。将具体但繁杂的业务需求，发展方向，梳理清楚，1234拆分出层次分明，轻重缓急的细分业务，组成清晰的业务架构。

愿天下没有难写的代码，只有赚钱的业务，阿门。