《大型网站技术架构》是一本由李智慧著作，电子工业出版社出版的平装图书，本书定价：59.00元，页数：218，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《大型网站技术架构》读后感(一)：书的内容还可以，但是印刷质量太差，建议不要购买，对不起这个价格
前几天，犹豫了很久，同时入手了李智慧的《大型网站技术架构 核心原理与案例分析》和杨传辉的《大规模分布式存储系统 原理解析与架构实践》。一到手，看到李智慧的《大型网站技术架构 核心原理与案例分析》，没有开读，看到 【“电子工业出版社”】 印的书就后悔了。
标价同样是59的书。
李智慧的《大型网站技术架构 核心原理与案例分析》 218页， 封面还没开始用，就皱了。封面，一前，以后，扉页处的纸那是一个差，像是以前八九十年代，上厕所用的那种纸一样。刚送过来，封面就有点脱胶。【电子工业出版社】，你还敢更没有节操一点么？这样的书，真心担心看一次，就破烂不堪了。
内容还未看，不过看过封面，讲解的内容还是不错。虽然可能都是皮毛，但是提供了一个深入下去的方向。
而同样是阿里系出的， 杨传辉的《大规模分布式存储系统 原理解析与架构实践》，【机械工业出版社】 共293页， 比起 李智慧的《大型网站技术架构 核心原理与案例分析》，纸张和包装完全是属于精美的级别。书到手时，还有塑料封装。
阿里的这两本书，总的来说，书中讨论的内容还是不错。但是强烈鄙视【“电子工业出版社”】 这种无良出版商。
后面阅读完了，在进行后续的评价.....
《大型网站技术架构》读后感(二)：比较全面 有不少不错的观点
本文并没有什么特别的东西，但是都很实在，而且能很好的组织起来，也可以看为一个架构。
何为架构，要有大局观，大局观就是提前预防掉那些通用的问题：高可用，工程化，伸缩性，扩展性。对应需要的能力：了解分布式的一些东西，了解项目的业务和流程和运维使之工程化，了解负载均衡，能够对业务的分割和代码的分层。
文中其他的一些观点我倒是很喜欢：
1 先成就他人，再成就自己
2 刚开始加入的时候不要急于证明自己，要先融入。
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 这样会大大减少负载波动。
《大型网站技术架构》读后感(三)：比较全面，但不够深入
先吐个槽，虽说一本218页的书我也没期望能把某个知识点讲的很细，不过这讲得也太概括了。。。
言归正传，如果单从全面性上打分，那毫无疑问要给5分。从前端技术到后端优化，从架构改进到信息安全，一个架构师应该具备的技能都可以再这本书中找到身影。不夸张的说，如果可以把这本书里所提到的技能都掌握好，那么已经远超架构师的水准，可以直奔技术总监去了。
缺点上面也说了，因为摊子铺的太大，所以自然不可能面面俱到。或者更确切的说，应该是点到即止。看其他书评，很多在吐槽看个目录就好，内容几本没干货。回过头想想，这些知识点如果都写细了，那可以出一套大型网站技术架构丛书了~
其实我觉得我们可以换一种打开方式，这本书就好像给我们指出了一条道路，但是这条路要怎么走，还是需要我们自己去探索。况且这本书的知识体系很好，如果让我们自己去找资料，耗时费力不说，也不一定能够总结的这么好。
新手可以入门，老手可以当做备忘，总体上还是值得入手一本的。
《大型网站技术架构》读后感(四)：技术小白的入门书籍
不愧是架构师写的书，脉络清晰，条理分明。
非技术岗的我只是把他作为科普书籍来读，细节深入的部分也可以带过，并不影响了解全局。
以下读书建议也是针对我这类读者来说——
全书四大部分：
第一章概述可以重点阅读，即是概览亦是总结，对网站架构的搭建，形态演化，基础模式和核心要素有很全面清晰的阐述。读完可以了解整个网站架构的基本情况。
第二章针对网站架构的5大核心要素展开深入的说明，解读了每一个核心要素的检验标准和常见优化策略，不过具体到有些专业词汇还需要查阅其他资料，有些难懂。但是作者对基础知识点的解读已经足够让我这种技术小白理解。
第三章结合各大公司实例进行网站架构优化的分析，如果有实例工作经验的阅读起来可能会更有体会。
最后一章在说架构师，不管是什么职业岗位，有些道理总是相通的。
整本书读下来除了个别难懂的专业点，很顺畅，没有多余的套话，有些地方作者会插入自己的感性领悟，也能得到一些启发。
作为小白觉得最好的读此书方法是认真读第一章，然后通读第二章先理解纲领，再填充阅读，希望深入的部分继续补充阅读，最后两章可以轻松泛读。
《大型网站技术架构》读后感(五)：内容全面，适合技术支持、解决方案岗位阅读
对于规划、设计、架构、售前、技术支持等解决方案制作岗位人员，严重推荐，对工作很有帮助与指导意义。 对于开发、运维、集成等具体实施岗位人员，不推荐，仅能充当增广见闻的科普读物，对全局有个全面了解，对于日常工作没有帮助。
完美解决大型网站流量疏导需要做什么的问题，没有细说具体应该怎么做的问题。
如书中讲述疏导流量需要做基于用户位置的DNS再加负载均衡。但是不会告诉你是用开源的LVS，还是用windows server的网络负载平衡，还是用专用硬件，更不会告诉你搭建windows server网络负载平衡集群的每一步操作，或者具体的代码及命令行。
技术层面核心内容是:
前端:基于用户位置的DNS--租用CDN--负载均衡--反向代理服务器做缓存--负载均衡--web服务器集群。
后端:数据库主从复制--读写分离--分布式数据库--业务分库--数据库表拆分。
《大型网站技术架构》读后感(六)：不想当架构师的程序员不是好产品
对整个技术体系缺少整体认知的我，这本书给我一个整体的骨架感。
以前只做后端技术，喜欢研究算法，知识面比较窄。花1个小时看完第一章就有种神清气爽的感觉，忽然明白了那些大型网站，海量的淘宝是怎么架构出来的。
性能、可用性、伸缩性、扩展性和安全五大方面来阐述网站架构，从纵向的前端、应用、服务、数据，到横向的各模块交互，全面丰富的解构。
作者把复杂的问题简单的概括总结出来，对于互联网经验不够充足的我来说，这些知识整体、全面，学到作者的分析和理解能力，弥足珍贵。
最后不忘说说架构师应该如何和大家合作，如何更好工作的话题，说的相当在理，作者是想明白了的聪明过来人。
《大型网站技术架构》读后感(七)：大型网站技术架构之路
这是一本入门级别的架构书，主要介绍了当下大型网络架构所需要的一些技术~突然发现现在国内所有的架构相关，大型网站相关的书全都是淘宝系的，果然只有遇到这些问题最多的人才最有经验~
如果以道术法来划分的乎，书中讲的基本都是道，架构的思想，以及架构师需要注意一些什么，真正具体的实践的话，涉及得很少，可能是因为实践遇到的问题千奇百怪，并没有那么大的普适意义吧~
如果你对架构不怎么了解的话，可以极力推荐这本入门的架构书~
《大型网站技术架构》读后感(八)：对于某些人，我就呵呵了；对于本书，我还是买了
这年头网络很发达，几乎什么东西都可以down。有些聪明人，直接根据关键字google一下，信息也能获取个十之八九。
这年头知识不值钱，尤其是冷门小众的东西，国外分享的那么多，直接拿来用就是了。
而且，程序员大多内(闷)秀(骚)，写点漂亮的代码可以，追求妹纸这么的事情都表达不好，更别说出书了。
所以就冲着这本书深入浅出我也得掏钱买了，更何况里面的内容还真是不错呢。
大型网站技术架构，涉及方面很多，想全部讲个清楚，那至少得2000页，更何况，讲清楚你就能看懂了吗？任何NB的人，都是项目实战而来的。所以，那些认为内容太泛泛的人，可以you can you up
做事情最怕的是方向错了，做程序员也一样。而这本书，就是一个指明大方向的参考。
《大型网站技术架构》读后感(九)：读书笔记
大型网站的关注指标
高可用
高性能
易扩展
可伸缩
安全
大型网站的特点
高并发，大流量
高可用
海量数据
用户分布广泛，网络情况复杂
需求快速变更，发布频繁
渐进式发展
大型网站架构演化发展过程
初始阶段，一般使用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算法等
密钥安全管理
将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设置，对外提供加密和解密服务
将加解密算法放在应用系统中，密钥则放在独立服务器中，在存储时，将密钥切分成数片，分别存储在不同的介质中
《大型网站技术架构》读后感(十)：架构的科普书、入门书，有用即是好的
用了坐地铁的时间看完了本书，现在重新翻了前三章，梳理一下。
说一本书有没有价值，不是说作者有多么有名，不是说书讲得多么高深，让人看不懂（比如，小时候觉得余秋雨的书多么牛逼，晦涩的啥都看不懂），而是说读者看完书后能产生多少共鸣，多少为读者所用。
这本书就是一本对我产生价值的书。作者说，软件架构是指有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。书中先介绍了一个架构的简单发展史，然后分别讲了性能、可用性、伸缩性、扩展性、安全性等五个核心要素。
在架构发展史中，我们看到，不是所有网站上来都追求庞大的架构，而多是从LAMP开始，通过架构的分层、业务的分层进行扩展。从这点来看，公司的很多线上事故确实是由于架构不合理造成的。
由于工作原因，我重点关注了可用性部分。一个高可用网站的软件生产工艺，起码要关注以下几个方面：发布策略、自动化测试、预发布验证、代码的管理、自动化发布、灰度发布等。这些点我司一个都还没有做好，软件质量差也就不足为奇了。再加上实时监控、数据的冗余灾备，基本保证了网站的高可用。
后面有一个案例是讲淘宝技术架构发展的，可以结合《淘宝技术这十年》一起看。