读书笔记：大型网站技术架构-核心原理与案例分析

Posted 2022-10-24 talk.push

李智慧《大型网站技术架构-核心原理与案例分析》

• 性能
• 可用性
• 伸缩性
• 扩展性
• 安全性
• 总结

这本书组织的很不错，语言精练，篇幅也不长，对网站架构的要点讲的狠清楚透彻，思路清晰。主要围绕架构的五个要点：性能、高可用、伸缩性、扩展性、安全性。令人印象非常深刻。而且李智慧老师深谙职场之道，后面一些关于技术人的建议也让人受用无穷。去年5月底报名的极客时间李智慧老师的架构课，感觉很受益，虽然并没有讲解太多关于具体技术的细节，但关于技术体系的构建以及很多观点比具体技术细节要受用得多。

事物发展到一定阶段，就会拥有自身的发展冲动，摆脱其初衷，向着使自己更强大的方向发展。既然大型网站架构解决了海量数据的管理和高并发事务的处理，那么就可以把这些解决方案应用到网站自身以外的业务上去。(云计算)

技术是用来解决业务问题的，而业务问题，也可以通过业务的手段来解决。

对模式的灵活运用，在于对问题和需求本质深入的理解，技术不足为虑。问题的实质才是关键。搞清楚问题，问题也就解决了一半。不要一味地陷入技术中，技术早已被前人转化为经验模式，善于站在巨人的肩膀上解决问题，才能让自己的境界提高。这不是对技术的轻视，而是对技术的尊重—技术的经验模式就应该被用于解决重复存在的问题。

性能、可用性、伸缩性、扩展性和安全性是网站架构最核心的几个要素，这几个问题解决了，大型网站架构设计的大部分挑战也就克服了。

性能

网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。

CPU Load的理想值是CPU的数目。
当Load值低于CPU数目的时候，表示CPU有空闲，资源存在浪费；
当Load值高于CPU数目的时候，表示进程在排队等待CPU调度，表示系统资源不足，影响应用程序的执行性能。
在Linux系统中使用top命令查看，该值是三个浮点数，表示最近1分钟，10分钟，15分钟的运行队列平均进程数。

性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓的增加访问压力，在系统测试环境中，就是不断增加测试程序的并发请求数。

消息队列具有很好的削峰作用—即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。

从编程的角度，资源复用主要有两种模式：单例和对象池。
所谓的连接池、线程池，本质上都是对象池，即连接、线程都是对象，池管理方式也基本相同。

HDFS（Hadoop分布式文件系统）中，系统在整个存储集群的多台服务器上进行数据并发读写和备份，可以看作在服务器集群规模上实现了类似RAID的功能，因此不需要磁盘RAID。

• HDFS中有两种重要的服务器角色：NameNode（名字服务节点）和DataNode（数据存储节点）。
• NameNode:在整个HDFS中只部署一个实例，提供元数据服务，相当于操作系统中的文件分配表（FAT），管理文件名Block的分配，维护整个文件系统的目录树结构。
• DataNode: 则部署在HDFS集群中其他所有服务器上，提供真正的数据存储服务。
• HDFS以块（Block）为单位管理文件内容，一个文件被分割成若干个Block，当应用程序写文件时，每写完一个Block，HDFS就将其自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台服务器宕机，数据依然可以访问，相当于实现了RAID1的数据复制功能。
• 应用程序（Client）需要写文件时，首先访问NameNode，请求分配数据块，NameNode根据管理的DataNode服务器的磁盘空间，按照一定的负载均衡策略，分配若干数据块供Client使用。

技术是为业务服务的，技术选型和架构决策依赖业务规划乃至企业战略规划，离开业务发展的支撑和驱动，技术走不远，甚至还会迷路.

可用性

对公司而言，可用性关系网站的生死存亡。对个人而言，可用性关系到自己的绩效升迁。工程师对架构做了许多优化、对代码做了很多重构，对性能、扩展性、伸缩性做了很多改善，但别人未必能直观地感受到，也许你的直接领导都不知道你做的这些意义何在。**但如果你负责的产品出了重大故障，CEO都会知道你的名字。
事物总是先求生存，然后求发展。
保证网站可用，万无一失，任重而道远

网站年度可用性指标=（1-网站不可用时间/年度总时间）×100%
对于大多数网站而言:
99%: 2个9是基本可用，网站年度不可用时间小于88小时；
99.99%: 3个9是较高可用，网站年度不可用时间小于9小时；
99.99%: 4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；
99.999%: 5个9是极高可用性，网站年度不可用时间小于5分钟.
事实上，Twitter网站的可用性不足2个9。

既然硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。而实现高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)、数据可用性(Availibility)、分区耐受性(Patition Tolerance,系统具有跨网络分区的伸缩性)这三个条件。

伸缩性

所谓网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力.

一般而言，NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事务一致性保证（ACID）。而强化其他一些大型网站更关注的特性：高可用性和可伸缩性。

高手定律：这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了.

扩展性

扩展性：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。

• 表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。
• 它是系统架构设计层面的开闭原则（对扩展开放，对修改关闭），架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。

注意与伸缩性的区别：

伸缩性：指系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力

安全性

非对称加密： 不同于对称加密，非对称加密和解密使用的密钥不是同一密钥，其中一个对外界公开，被称作公钥，另一个只有所有者知道，被称作私钥。

• 用公钥加密的信息必须用私钥才能解开，反之，用私钥加密的信息只有用公钥才能解开
• 非对称加密算法常用有RSA算法等。

总结

一位网站资深架构师曾经说过：在互联网公司呆一年，相当于在传统软件公司呆三年。他的意思大概是在互联网公司一年遇到的问题比传统软件公司三年遇到的问题还多。而且随着网站业务的快速发展，问题也层出不穷，每年遇到的问题都不同。遇到问题，解决问题，经历了这个过程，技术才能升华，人和技术才能融为一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。

• 大型网站的技术本质都很简单，没有很花哨的东西，掌握起来也不难。
• 大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。
• 每一次故障都会给公司带来难以估计的利益损失，所以培养一个网站架构师的成本不单要看付了他多少薪水，给了他多少股票，还要看为他引起的故障买了多少次单。

在软件开发过程中，架构师除了实现技术架构，完成产品技术实现外，还需要和项目组内外各种角色沟通协调，可以说架构师相当多的时间用在和人打交道上。

• 处理好人的关系对架构和项目的成功至关重要。

最好的软件项目管理不是制订计划，组织资源，跟踪修正项目进展，对成员进行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。
每个人都是为实现自我价值而努力，不是为了领工资而工作.

领导的真谛：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
没有懒惰的员工，只有没被激发出来的激情。所有强迫员工加班的管理者都应该为自己的无能而羞愧。

有些企业喜欢挖优秀的人，而不是去把自己打造成一个培养优秀人才的地方。殊不知：是事情成就了人，而不是人成就了事。指望优秀的人来帮自己成事，不如做成一件事让自己和参与的人都变得优秀。

学会妥协:

• 不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。
• 很多时候，对架构和技术方案的反对意见，其实意味着架构和技术方案被关注、被试图理解和接受。架构师不应该对意见过于敏感，这时架构师应该做的是坦率地分享自己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。对于技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候也意味着问题已经收敛，对于整体架构设计，各方意见正趋于一致。

学会提问：

• 给上司提问应该是“你觉得A和B两个方案哪个更好？”这种封闭式问题。
• 给下属提问则相反，用开放式的问题启发他去思考，寻找创新的解决方案。所以，只有“元方，你怎么看？”，而没有“大人，你怎么看？”。