大型网站技术架构

纯阳书评（公众号:纯阳书评／微信号:chimbusco88）《构建可伸缩web应用》是一本重点关注网站伸缩性的架构好书，而本书则是关于大型网站性能、可用性、伸缩性、扩展性和安全性等5个核心要素的架构好书！ 好在三个方面，一是作者具很强洞察力，观察并总结出了大型网站发展过程中架构立演化的规律和内在逻辑。 二是通过为现阶段大型网站架构做全景式透视，阐述了不同层面架构设计所要考虑的问题和解决思路，详细讨论了分层、分割、分离、分库、分片和分布的理念和实践。 三是分享了关于架构师的分类、领导艺术、互联网应用与传统应用开发异同等方面的观点，见解很精辟。

大型网站不是设计出来的，而是逐步发展演化出来的。 不要企图去设计一个大型网站！ 有些传统企业进军互联网，凭借其雄厚的资金、丰富的行业经验、近乎垄断的市场地位，试图在互联网领域开发一个大型网站复制其在传统行业的优势地位。但是互联网发展运行有其自己的规律，短暂的互联网历史已经一再证明这种企图是行不通的。 垄断、牌照、行业壁垒、国有资本、行政资源，这些在传统行业呼风唤雨的魔法到了互联网领域只会被嘲笑、被捉弄。庞大只是笨拙而已，壁垒只会画地为牢，没什么了不起。 互联网没有门槛，谁都可以进来玩，但是进来后，最好把那些陈旧的思想和包袱放下，重新来过。 互联网是一个开放和分享的世界，这里是创新者的乐园，探险者的处女地。只要你努力，富有想象力和聪明才智，能为用户创造价值，能推动社会进步，不管你开始时多么弱小，总有机会迅速聚集资金、人才和注意力，在的时间内发展壮大。 互联网是一种精神，一种开放、分享、自由的精神；越是付出不问回报，越是获得丰厚的回报；越是不设边界，越是拥有整个世界。互联网是一种颠覆，打碎所有的藩篱，给所有人平等表达和获取的机会，每个人都可以发出自己的声音。互联网是一种建设，重塑人们的思维方式和社会运行方式，建设一个人和人彼此理解信任的大同世界。

一个大型网站不是设计出来的，是一步步发展演进而成的，书中主要介绍了网站设计的基本架构技术选型，包括架构的设计和优化等，一些重点技术的使用场景案例剖析，增长了不少见识，值得定期翻开再研读。         最后书中说的真好:互联网是一种精神，一种开放、分享、自由的精神；越是付出不问回报，越是获得丰厚的回报；越是不设边界，越是拥有整个世界。互联网是一种颠覆，打碎所有的藩篱，给所有人平等表达和获取的机会，每个人都可以发出自己的声音。互联网是一种建设，重塑人们的思维方式和社会运行方式，建设一个人和人彼此理解信任的大同世界。 互联网正在并将继续改变这个世界，一切才刚刚开始，你我正生逢其时！

虽然这本书成书时间较早，里面提到的技术放在如今大多已经过时，但是作者作为架构师在解决这些技术问题过程中的思考方式和职业生涯的阅历我认为才是这本书最值得称道的地方。技术永远在进步，只是表象，但是解决问题的思维方式才是本质。因此不在于掌握多先进的技术，而在于根据实际业务使用最适合的技术，技术一定是要围绕业务螺旋式展开的。

5分好评。技术书有其独特的写作难度，但这本书的作者能做到举重若轻，靠的是丰富的经验，严密的逻辑，广阔的胸怀，甚至是禅师般的哲学境界。 全书精炼而全面，没有代码，没有废话，有一点理科基础的读者，都可以轻松看懂这本书，看过后会对网站的技术支持有一个全面的了解和理解。

几年前，我读过，感觉学到了好多东西，很多东西听都没有听过；这次读感觉内容有点浅薄，即便是这样，也学到了好多，再次巩固一下，列出来，如下： 1、Facebook是伯克扎克同学在哈佛大学的宿舍里开发的；Google的第一台服务器部署在斯坦福大学的实验室里；阿里巴巴则是在马云家的客厅里诞生的。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的，这也正好与网站架构的发展演化过程对应。 2、网站技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将网站技术发展引入崎岖小道，架构之路越走越难。 3、技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。 4、目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。此外，还有可以支持网站线上服务器配置实时更新的分布式配置；分布式环境下实现并发和协同的分布式锁；支持云存储的分布式文件系统等。 5、在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。 6、访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。 7、山寨与创新的最大区别不在于是否抄袭，是否模仿，而在于对问题和需求是否真正理解与把握。 8、一般说来，除了当前的系统功能需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素，架构设计过程中需要平衡这5个要素之间的关系以实现需求和架构目标，也可以通过考察这些架构要素来衡量一个软件架构设计的优劣，判断其是否满足期望。 9、衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过测试这些指标以确定系统设计是否达到目标。 10、网站可伸缩架构的主要手段是事件驱动架构和分布式服务。 事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。 分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。可复用服务升级变更的时候，也可以通过提供多版本服务对应用实现透明升级，不需要强制应用同步变更。 11、衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。 12、性能、可用性、伸缩性、扩展性和安全性是网站架构最核心的几个要素，这几个问题解决了，大型网站架构设计的大部分挑战也就克服了。 14、吞吐量：指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可以用“请求数/秒”或是“页面数/秒”来衡量，也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。TPS（每秒事务数）是吞吐量的一个常用量化指标，此外还有HPS（每秒HTTP请求数）、QPS（每秒查询数）等。 15、性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。 16、减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。 17、网站性能优化第一定律：优先考虑使用缓存优化性能。 18、网站数据访问通常遵循二八定律，即80%的访问落在20%的数据上 19、一般说来，数据的读写比在2:1以上，即写入一次缓存，在数据更新前至少读取两次，缓存才有意义。 20、因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。 --所以商品属性，没有必要时时更新； 21、当缓存服务崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况被称作缓存雪崩。 22、产品在设计之初就需要一个明确的定位：什么是产品要实现的功能，什么不是产品提供的特性。在产品漫长的生命周期中，会有形形色色的困难和诱惑来改变产品的发展方向，左右摇摆、什么都想做的产品，最后有可能成为一个失去生命力的四不像。 23、如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其value值为null）。 24、启动线程数=[任务执行时间/（任务执行时间-IO等待时间）]×CPU内核数 25、编程上，解决线程安全的主要手段有如下几点。 将对象设计为无状态对象：所谓无状态对象是指对象本身不存储状态信息（对象无成员变量，或者成员变量也是无状态对象），这样多线程并发访问的时候就不会出现状态不一致，Java Web开发中常用的Servlet对象就设计为无状态对象，可以被应用服务器多线程并发调用处理用户请求。 使用局部对象：即在方法内部创建对象，这些对象会被每个进入该方法的线程创建，除非程序有意识地将这些对象传递给其他线程，否则不会出现对象被多线程并发访问的情形。 并发访问资源时使用锁：即多线程访问资源的时候，通过锁的方式使多线程并发操作转化为顺序操作，从而避免资源被并发修改。 26、从编程角度，资源复用主要有两种模式：单例（Singleton）和对象池（Object Pool）。 27、事实上，Java开发常用的对象容器Spring默认构造的对象都是单例（需要注意的是Spring的单例是Spring容器管理的单例，而不是用单例模式构造的单例）。 28、对于每个Web请求（HTTP Request），Web应用服务器都需要创建一个独立的线程去处理，这方面，应用服务器也采用线程池（Thread Pool）的方式。这些所谓的连接池、线程池，本质上都是对象池，即连接、线程都是对象，池管理方式也基本相同。 29、在JVM分代垃圾回收机制中，将应用程序可用的堆空间分为年轻代（Young Generation）和年老代（Old Generation），又将年轻代分为Eden区（Eden Space）、From区和To区，新建对象总是在Eden区中被创建，当Eden区空间已满，就触发一次Young GC（Garbage Collection，垃圾回收），将还被使用的对象复制到From区，这样整个Eden区都是未被使用的空间，可供继续创建对象，当Eden区再次用完，再触发一次Young GC，将Eden区和From区还在被使用的对象复制到To区，下一次Young GC则是将Eden区和To区还被使用的对象复制到From区。因此，经过多次Young GC，某些对象会在From区和To区多次复制，如果超过某个阈值对象还未被释放，则将该对象复制到Old Generation。如果Old Generation空间也已用完，那么就会触发Full GC，即所谓的全量回收，全量回收会对系统性能产生较大影响，因此应根据系统业务特点和对象生命周期，合理设置Young Generation和Old Generation大小，尽量减少Full GC。 30、目前许多NoSQL产品采用LSM树作为主要数据结构，LSM树可以看作是一个N阶合并树，在LSM树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树。当数据访问以写操作为主，而读操作则集中在最近写入的数据上时，使用LSM树可以极大程度地减少磁盘的访问次数，加快访问速度。 31、RAID5和RAID3很相似，但是校验数据不是写入第N块磁盘，而是螺旋式地写入所有磁盘中。这样校验数据的修改也被平均到所有磁盘上，避免RAID3频繁写坏一块磁盘的情况。 32、网站性能优化的主要工作是改善高并发用户访问情况下的网站响应速度。 33、归根结底，技术是为业务服务的，技术选型和架构决策依赖业务规划乃至企业战略规划，离开业务发展的支撑和驱动，技术走不远，甚至还会迷路。 34、网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点。 35、对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。 36、既然硬件故障是常态，网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。 37、在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。 38、降级有两种手段：拒绝服务及关闭服务。 39、数据一致性又可分为如下几点。、 数据强一致：各个副本的数据在物理存储中总是一致的；数据更新操作结果和操作响应总是一致的，即操作响应通知更新失败，那么数据一定没有被更新，而不是处于不确定状态。 数据用户一致：即数据在物理存储中的各个副本的数据可能是不一致的，但是终端用户访问时，通过纠错和校验机制，可以确定一个一致的且正确的数据返回给用户。 数据最终一致：这是数据一致性中较弱的一种，即物理存储的数据可能是不一致的，终端用户访问到的数据可能也是不一致的（同一用户连续访问，结果不同；或者不同用户同时访问，结果不同），但系统经过一段时间（通常是一个比较短的时间段）的自我恢复和修正，数据最终会达到一致。 40、即使每次发布的新功能都是在原有系统功能上的小幅增加，但为了保证系统没有引入未预料的Bug，网站测试还是需要对整个网站功能进行全面的回归测试。 41、比较流行的Web自动化测试工具是ThoughtWorks开发的Selenium。Selenium运行在浏览器中，模拟用户操作进行测试，因此Selenium可以同时完成Web功能测试和浏览器兼容测试。 42、对于有固定发布日期的网站（很多网站选择周四作为发布日，这样一周前面有三天时间可以准备发布，后面还有一天时间可以挽回错误。如果选择周五发布，发现问题就必须要周末加班了。） 43、“不允许没有监控的系统上线”，这是许多网站架构师在做项目上线评审时常说的一句话。 44、目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具。 45、事物总是先求生存，然后求发展。保证网站可用，万无一失，任重而道远。 46、使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS（Linux Virtual Server）。 47、负载均衡算法通常有以下几种。 轮询（Round Robin，RR）、加权轮询（Weighted Round Robin，WRR）、随机（Random）、最少连接（Least Connections）、源地址散列（Source Hashing） 48、计算机领域有句话：计算机的任何问题都可以通过增加一个虚拟层来解决。计算机硬件、计算机网络、计算机软件都莫不如此。计算机网络的7层协议，每一层都可以看作是下一层的虚拟层；计算机操作系统可以看作是计算机硬件的虚拟层；Java虚拟机可以看作是操作系统的虚拟层；分层的计算机软件架构事实上也是利用虚拟层的概念。 49、网站架构师必须对网站的商业目标、历史演化、技术路线了然于胸，甚至还需要综合考虑技术团队的知识储备和结构、管理层的战略愿景和规划，才能最终做出对网站伸缩性架构最合适的决策。 50、高手定律：这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。 51、救世主定律：遇到问题，分析问题，最后总能解决问题。如果遇到问题就急匆匆地从外面挖一个高手，然后指望高手如探囊取物般轻松搞定，最后怕是只有彼此抱怨和伤害。许多问题只是看起来一样，具体问题总是要具体对待的，没有银弹，没有救世主。所以这个定律准确地说应该是“没有救世主定律”。 52、扩展性（Extensibility）：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则（对扩展开放，对修改关闭），架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。 伸缩性（Scalability）：指系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。 53、笔者认为，软件架构师最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解、对人性的把握、甚至对世界的认知。 54、马克思的劳动价值理论告诉我们，产品的内在价值在于劳动的时间，劳动的时间不在于个体付出的劳动时间，而在于行业一般劳动时间，资本家只会为行业一般劳动时间买单，如果你的效率低于行业一般劳动时间，对不起，请你自愿加班。 55、HTTP请求头的Referer域中记录着请求来源，可通过检查请求来源，验证其是否合法。很多网站使用这个功能实现图片防盗链（如果图片访问的页面来源不是来自自己网站的网页就拒绝）。 56、ModSecurity是一个开源的Web应用防火墙，探测攻击并保护Web应用程序，既可以嵌入到Web应用服务器中，也可以作为一个独立的应用程序启动。ModSecurity最早只是Apache的一个模块，现在已经有Java、.NET多个版本，并支持Nginx。 57、信息加密技术可分为三类：单项散列加密、对称加密和非对称加密。 58、在合适的场景下使用合适的产品，而不是最好的产品，所谓小脚穿大鞋，不但跑不快，还可能会摔跤。 59、Wikipedia通过约束业务获得更大的技术方案选择余地，很多时候业务后退一小步，技术就可以前进一大步。 60、一般而言，服务器之间通信越少，就越少依赖，发生故障时互相影响就越少，集群的可用性就越高。 61、网站的秒杀业务不能使用正常的网站业务流程，也不能和正常的网站交易业务共用服务器，必须设计部署专门的秒杀系统，进行专门应对。 62、 秒杀系统的应对策略为了应对上述挑战，秒杀系统的应对策略有如下几点。 1）、秒杀系统独立部署 2）、秒杀商品页面静态化 3）、租借秒杀活动网络带宽 4）、动态生成随机下单页面URL 63、大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。每一次故障都会给公司带来难以估计的利益损失，所以培养一个网站架构师的成本不单要看付了他多少薪水，给了他多少股票，还要看为他引起的故障买了多少次单。 64、高并发访问数据库引发的故障，经验教训： ●首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。 ●首页最好是静态的。 65、高并发情况下锁引发的故障，经验教训： ●使用锁操作要谨慎。 66、缓存引发的故障，经验教训： 、 ●当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。 67、不规范的流程引发的故障，经验教训： ●代码提交前使用diff命令进行代码比较，确认没有提交不该提交的代码。 ●加强code review，代码在正式提交前必须被至少一个其他工程师做过code review，并且共同承担因代码引起的故障责任。 68、不好的编程习惯引发的故障，经验教训： ●程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。 ●程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象（使用空对象模式）。 69、一定要坚信：一群优秀的人做一件他们热爱的事，一定能取得成功。 70、这也是领导的真谛：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。 71、没有懒惰的员工，只有没被激发出来的激情。所有强迫员工加班的管理者都应该为自己的无能而羞愧。 72、大多数人，包括我们自己，都比自己以为的更优秀，有些优秀需要在合适的环境中才会被激发出来，比如做一些有挑战的事，和更优秀的人合作，抑或拥有了超越自我的勇气。发掘人的优秀远比发掘优秀的人更有意义。 73、共同参与架构 1）、不要只有架构师一个人拥有架构 让项目参与者对架构充分争论，大家越是觉得自己是项目架构的重要贡献者，就越是愿意对开发过程承担责任，越是愿意共同维护架构和改善软件。 2）、让其他人维护框架与架构文档 除非是重大的重构，否则架构师应该让项目组成员维护框架和架构文档，给项目组成员成长的机会也让自己有更多的时间去寻找更大的挑战。 74、不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。 75、架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己。你越是强加禁令，队伍就越是没有纪律；你越是强制，团队就越是不能独立自主；你越是从外面寻找帮助，大家就越是没有信心。 76、开发软件的目的是为了解决现实世界的问题，但是很多时候人们并不清楚真正的问题是什么。有可能大家很辛苦地忙活了一场，发现做出来的软件一点价值没有。 77、所谓问题，就是体验—期望，当体验不能满足期望，就会觉得出了问题。消除问题有两种手段：改善体验或者降低期望。降低期望只是回避了问题，而如果直面期望和体验之间的差距，就会发现问题所在，找到突破点。 78、给上司提封闭式问题，给下属提开放式问题 所以，只有“元方，你怎么看？”，而没有“大人，你怎么看？”。 79、用一种温和的方式提出问题“我非常赞同你的方案，不过我有一个小小的建议……”。 80、有时候，有些人会提出一些不怎么靠谱的问题和方案。比如，一个急着要表现自己能力和价值的新员工，你如果和他直接说“不行”，会挫伤他的积极性，而他经过一段时间的磨合和思考，会自己意识到不可行。对于这种情况，适当逃避问题，将事情搁置起来是最好的办法。“我去开个会，我们回来再谈。”“这个idea非常好，我们改天组织一个会议好好讨论一下……” 81、目前各种NoSQL数据库层出不穷，在内存管理、数据模型、集群分布式管理等方面各有优势，不过从社区活跃性角度看，HBase无疑是目前最好的。 82、这是一本讲大型网站架构设计的书，但是大型网站不是设计出来的，而是逐步发展演化出来的。

页页干货，字字珠玑，喜欢看这种短小而精悍、深入而浅出的书，作者从从一个大的视角高屋建瓴的分析了大型(高并发和海量数据处理)网站的方方面面，前面几章偏技术，后面几章偏项目管理，总体来看是一本目录级别的入门书，对于具体技术的细节仍需要深入研究。

一刷书评： 这是一本关于系统架构设计技术启蒙或入门的书籍，5星推荐。 这是一本无意或有意间偶然看到的书，虽做着与之无关的工作，但周围也碰到一些类似问题，同时因为兴趣而读了下来，读得比较细，历时超过8小时，大概5天的时间，做了超过300条笔记，在读的过程中，有一种醍醐灌顶或者说是柳暗花明又一村的感觉，正如作者在书中所说，原理其实是很简单清晰的，这或者也可以说是“系统架构设计应该是简单的，简单到没有明显的问题”，不管我们是否读懂了该书，如果要落实到底，对我们来说仍然任重而道远，不可轻视。 这是一本技术指导的书，建议带着问题来读，这样就感觉特别想读，同时强烈建议先读完<<淘宝技术这十年>>后，再读该书，也许我们的感受会更好些，如果能够和实践中碰到问题结合起来，也许我们的感受会更深，乃至该书的循序渐进的解决方案会有一种水到渠成的感觉，或者说理所当然应该如此做。这两本书都是“阿里人”所著，反映了阿里的一个特点趋势，业务不断驱动技术，技术促进业务发展，这何尝不是对于现实里中小公司具有极好的借鉴学习呢。比较好奇的是：业界常说百度强技术，阿里强运营，腾讯强产品。感觉同为bat，阿里技术人这边出类似技术类书籍要多于另外两家，也许是其他2家可能不喜欢分享吧，但是最大的也许是我读书少😅。 这也是一本关于做人做事的书。在书中最后部分，挥洒了很多笔墨，传递了作者的一些观点。以前也碰到过类似问题，一直难以忘怀，在读该书中，豁然开朗。看来，读书真的是一件好事。当我们读完一百本，我们或许会与之前有了一些不同吧；当我们读完500本，也许会到达另一个层次吧；而当我们读完1000本，又会是怎么一番场景了，也许对于自己、对于这个社会、对于这个世界、乃至对于我们这个宇宙，会有独属于自己全新的认知吧。然而真正到达这几个节点的人几乎不会告诉我们这是一种怎样的感觉，即使讲述出来我们是否又能真正切实感受到呢？而这也是我们一直持续不断追求的东西。 而我此时比较好奇的只是这样一个问题，读完100本书，我们需要多少时间😂。 以上仅为一个非架构师初学者词不达意的喃喃自语。

系统设计的一本入门指南级图书。大，全，而不深。 针对大型网站架构的追求：性能，可用性，伸缩性，扩展性，安全性。作者都列举了常见的具体的解决方案，且简单描述了原因，原理，实现和效果。这些解决方案大都是自底向上的经验总结，而缺少宏观设计。又可能篇幅受限，流于浅显。最可惜的是，作者没有给出参考文献，好像把人胃口吊起来，然后菜没了。 除了技术的部分，对架构师职业性质和内容的探讨，真诚而有启发，个人觉得反而比前文更有价值。

在互联网领域，任何一个小问题，当数据规模，业务场景增长到一定量级时，问题都会开始变得棘手起来。《大型网站技术架构：核心技术原理与案例分析》一书简单的介绍了一个网站是如何一步步从最简单的单体架构模式逐渐演变成集群分布式架构。针对大型网站在性能、可用性、伸缩性、扩展性、安全性等方面的常见问题以及处理方案也做了比较细致的介绍。 在演变的过程中，网站的性能、可用性、伸缩性、扩展性、安全性收到了前所未有的挑战，但正是有了这些挑战，也才促进了技术的快速进步与发展；另一方面，技术是服务于业务的，如果为了技术而技术往往得不偿失，业务的发展过程也是渐进式的，在业务的不同阶段需要不同的架构和模式，因此，在软件行业，没有圣杯和银弹。但在发展过程中，我们逐渐吸取经验教训，却又总结了一套可以服用的理论和方法，在实际过程中还是需要特殊情况特殊处理，切不可生搬硬套。