《大型网站技术架构》读后感精选10篇
《大型网站技术架构》是一本由李智慧著作，电子工业出版社出版的平装图书，本书定价：59.00元，页数：218，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《大型网站技术架构》读后感(一)：李智慧，有智慧
这本书太好读了，今天我一口气读了5个小时把它读完，根本停不下来。
作者显然是一个很有智慧的人，很多技术本质他都能看的很透。本书不是一本技术细节书籍，虽然第六章他也详细介绍了memcache的分布式哈希原理，看得出作者研究的很深。
我一直对架构师之类的buzzword嗤之以鼻，看了本书以后发现是我自己太浅薄了。我原来以为架构师主要负责设计，原来架构师还要操心运维自动化、安全等问题。
看完本书学到的不仅是架构方面的知识，还有作者的学习方法。可以在第4篇案例看到，作者研究过很多系统的架构。
其它评论的是是非非不想评论，但是我想说明一点，这本书重要的是思想，是作者多年以来思考、经验的凝聚。
下面的list，是我的笔记:
- 不要企图去设计一个大型网站!
- 当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高的和其它服务器一样的级别。
- 不要为了技术而技术，不要企图用技术解决所有问题。业务的问题可以通过技术解决，也可以通过业务解决。
- 自动化代码管理
- 自动化测试
- 自动化安全检测
- 自动化部署
- 自动化报警
- 自动化失效恢复
- 自动化失效转移
- 自动化降级
《大型网站技术架构》读后感(二)：书的内容还可以，但是印刷质量太差，建议不要购买，对不起这个价格
前几天，犹豫了很久，同时入手了李智慧的《大型网站技术架构 核心原理与案例分析》和杨传辉的《大规模分布式存储系统 原理解析与架构实践》。一到手，看到李智慧的《大型网站技术架构 核心原理与案例分析》，没有开读，看到 【“电子工业出版社”】 印的书就后悔了。
标价同样是59的书。
李智慧的《大型网站技术架构 核心原理与案例分析》 218页， 封面还没开始用，就皱了。封面，一前，以后，扉页处的纸那是一个差，像是以前八九十年代，上厕所用的那种纸一样。刚送过来，封面就有点脱胶。【电子工业出版社】，你还敢更没有节操一点么？这样的书，真心担心看一次，就破烂不堪了。
内容还未看，不过看过封面，讲解的内容还是不错。虽然可能都是皮毛，但是提供了一个深入下去的方向。
而同样是阿里系出的， 杨传辉的《大规模分布式存储系统 原理解析与架构实践》，【机械工业出版社】 共293页， 比起 李智慧的《大型网站技术架构 核心原理与案例分析》，纸张和包装完全是属于精美的级别。书到手时，还有塑料封装。
阿里的这两本书，总的来说，书中讨论的内容还是不错。但是强烈鄙视【“电子工业出版社”】 这种无良出版商。
《大型网站技术架构》读后感(三)：提纲挈领，看山是山，看水是水
很是惭愧，我在2017年的今天才阅读了这本久负盛名的《大型网站技术架构—核心原理与案例分析》一书。买之前也看了大家的评论，大部分人对这本书的缺点评价的很到位：泛泛而谈。但我不敢苟同。
不知道还有多少豆友还记得高中政治课本中的内容，我记得从政治经济学讲起的时候，那句“商品的价值是凝结在商品中的无差别的人类劳动”是多么的深刻而又简单，一本薄薄的政治课本，能否概括《资本论》和《政治经济学》中所有的内容？明显不可能，如果你后来大学深入学习过这些大部头，回过头来再阅读高中课本的时候，是不是也有种“泛泛而谈”的感觉呢？是不是也有种“你说的道理我都懂，都能找到这些资料，这个课本只不过是资料的堆砌”的感觉呢？肯定是有，因为你已经到了看山不是山，看水不是水的境界，却还差一层。课本的编委，绝非浪得虚名，一个简单的定义，一个简单的论述和证明，就已经超出了“泛泛”的范畴。
你要明白，这本书的用途是什么？大型网站技术架构，你想象的干货肯定是关于淘宝内部使用的各种框架技术和他们的组合，甚至有详细的片段的代码， 告诉你这样做就对了，这样就可能做一个大型网站，甚至复制淘宝。这恰恰是作者所不愿看到的，作者结尾写的很明白，不要企图去设计一个大型网站，对于一个以盈利为目的的企业来说，业务永远是第一位的，技术永远是为业务服务的。作者不希望你看完这本书后回去告诉你老大说咱们得这样这样改才能支持千万级的调用，但其实你所负责的产品TPS可能连5都不到。作者希望的是你拥有大型网站技术架构的思维，从多个角度去考虑问题，而不要仅仅专注于某个方面，并且给出了常见的解决方案，作为一本“领进门”的书籍而言，已然足矣。
技术架构，一切从实际出发，一切从业务出发，源于业务，也要高于业务。看本书的架构：性能，可用性，伸缩性，扩展性和安全性。从五个最重要的角度说明了大型网站设计和演化的时候需要关注什么，并且着重强调了伸缩性和扩展性的区别，这不就是干货吗？你在网上随便搜索个博客会告诉你二者的区别？而且作者大部分的图例都能保持一致的风格，这点也让阅读时舒服了很多。当然，缺点也是有，也很明显，大部分人就是冲着《案例》来的，毕竟前面写太多的理论，最终总要结合实际，《案例》有但内容不够多，可能涉及到一些商业机密，无论如何，瑕不掩瑜，但希望如果未来再版的话可以加强。
如果我是在2013年看的这本书，我一定会简单的站到“泛泛”这一消息队列中，但好在我是在4年后的今天看到，经过一番摸爬滚打，与作者心有戚戚焉。才明白，任何事情，纸上学来终觉浅。
《大型网站技术架构》读后感(四)：干货略少，泛泛而谈
作者在阿里有一线的架构经验，但是本书中谈得并不深入，老生常谈的一些东西，实例部分更是点到即止。不过作者作了一定的归纳，可以看作是一般的方法论入门。
下面是部分摘抄内容：
4.3.4 代码优化(P54)
1.多线程
（1）使用多线程的原因：IO阻塞与多CPU；
（2）启动线程=[任务执行时间/(任务执行时间-IO等待时间)] * CPU内核数
（3）线程安全的主要手段：将对象设计为无状态、使用局部对象、并发访问资源时使用锁；
2.资源复用：单例、线程池；
4.垃圾回收。
5.3.2 应用服务器集群的Session管理
1.Session复制；
2.Session绑定；
4.Session服务器；
7.1
1.伸缩性
不需要改变网站的软硬件设计，仅仅通过改变部署服务器数量就可以扩大或者缩小网站的服务处理能力。或者说，系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。
2.扩展性
对现在系统影响最小的情况下，系统功能可持续扩展或者提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应，它是系统架构设计层面的开闭原则。
规则引擎是一种将业务规则和规则处理相分离的技术，业务规则将文件由运营人员通过管理界面编辑，当需要修改规则时，无须更改代码发布程序，即可实时使用新规则，而规则处理逻辑则调用处理输入的数据。
《大型网站技术架构》读后感(五)：不想当架构师的程序员不是好产品
对整个技术体系缺少整体认知的我，这本书给我一个整体的骨架感。
以前只做后端技术，喜欢研究算法，知识面比较窄。花1个小时看完第一章就有种神清气爽的感觉，忽然明白了那些大型网站，海量的淘宝是怎么架构出来的。
性能、可用性、伸缩性、扩展性和安全五大方面来阐述网站架构，从纵向的前端、应用、服务、数据，到横向的各模块交互，全面丰富的解构。
作者把复杂的问题简单的概括总结出来，对于互联网经验不够充足的我来说，这些知识整体、全面，学到作者的分析和理解能力，弥足珍贵。
最后不忘说说架构师应该如何和大家合作，如何更好工作的话题，说的相当在理，作者是想明白了的聪明过来人。
《大型网站技术架构》读后感(六)：《大型网站技术架构》笔记
核心原理与案例分析
分为三个部分，应用区、文件区、DB区：
大型网站核心架构要素：性能、可用性、伸缩性、扩展性、安全性
WEB前端性能优化：减少http请求，合并CSS、合并Javaｓｃｒｉｐｔ、合并图片。使用浏览器缓存。启用压缩。CSS放页面最上面，JS放页面最下面。减少Cookie传输。CDN加速。反向代理。
缓存：将数据存储在相对较高访问速度的存储介质中。缓存的内容为：读写比例高、很少变化的数据。
分布式缓存：memcached
消息队列异步处理
线程数量和CPU内核数成正比
RAID0：并发写入每块磁盘
RAID1：两块磁盘都写同样的
RAID10
RAID5：
HDFS取代RAID
预发布服务器：不添加在负载均衡中的完全一样的服务器
灰度发布
几种负载均衡方式：HTTP重定向负载均衡、DNS域名解析负载均衡、反向代理负载均衡、IP负载均衡、直接路由负载均衡（修改MAC，LVS）
负载均衡算法：RR轮询、WRR加权轮询、随机、最少连接、源地址散列
70%的WEB攻击来自XSS攻击和SQL注入攻击
消毒、禁止页面Javaｓｃｒｉｐｔ访问带有HttpOnly属性的Cookie
CSRF：跨站点请求伪造
开源WAF，web应用防火墙：ModSecurity
单向散列算法：MD5、SHA
对称加密：DES、RC
非对称加密：RSA
贝叶斯分类算法
秒杀系统的应对策略：秒杀系统独立部署、秒杀商品页面静态化、租借秒杀活动网络带宽、动态生成随机下单页面URL
首页不应该访问数据库，首页最好是静态的
《大型网站技术架构》读后感(七)：读书笔记
大型网站的关注指标
高可用
高性能
易扩展
可伸缩
安全
大型网站的特点
高并发，大流量
高可用
海量数据
用户分布广泛，网络情况复杂
需求快速变更，发布频繁
渐进式发展
大型网站架构演化发展过程
初始阶段，一般使用LAMP来搭建，所有资源存放在一台服务器上
应用服务和数据服务分离，有独立的数据库服务器
使用缓存改善网站性能，依据是二八定律：80%的业务访问集中在20%的数据上
这里需要考虑哪些数据适合缓存
缓存可以是本地缓存，也可以是远程分布式缓存
使用应用服务器集群改善网站的并发处理能力
如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性
这里需要考虑使用哪些负载均衡的策略
*数据库读写分离
缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能
可以利用主流数据库提供的主从热备功能，通过配置两台数据库的朱从关系，将一台数据库服务器上的数据同步到另外一台上面
使用反向代理和CDM加速网络响应
CDN和反向代理的基本原理都是缓存
CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户
使用分布式文件系统和分布式数据库系统
网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上
使用NoSQL和搜索引擎
业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线
分布式服务
大型网站架构演化的价值观
网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。
大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程
驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路
大型网站架构模式
分层，这是在横向方向对系统进行切分
分层的挑战在于必须合理规划层次边界和接口
分层包括物理分层和逻辑分层两种
分割，这是在纵向方向对系统进行切分
将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元
分布式
分层和分割的目的在于小模块便于分布式部署
带来的问题：1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；2） 服务器越多，宕机的概率越大
常用的分布式方案：1） 分布式应用和服务； 2） 分布式静态资源； 3） 分布式数据和存储； 4） 分布式计算；5） 分布式配置、分布式锁、分布式文件系统。。。
集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务
即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性
缓存，即将数据放在距离计算最近的位置以加快处理速度
CDN
反向代理
本地缓存
分布式缓存
异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作
通常需要使用消息队列
带来的好处：1） 提高系统可用性； 2） 加快网站响应速度； 3） 消除并发访问高峰
冗余
集群带来的必然结果
安全需求的必然结果
自动化，DevOps思维，尽量减少人工干预
自动化发布
自动化代码管理
自动化测试
自动化安全监测
自动化部署
自动化监控
自动化报警
自动化失效转移、恢复
自动化分配资源
......
安全
大型网站核心架构要素
性能
一个性能问题可能会导致网站用户严重流失
衡量性能的指标：响应时间、TPS、系统性能计数器等
可用性
没有网站可以完美的7*24运行
网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用
必要的手段是集群，即冗余
伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求
衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器
扩展性，直接关注网站的功能，保证可以快速响应需求变更
衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响
安全性
衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对
瞬时响应 - 高性能架构
不同视角下的网站性能
用户视角
主要是端到端的感觉
主要通过前段优化的手段来提升用户体验
开发人员视角
主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等
主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能
运维人员视角
主要关注基础设施性能和资源利用率
主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率
性能测试指标
响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间
并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性
吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力
性能计数器， 描述服务器或者操作系统性能的一些数据指标
性能测试方法
性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期
负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值
压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求
稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定
Web前段优化
浏览器访问优化
减少http请求
使用浏览器缓存
启用压缩
CSS放在页面最上面，Javaｓｃｒｉｐｔ放在页面最下面
减少Cookie传输
CDN加速
反向代理
应用服务器性能优化
分布式缓存
缓存从本质上来说，就是一个内存hash表
缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义
应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存
缓存也需要注意缓存热点数据
缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用
缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能
对于分布式缓存来说，目前有两类：1） 不同的缓存服务器之间进行通信，例如JBoss Cache；2）不同缓存服务器之间不进行通信，例如Memcached
异步操作
一般会使用消息队列，带来的额外好处是会削平峰值
使用集群
代码优化
多线程
需要注意线程安全问题，方法：1） 将对象设计成无状态对象；2） 使用局部对象；3） 并发访问资源时使用锁
资源复用
主要是单例和资源池（对象池）
数据结构，选择合适的算法
垃圾回收
合理设置垃圾回收策略
存储性能优化
机械硬盘 vs 固态硬盘
+树 vs LSM树
RAID vs HDFS
万无一失 - 高可用架构
网站的可用性描述网站可以有效访问的特性，它不同于易用性
网站可用性度量
网站不可用时间 = 故障修复时间点 - 故障发现时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%
一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟
网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问
网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。
高可用的应用
无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的
通过负载均衡进行无状态服务的失效转移
负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力
应用服务器集群的Session管理
ession复制
ession绑定
利用Cookie记录Session
ession服务器
高可用的服务
分级管理
超时设置
异步调用
服务降级
幂等性设计
高可用的数据
主要手段：数据备份和失效转移
CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件
数据一致性分类： 1） 数据强一致； 2） 数据用户一致； 3） 数据最终一致
数据备份
冷备的优点是简单和链家，成本和技术难度较低，缺点是不能保证数据最终一致
热备分为两种：1） 异步热备； 2） 同步热备
失效转移
失效确认：1） 心跳检测；2） 应用程序访问失败报告
访问转移
数据恢复
高可用网站的软件质量保证
网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似
一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器
自动化测试
一般使用Selenium来进行测试
预发布验证
预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问
代码控制
主干开发，分支发布
分支开发，主干发布，这是目前使用的主流方式
自动化发布
火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。
实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待问题解决后再来一次
一种可能是火车上的重点项目如果失败，那么整趟火车需要返回
人的干预越少，自动化程度越高，引入故障的可能性就越小
灰度发布
大型网站都会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天你才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可
网站运行监控
监控数据采集
用户行为日志收集
服务器性能监控
运行数据报告
监控管理
系统报警
失效转移
自动优雅降级
永无止境 - 可伸缩性架构
网站伸缩性： 在不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力
网站架构的伸缩性设计
不同功能进行物理分离实现伸缩
单一功能通过集群规模实现伸缩
应用服务器集群的伸缩性设计
HTTP重定向负载均衡
DNS域名解析负载均衡
反向代理负载均衡
IP负载均衡
数据链路层负载均衡
负载均衡算法
轮询
加权轮询
随机
最小链接
原地址散列
分布式缓存集群的伸缩性设计
Memcached分布式缓存集群的访问模型
用用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法、Memcached服务器集群列表以及通信模块构成
路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）
Memcached分布式缓存集群的伸缩性挑战
挑战主要针对路由算法，当集群扩容时，如何保证路由算法可以得到新加入的服务器？
解决方法： 在网站访问量最少的时候扩容，然后通过模拟请求的方法逐渐预热缓存，使得缓存服务器中的数据重新分布
分布式缓存的一致性Hash算法
数据存储服务器集群的伸缩性设计
数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性
关系数据库集群的伸缩性设计
利用主从结构实现读写分离
根据不同业务的数据，放到不同的数据库集群中，即数据库分库
对于特别大的表，进行分片处理
oSQL数据库的伸缩性设计
HBase
随需应变 - 可扩展架构
可扩展性：在对现有系统影响最小的情况下，系统功能可持续扩展或者提升的能力
实现可扩展的手段：低耦合，高内聚
利用分布式消息队列降低系统耦合性
事件驱动架构（Event Driven Architecture）
定义：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的场景是生产着消费者模型
分布式消息队列
利用分布式服务打造可服用的业务平台
需要将超大型的、复杂系统查分成可独立部署的模块，从而降低耦合性
Web Service与企业分布式服务
Web Service比较臃肿，可以考虑使用REST
或者使用开源的解决方案，例如Dubbo
可扩展的数据结构
固若金汤 - 安全架构
典型攻击方式
XSS攻击（跨站脚本攻击）
黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式
分类： 1） 反射型； 2） 持久型
解决方法：1） 消毒； 2) HttpOnly
注入攻击
分类： 1） SQL注入攻击； 2） OS注入攻击
解决方法：1） 消毒； 2） 参数绑定
CSRF攻击（跨站点请求伪造）
攻击者通过跨站请求，以合法用户的身份进行非法操作
解决方法： 识别请求者身份：1） 表单Token； 2） 验证码； 3） Referer check
其他攻击方式
Error Code，可能显示异常堆栈，从而暴露危险信息，解决方法：使用统一的500页面
HTML注释，注释可能会暴露危险信息，解决方法：code review或者自动扫描
文件上传，可能上传病毒文件，解决方法：设置上传文件白名单，只允许上传指定类型的文件
路径遍历， 在URL中使用相对路径，遍历系统未开放的目录和文件，解决方法： 将资源文件部署在独立的服务器上，使用独立域名
信息加密技术以及密钥管理
单项散列加密，包括MD5、SHA等
对称加密， 包括DES算法、RC算法等
非对称加密， 包括RSA算法等
密钥安全管理
将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设置，对外提供加密和解密服务
将加解密算法放在应用系统中，密钥则放在独立服务器中，在存储时，将密钥切分成数片，分别存储在不同的介质中
《大型网站技术架构》读后感(八)：比较全面，但不够深入
先吐个槽，虽说一本218页的书我也没期望能把某个知识点讲的很细，不过这讲得也太概括了。。。
言归正传，如果单从全面性上打分，那毫无疑问要给5分。从前端技术到后端优化，从架构改进到信息安全，一个架构师应该具备的技能都可以再这本书中找到身影。不夸张的说，如果可以把这本书里所提到的技能都掌握好，那么已经远超架构师的水准，可以直奔技术总监去了。
缺点上面也说了，因为摊子铺的太大，所以自然不可能面面俱到。或者更确切的说，应该是点到即止。看其他书评，很多在吐槽看个目录就好，内容几本没干货。回过头想想，这些知识点如果都写细了，那可以出一套大型网站技术架构丛书了~
其实我觉得我们可以换一种打开方式，这本书就好像给我们指出了一条道路，但是这条路要怎么走，还是需要我们自己去探索。况且这本书的知识体系很好，如果让我们自己去找资料，耗时费力不说，也不一定能够总结的这么好。
新手可以入门，老手可以当做备忘，总体上还是值得入手一本的。
《大型网站技术架构》读后感(九)：比较全面 有不少不错的观点
本文并没有什么特别的东西，但是都很实在，而且能很好的组织起来，也可以看为一个架构。
何为架构，要有大局观，大局观就是提前预防掉那些通用的问题：高可用，工程化，伸缩性，扩展性。对应需要的能力：了解分布式的一些东西，了解项目的业务和流程和运维使之工程化，了解负载均衡，能够对业务的分割和代码的分层。
文中其他的一些观点我倒是很喜欢：
1 先成就他人，再成就自己
2 刚开始加入的时候不要急于证明自己，要先融入。
3 最好的奖励就是目标的达成，最大的惩罚就是目标没实现
4 技术是要解决问题，但是我们要关心的是解决问题的人。
5 学会妥协
6越激烈的争辩代表越关心这个问题
文中有些例子有点意思
1 wiki的实现中就是业务退一小步，技术进一大步。这个他们能够那么省钱的原因啊。
2 秒杀从根本上来讲并不是很难，首先是页面的静态化，开始秒杀的按钮通过js来实现，js不缓存，js尽量小。开始秒杀的时候使用可以秒杀的js。秒杀很少能达数据层，因为就那么几个能成功。主要的压力在应用服务器，但是用一个记数服务器，收到请求更新这个数字，大于数字的直接返回秒杀失败。所以大部分都会进入失败的逻辑，整个也很简单。只要业务服务器能抗住这些访问压力就基本ok了，如果业务服务器不够，可以直接在负载均衡那边随机失败一部分。
3 负载均衡的实现： 1 dns实现 2应用层实现，使用反向代理。3 网络层实现 ip负载均衡，通过网关来修改目标ip 4 数据链路层 改mac地址，如lvs。 负载均衡的策略主要有 轮询 随机 最少连接 hash。
4 一致性hash的时候，用多个虚拟节点对应一台实际的服务器，如150:1 这样会大大减少负载波动。
《大型网站技术架构》读后感(十)：大型网站技术架构之路
这是一本入门级别的架构书，主要介绍了当下大型网络架构所需要的一些技术~突然发现现在国内所有的架构相关，大型网站相关的书全都是淘宝系的，果然只有遇到这些问题最多的人才最有经验~
如果以道术法来划分的乎，书中讲的基本都是道，架构的思想，以及架构师需要注意一些什么，真正具体的实践的话，涉及得很少，可能是因为实践遇到的问题千奇百怪，并没有那么大的普适意义吧~
如果你对架构不怎么了解的话，可以极力推荐这本入门的架构书~