小谈大型网站架构设计

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

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

作者在阿里当过架构师,现在就职英特尔。写这本书的时候正值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拆分出层次分明,轻重缓急的细分业务,组成清晰的业务架构。

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

你可能感兴趣的:(小谈大型网站架构设计)