第1章大道至简1
规则1——避免过度设计4
内容：
过度设计有2大类：
1、产品的设计和实施超过了实际（能够使用）的需求。
不需要追求完美设计，把握好开发尺度，否则浪费资源，增加维护成本和延长开发周期。
2、所完成的产品过于复杂
指把一件事情做得过于复杂和以复杂的方式去完成一个任务。让用户花费不必要的精力去完成一件事情。
简化操作步骤，提高用户体验和客服工作效率
应该把代码写得通俗易懂，复杂问题简单化，构思易于理解并可以维护的解决方案。
可以把这一项列为技术人员的能力评估之一。
规则2——方案中包括扩展9
内容：提供及时可扩展的DID方法
Design设计20倍的容量
Implement实施3倍的容量
Deploy部署1.5倍的容量
每个设计都应该有一套定义和指导如何设计架构原则和标准
每个开发项目开始前都先确定出完成目标，避免规则1的超出需求
规则3——三次简化方案13
内容：在设计复杂系统时，从项目的范围、设计和实施角度简化方案。
如何简化范围？
应用帕累托原则（也叫80-20原则）。收益的80%来自于20%的工作。如何删除不必要的功能，可以做5倍的工作。
如何简化方案设计？
缩窄项目范围，步骤要求易于理解、低成本、高效益和可扩展的方式来完成。
如何简化方案实施？
先模仿别人的合适的方案，只有都找不到的情况下，自己创建解决方案。
规则4——减少域名解析16
内容：从用户角度减少域名解析次数
用法：尽量减少下载页面所需的域名解析次数，但是保持与浏览器的并发连接平衡。
网页上大小差不多的文件，但下载时间却不同。测试插件（火狐Firebug）
每个页面改版前后都测试一下下载时间，是否比原来性能更好
网页上的域名解析的次数减少，网页的下载性能就越好。
这一条和之前的一本书上的说法矛盾的，另外一本是说把CSS,JS独立域名会更快。不知道这里说的域是独立一级域名还是也包含二级同域名，可以拿5sw首页做个测试。
规则5——减少页面目标19
内容：尽可能减少网页上的对象数量
用法：
·减少或者合并对象，但要平衡最大并发连接数
·寻找机会减轻对象的重量
·不断测试确保性能的提升
把同类的对象放在一个文件里，如小图标，合并为一个大图标，通过CSS来单独显示。
浏览器并发连接存在顶项是因为负责提供对象的每个域名服务都存在着资源限制。
因此，最好把网页的内容（CSS,JS，图片）拆分成足够多的对象数，比如把不同的网页对象分别存储在不同的子域名上。浏览器把这当成不同的域名对待，并允许每个子域名拥有自己的最大并发连接数。
这一条和上面的减少域名解析是矛盾的，所以怀疑是同域名，需要验证。
总之，页面上的对象越少性能越好，但是这必须与许多其他因素平衡。把CSS文件加载到页面的顶部，把JS方底部，缩小文件，使用缓存，延迟加载等优化技术。
规则6——采用同构网络23
内容：确保交换机和理由源于同一供应商
这个统一用的阿里，自己无须考虑，就是在选择配置的时候选择同一区域就好。
总结24
注释25
第2章分而治之27
规则7——X轴扩展31
内容：通常叫水平扩展，通过复制服务或数据库以分散事务处理带来的负载
用法：
·克隆服务的同时配置负载均衡器
·确保使用数据库的代码清楚读和写之间的区别
规则8——Y轴拆分35
规则9——Z轴拆分39
内容：根据客户的独特属性（ID,姓名...）进行拆分
总结41
·通过克隆扩展
·通过拆分不同的东西来扩展
·通过拆分类似的东西来扩展
注释42
第3章水平扩展43
规则10——向外扩展46
内容：通过复制或拆分服务或数据库而分散事务负载的方法，与此相对的是向上扩展，即通过购买更大的硬件而实现的扩展。
规则11——用商品化系统（金鱼而非汗血宝马）50
内容：尽可能采用小型廉价系统，只采购必要的容量
规则12——托管方案扩展53
内容：增加灾难恢复
规则13——利用云61
内容：有目的的利用云技术按需扩展
总结64
注释64
第4章先利其器65
规则14——适当使用数据库71
内容：选择适当的工具MYSQL，oracle，SQL
规则15——慎重使用防火墙80
内容：只有在能够显著降低风险时才使用防火墙。
并不是每样产品都值得动用防火墙耗费成本和降低可用性去保护。防火墙的决策，与所有其他业务决策一样，也应该权衡利弊么不能机械执行。
规则16——积极使用日志文件85
内容：使用应用日志文件来诊断和预防问题
日志对发现和确定问题有难以估量的价值。
总结88
注释89
第5章画龙点睛90
规则17——避免画蛇添足93
内容：避免翻来覆去的检查刚完成的工作或马上读取刚写入的数据。
规则18——停止重定向98
内容：如果有可能，避免重定向；确实需要时，采用正确的方法。
用法：如果需要重定向，考虑通过服务器配置来实现，而不是利用HTML或者其他基于代码的解决方案。
原因：重定向会延迟用户进程，消耗计算机资源，造成错误，不利于页面在搜索引擎中的排名。
规则19——放宽时间约束104
内容：尽可能放宽系统中的时间约束
总结107
注释107
第6章缓存为王109
规则20——利用CDN缓存113
内容：用CDN来减少网站的负载，图片、JS、CSS等一般都是静态的，可以缓存在CDN中
规则21——灵活管理缓存117
内容：使用Expires头来减少请求量，提高系统的可扩展性和性能。
用法：通过应用代码在网络服务器上设置头字节
误解：通过定义页面要素head中的meata标签来控制页面的缓存行文。但是，HTML中的meta标签是用来建议浏览器应该如何处理页面的，但很多浏览器不太注意这些。更糟糕的是，代理缓存不检查HTML
规则22——利用Ajax缓存120
内容：适当使用HTTP响应以确保Ajax调用可以缓存
原因：减少用户可感知的响应时间，增加用户满意度，提高平台或方案的可扩展性。
但是如果用得不好，也会产生一些独特的可扩展性约束。
确保可以在浏览器中缓存内容的三个关键要素分别是HTTP响应中的Cache-Control头、Expires头和Last-Modifed头。
目标是减少在网络上来回传输数据，以减少用户感知的响应时间和降低服务器的负载。因此，响应头中的Expires设置的有效期应足够长。
规则23——利用页面缓存128
内容：在网络服务的前端部署页面缓存
页面部署缓存是部署在网络服务器前面的缓存服务器，用来减少静态和动态对象对这些服务器的请求。
强调3点：
1、在网络服务器前面实施页面缓存
2、需要使用适当的HTTP头，以确保发挥内容缓存和结果缓存的最大潜在作用。
3、尽可能包括RFC2616中另外的HTTP头，这有助于最大限度的提高内存缓存能力。
规则24——利用应用缓存130
内容：使用应用缓存以成本效益方式扩展。
假设可以使用，确定可以最大化缓存的拆分方法。
规则25——利用对象缓存134
内容：实现对象缓存以帮助扩展持久层
用法：选择任何开源或有供应商支持的解决方案和在应用代码中实现
原因：实施相当简单的对象缓存可以节省大量应用或数据库服务器上的计算资源
最常见的实施是把缓存放在数据库层前面。
规则26——独立对象缓存137
内容：在架构中采用单独的对象缓存层
总结139
本章讨论了7个缓存规则。通过浏览器到网络，直到应用和数据库每个层次的缓存，可以显著的提高系统性能和可扩展性。
注释139
第7章前车之鉴141
规则27——失败乃成功之母144
规则28——不靠QA发现错误151
规则29——不能回滚注定失败155
内容：必须具备内容回滚的能力
用法：清理代码并准寻几个简单的步骤以确保可以回滚代码。
阿里服务器自带有回滚功能，
总结160
注释160
第8章重中之重162
规则30——从事务处理中清除商务智能164
内容：业务系统与产品系统分离、产品智能与数据库系统分离。
用法：把存储过程从数据库移到应用逻辑。在公司和产品系统之间不做同步调用。
不要把业务、流程相关的系统混合在一起。理想状态，是各个系统能依照各自的需求独立扩展。当所有系统捆绑在一起后，需求和被需求的系统要按照相同的速度扩展。
规则31——注意昂贵的关系168
内容：注意数据模型中的关系
用法：当设计数据库模型时，考虑数据库分离和未来可能的数据需求
当SQL查询由于连接表的需求而性能不佳时，有几个备选方案。首先是要调整查询语句。如果行不通，下一个选择是创建视图、物化视图、汇总表等，可以对表进行预处理。另外一种选择是不要在查询语句中连接，而是将数据集传回到应用中，并让应用在内存中进行连接。
SQL优化思路：
1、调整查询语句
2、合理使用视图
3、查询尽量不使用连接，而是将数据集传回到应用中，并让应用在内存中进行连接
目前后台统计里的部分功能很慢：应该是使用连接太多，列入后期研究解决项目。
规则32——正确使用数据库锁172
内容：理解如何使用明锁在监控暗锁
用法：在代码中查时注意明锁。监控数据库暗锁，并在必要时进行明确调整以保证适度的吞吐量。选择允许锁类型和粒度灵活性的数据库与存储引擎。
实际未操作过，术语不理解，需要深入学习下是怎么操作的
规则33——禁用分阶段提交176
内容：不要使用分阶段提交协议来存储或处理事务
实际未操作过，术语不理解，需要深入学习下是怎么操作的
规则34——慎用Select for Update178
内容：定义游标时，select语句中尽量少用for update子句
要点：游标在使用得体时，它能使程序更快、更容易。但for update游标可能导致长时间占有锁，而且减缓事物完成时间。
网站没有用到
规则35——避免选择所有列181
内容：不要在查询中使用select *
用法：始终在查询语句中声明你要选择或插入数据的列
网站有地方有使用到 * ，花时间排查一下
总结183
第八章主要讲的是数据库的规则
注释184
第9章有备无患185
规则36——用“泳道”隔离故障188
内容：在设计中实现故障隔离区或泳道
泳道是围绕设立故障隔离域提出的架构概念。
泳道的原则：
1、泳道之间什么都不共享
2、泳道之间不进行同步调用
3、当绝对必要时如何实现跨越泳道边界的异步传输
故障隔离原则：
不共享 泳道不共享服务。但可以接受共享一些诸如边界理由器和负载均衡器的网络设备。
在泳道之间不进行同步调用 泳道是不可以进行跨越边界进行同步调用的最小单位
限制泳道之间的异步调用 尽管允许，但应限制泳道间的异步调用。调用越多，故障蔓延的机会就越大
异步调用设置超时和开关控制 异步调用应设置超时，因其他服务失败，必要时可关闭调用
规则37——拒绝单点故障194
内容：永远不要实施会带有单点故障的设计，一直要消除单点故障
规则38——避免系统串联198
规则39——启用与禁用功能201
内容：搭建一个框架来启用与禁用产品的功能
方法 描述 优点 缺点
超时自动关闭 当调用第三方服务变慢时，将该功能关闭，直到认为干预重启 防止影响其他服务 容易受到错误的故障的影响。
替代服务 当某个服务发生故障时，取代该服务 可以让用户自己判断是否故障 关闭服务可能比较慢，可能需要用户的干预才能关闭
人工关闭 管理员发出信号/命令来停止某个响应缓慢的功能 人工确定出现故障的服务 比自动关闭慢。
利用配置文件关闭 改变配置文件中参数以指示关闭服务 不必依靠像命令这样的请求 很可能要求重启服务
利用文件关闭 凭借一个文件的存在与否标识某个功能是否可用 不必像同步命令那样依靠请求/应答模式进行通信 可能会因为每个请求都需要检查文件的存在，所以比较慢
运行时的变量 在启动时作为入口参数读入程序，然后像守护进程一样运行 与配置文件类似 与配置文件类似
总结205
第10章超然物外206
规则40——力求无状态208
规则41——在浏览器中保存会话数据211
内容：彻底避免会员数据，但需要时，考虑把数据保存在用户的浏览器中。
用法：在用户的浏览器中使用cookie来保存会话数据
得防止数据被劫持？可以使用https发送页面和cookie。
在实施中，控制cookie大小至关重要。数据过多会降低页面加载以及系统WEB服务器的性能。
规则42——用分布式缓存处理状态213
内容：使用分布式缓存在系统中存储会话数据
分布式缓存的禁忌：
·不要实施必须对服务器有粘度才能正常工作的系统
·不要使用状态或会话复制来产生不同系统上的数据副本
·不要把缓存放在执行任务的系统上。这并不意味着不应该有本地应用缓存，只是最好把会话信息放在本层或服务器上。
总结216
注释217
第11章异步通信218
规则43——尽可能异步通信220
内容：尽可能优先考虑异步通信而不是同步通信
规则44——扩展消息总线224
内容：同任何物理或逻辑系统一样，消息总线也会因需求而失败。所以它们也需要扩展
我们在技术架构中发现的最常见故障之一，也常称为企业服务总线或消息总线的巨大单点故障。
规则45——避免总线过度拥挤229
总结233
第12章意犹未尽234
规则46——警惕第三方方案237
内容：不要依赖供应商的解决方案来实现可扩展性
主动权要掌握在自己的手上，保持架构的简单，降低总的成本。
防止供应商或服务商说停止就停止，命运要掌握在自己的手上
规则47——梯级存储策略240
内容：将存储成本与数据价值匹配，包括删除价值低于存储成本的数据。
现在用的云存储，他们自己有做相关优化
规则48——分类处理不同负载246
内容：通过分区和故障隔离，处理独特的工作负载，以最大限度的提高整体的可用性，可扩展性和成本效益。
规则49——完善监控250
内容：想想在设计时需要考虑什么才能监控应用
现在用的是阿里云盾，除非是自己购买的服务器放机房才需要考虑
规则50——保持竞争力255
内容：让架构的每个组成部分都有竞争力或认同竞争力
可以购买解决方案，但必须在部署和维护时保持竞争力。
技术可以找人开发，但是流程和服务等必须有自己独特的解决方案
总结257
注释258
第13章谋定而动259
用风险收益模型评估可扩展性项目和举措259
50条可扩展性规则简述264
可扩展性规则的利益与优先级排行榜297
总结300
可参考测试的规则：以下数字对应相应的规则数
策划、代码、前端优化手段类：
1、避免过度设计
2、方案中包括扩展
3、三次简化方案
4、减少域名解析
5、减少页面目标
18、停止重定向
20、利用CND缓存
21、灵活管理缓存
22、利用Ajax缓存
23、利用页面缓存
24、利用应用缓存
25、利用对象缓存
41、在浏览器中保存会话数据
SQL类：
32、正确使用数据库锁
33、禁用分阶段提交
34、慎用SELECT FOR Update
35、避免选择所有列
SQL优化思路：
---调整查询语句
---合理使用视图
---查询尽量不使用连接，而是将数据集传回到应用中，并让应用在内存中进行连接
目前后台统计里的部分功能很慢：应该是使用连接太多，列入后期研究解决项目。
第三方合作：
46、警惕第三方方案
50、保持竞争力
其他的规则有的是用上了阿里的云服务，他们自己有做相关的工作；有的是专业术语未看懂，需要进一步去学习。
（2018-3-7）
网友评论