读书_大型网站技术架构01_李智慧

豆瓣评分7.9还是不错的,并且目录上看也适合自己。个人技术栈比较杂,各方面都会一点,里面涉及的大多数技术或软件工具也都用过(redis,mongo,消息队列等),所以阅读起来还是比较轻松的。
读大学时读书也爱记笔记(主要出于方便复习的角度),现在纸质笔记携带不便,用电子笔记更合适些。

1 大型网站架构演化

第一章主要是大型网站架构进化历程,我们更多的是关注最终结论(现代大型网站典型架构)。
最“复杂”,最“全能”的架构如下

为了方便后续学习,将其标号

01,02,静态资源的处理
01和02都是为了加速静态资源的处理,理想情况下希望cdn缓存绝大多数静态资源(变动频率低的)。

03,负载均衡
相关:会话管理。需要关注session是统一管理还是分配到集群中的某台机器。如果是某台那就可能有会话粘滞,如果随机一台,就可能需要需要会话统一管理。

08,09非结构话数据库
典型场景是搜索服务

10,分布式缓存
优先使用本地缓存,一般不会一下子就用到分布式缓存,当然有些系统会直接使用分布式缓存。将一些配置信息、热点数据缓存本地,降低数据库压力。
相关:缓存穿透、雪崩,缓存失效,一致性hash。

11,分布式文件系统
处理一些小文件存储。数据库数据量大了后一般都会对业务分库,服务器独立部署。

12,数据库分离
读写分离,主备-分离
相关:分离后数据的一致性。

架构并非越强大越好,而是越合适越好,淘宝一代是用lamp架出来的(嗯,php是最好的语言),为啥?便宜,快捷,够用。
如果淘宝第一天就采用现在的架构,估计3-5年系统出来了,投资人跑路了,黄了,
况且系统本身复杂度-性能也是非线性的,可能性能提升50%,目前架构改改能搞定,再提升更多,就需要将目前推倒重来换架构
而且“大系统”本身负责度就很高,从开发-测试-发布-维护等一系列步骤需要的成本都会高出很多。
简单来说,架构要和业务匹配,适当的冗余,但没必要为1万用户的系统,设计支持100万用户的架构。

2 大型网站架构模式

从以下角度描述各技术手段

1
2
3
概念:
目的:
举例:

2.1.1 分层

概念:将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统。
目的:

  1. 便于分工合作开发和维护;
  2. 各层独立,只要维持调用接口不变,各层可根据具体问题独立演化发展而无需其他层必须相应调整;
  3. 物理部署上,三层结构可部署在同一物理机器上,随着网站业务发展,必然要分离部署,其三层结构分别部署在不同服务器,使网站拥有更多计算资源应对更多用户访问。
    举例:目前主流的mvc架构,网络的7层结构

2.1.2 分割

概念:从纵向方面对软件进行切分,将不同功能和服务分割开来,包装成高内聚低耦合的模块单元。
目的:

  1. 有助于软件开发和维护;
  2. 便于不同模块的分布式部署,提供网站的并发处理能力和功能扩展能力。

举例:

  1. 在应用层,按业务分割为购物、论坛、搜索、广告不同的应用,独立团队负责,部署在不同服务器;
  2. 同一应用内部,如果规模庞大业务复杂,会继续分割,比如购物业务分割为机票酒店业务、3C业务、小商品业务等更细小的粒度。
    其他:微服务,多站点的登录中心,前台网站和admin管理后台

2.1.3 分布式(分层和分割的目的)

如果分层和分割后系统还在单机上运行,那么分层和分割的意义就很小了,反而提升系统复杂度。提高性能最直接的方法时提升主机个数,毕竟单机的性能是非常有限的。而分层和分割就是为多机部署而准备的。
概念:分层和分割的一个主要目的是为了切分后的模块便于分布式部署,即不同模块部署在不同服务器上,通过远程调用协同工作。
目的:可使用更多的计算机完成同样的功能,计算机越多,CPU、内存、存储资源也越多,处理并发访问和数据量就越大。

缺点

  1. 分布式服务调用必须通过网络,可能会影响性能;
  2. 服务器越多,服务器宕机概率就越大;
  3. 分布式环境数据一致性非常困难,分布式事务也难以保证;
  4. 分布式导致网站依赖错综复杂,开发管理维护困难。

举例

  1. 分布式应用和服务:将分层和分割后的应用和服务模块分布式部署。
  2. 分布式静态资源:网站的静态资源如JS、CSS、Logo图片等资源独立分布式部署,并采用独立域名,即动静分离。
  3. 分布式数据和存储:大型网站需处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,此时需分布式存储。
  4. 分布式计算:严格来说,应用、服务、实时数据处理都是计算,网站除了要处理这些在线业务,还有很大一部分后台业务,包括搜索引擎的索引构建、数据仓库的数据分析统计等。

2.1.4 集群

不明白为何单列,个人理解和分布式一个意思,难不成单机用docker做成分布式么?意义何在?
使用分布式必然导致我们面对的是服务器集群

2.1.5 缓存

概念:将数据存放在距离计算最近的位置。这里的“计算”可能是cpu,也可能是负责运算的主机
目的:加快处理速度。
举例: CDN(离用户近的位置),本地缓存(离cpu近的位置),分布式缓存(相对数据库,离cpu更近)。

2.1.6 异步

概念:

  1. 单一服务器内部可通过多线程共享内部队列方式实现异步,业务操作前面的线程将输出写入队列,后面的线程从队列读取数据处理。
  2. 分布式系统中,多个服务器集群通过分布式消息队列实现异步。

目的:

  1. 提高系统可用性:消费者服务器发生故障,数据会在消息队列服务器存储堆积,生产服务器可以继续处理业务请求,系统整体表现无故障。消费者服务器恢复正常后,继续处理消息队列中的数据。
  2. 加快网站响应速度:业务处理前端的生产着服务器将数据写入消息队列,无需等待消费者服务器处理就可以返回,响应延迟减少。
  3. 消除并发访问高峰:用户访问网站是随机的,虽然存在高峰和低谷,但突发事件(促销活动、微博热点事件)会造成网站并发访问突然增大。使用消息队列将突然增加的访问请求数据放入消息队列,等待消费者服务器依次处理,减小网站负载压力。
  4. 解耦,提升扩展性。
  5. 缺点:消费者服务器处理(如业务校验、写数据库)失败,以订单提交为例,可在成功提交后Email或短信通知用户订单成功,避免交易纠纷。

举例:多级流水线,消息队列(实现异步的手段)

2.1.7 冗余

分布式中,一旦单机有损坏,那么有可能导致整个系统无法正确提供服务。(为啥不分布式就没这个问题呢?这是个概率问题,机器越多,所有机器都不出问题的概率就越低,比如抽取100万电脑,全部没问题概率基本为0)。为弥补分布式的缺陷,就采用冗余,作为保险机制。
概念: 任何服务都必须部署至少两台服务器构成的一个集群。
目的:实现服务高可用。
举例:

  1. 冷备份:定期备份,存档保存。
  2. 热备份:主从分离,实时同步。

2.1.8 自动化

机器不受情绪干扰,如果相关流程步骤考虑周到,机器负责执行,出错概率比人工操作低
目的:减少人为干预,减少故障。
举例:自动化测试,自动化部署,自动化发布,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级(网站遇到访问高峰,超出网站最大处理能力时,为保证整个网站安全可用,会自动化拒绝部分请求及关闭部分不重要服务将系统负载降至安全水平。)

2.1.9 安全

范围很大,伴随应用开发全周期,个人并非这个领域的,只熟悉一些基础知识。
目的:减少数据泄露或篡改,或不符合业务逻辑的非法操作的风险。
举例:身份认证(密码和手机校验码),通讯加密(登录、交易等操作需要对网络通信加密),防止机器人程序攻击网站,使用验证码识别

3 大型网站核心架构要素

同一个要素对于应用中的不同角色(应用服务器,文件服务器,关系数据库,非关系数据库,分布式缓存等),其要求也是不同的。

3.1 性能

1
2
3
4
5
6
7
8
浏览器端:通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。
CDN:将网站静态内容分发至离用户最近的网络服务商机房,使用户通过最短访问路径获取数据。
反向代理服务器:缓存热点文件,加快请求响应速度,减轻应用服务器负载压力。
应用服务器端:本地缓存和分布式缓存,通过缓存在内存中的热点数据处理用户请求,加快请求处理过程,减轻数据库负载压力
异步操作:将用户请求发送至消息队列等待后续任务处理,而当前请求直接返回响应给客户。
集群:将多台服务器组成一个集群共同对外服务,提高整体处理能力,改善性能。
代码层面:通过使用多线程、改善内存管理等手段优化性能。
数据库服务器端:索引、缓存、SQL优化等性能优化手段已经比较成熟,NoSQL数据库通过优化数据模型、存储结构、伸缩性等手段在性能方面的优势日趋明显。

3.2 可用性

高可用设计的目标就是当服务器宕机的时候,服务或者应用依然可用
网站高可用的主要手段是冗余,应用部署在多台服务器上同时提供访问,数据存储在多台服务器上互相备份,任何一台服务器宕机都不会影响应用的整体可用,也不会导致数据丢失。

对应用服务器:多台服务器通过负载均衡设备组成一个集群共同对外提供服务,任何一台服务器宕机,只需要把请求切换到其他服务器就可以实现应用的高可用,但是一个前提条件是应用服务器上不能保存请求的会话信息。
对存储服务器:需要对数据进行实时备份,当服务器宕机时需要将数据访问转移到可用的服务器上,并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。
对软件质量保证:通过预发布验证、自动化测试、自动化测试、自动化发布、灰度发布等手段,减少将故障引入线上环境的可能,避免故障范围扩大。

3.3 伸缩性

伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可用多台服务器构建集群,是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

对于应用服务器集群:只要服务器上不保存数据,所有的服务器都是对等的,通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
对于缓存服务器集群:加入新的服务器可能会导致缓存路由失效,进而导致集群中大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新加载,但是如果应用已经严重依赖缓存,可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
对于关系数据库:虽然支持数据复制,主从热备等机制,但是很难做到大规模集群的可伸缩性,因此关系数据库的集群伸缩性方案必须在数据库之外实现,通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
对于NoSQL数据库:为海量数据而生,因此其对伸缩性的支持通常非常好,可以做到在较少运维参与的情况下实现集群规模的线性伸缩。

3.4 扩展性

网站的扩展性架构直接关注网站的功能需求
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线新产品。

事件驱动架构:通常利用消息队列实现,将用户请求和其他业务时间构造成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来,可以透明地增加新的消息生产者任务或者新的消息消费者任务。
分布式服务:将业务和可复用服务分离开,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。
开放平台接口:吸引第三方开发者,调用网站服务,使用网站数据开发周边产品,扩展网站业务。

3.5 安全性

网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。

3.6 小结

参考

《大型网站技术架构:核心原理与案例分析》:https://blog.csdn.net/hubinqiang/article/details/51060268#t28
《大型网站技术架构:核心原理与案例分析》笔记:https://www.cnblogs.com/netoxi/p/7258895.html
读-李智慧-大型网站技术架构:核心原理与案例分析:https://blog.csdn.net/xiaoxufox/article/details/53176455#t15

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×