Context
这是第一篇读书笔记，最近看了几本有点厉害的书。我担心我看了之后又忘记了，所以还是有必要记录一下的。
Note
这本书是一个很多年工作经验的架构师大神根据自己的各种亲身经历总结出来的一些东西。总共分为4个部分:稳定性、容量、一般设计问题、运营。
目前呢，我才读到了178页，差不多是第四部分运营的一半位置，所以这本书终于将要被我读完了！
这本书读的时间很长，因为他不是一本工具书，它是一本和小说一样的书，通过各种故事来引出问题和解决方案。有时候一些情况是我现在无法理解的，因为我还没有接触过作者大大所做的那种超高并发，大用户，等复杂场景。也有可能是因为作者大大做的系统都是从最最最底层开始一直垒到最顶层的，而我现在都是使用各种框架，把最难的部分或者最可能出问题的部分交给了其他大佬们去解决了。
其实这个并不是最好的习惯，因为在书的P35就提到了一个点厂商API库，这里说有时候我们使用的第三方API被封装的特别漂亮，但是其实他的实现非常丑陋，甚至存在很多的缺陷～但是其实我们这些小角色现在也只能抱怨抱怨，因为并没有能力和时间去修改它～～
Chapters
讲一下这本书的四个部分都是什么具体内容吧～
目录其实可以在网上查到，所以我也不说了。但是这四个部分讲的内容大概是什么我倒可以稍微概括一下，因为说不定未来遇到了问题，可以很针对性的去找对应的章节。
注意，下面被这样标记的部分就是书中原话的意思～
第一章:稳定性
这一章介绍了稳定性反模式和稳定性模式，其中稳定性反模式指的是一些设计会导致导致没考虑到的小问题被方法，导致系统快速的崩溃。而使用稳定性模式，就可以降低这种崩溃的风险。
在介绍稳定性的时候讲到了故障链，这其实很好理解，一个很小的故障，导致了另一个未知故障的发生，进而导致另另一个未知故障的发生，进而满满的发现所有的模块都爆了。就像什么火箭飞船飞机什么的，一开始发现一个很小的异常，然后慢慢地慢慢地，全屏都是error然后爆炸了～
这一章讲到了一个凌晨5点崩溃的故事，说的是一个服务器每天凌晨5点都会死掉。我相信这套系统在测试阶段应该没有出现过这种问题，但是在生产服务器中，却出现了这个崩溃问题。作者通过获取故障服务器的线程转储(我并不知道这是什么)，tcpdump抓包，分析得到这个崩溃是由TCP链接的不对称导致的。
TCP如果双方都不通知对方，这个链接中断了，那么即使物理线路真的断了，那他们也以为没有断。而在生产服务器中，又一个防火墙角色的存在，导致情况变得更加复杂。
防火墙检查到外部节点超过若干时间没有和本机通信了，便会移除防火墙里面的记录，导致后续外部节点再次通信产生失败。这这个例子中，防火墙保护了数据库服务器，而链接数据库服务器的应用服务器，由于过了一个晚上的休息时间，使得防火墙中对应的记录都被删除了，所以应用服务器再也无法跟数据库服务器进行通信了，于是这些线程全部被阻塞了，最终系统崩溃了。
虽然这个故事讲的并不是生产环境和测试环境的事情，但是我觉得这个故事我对他印象还是很深刻的。
之后说了连锁反应， 假设分布式服务器集群有若干台，他们的故障概率为x，那么当某一台服务器挂了之后，剩下的负载服务器的故障概率就会升高，因为他们分担了之前服务器的负载。以此类推，当更多的服务器挂掉之后，剩下的服务器的故障概率会变得高的可怕，说不定就会导致系统崩溃。
用户是可怕的，每个用户都好用了更多的内存，这应该不需要再解释了。
无共享,在软件设计的时候我还是挺喜欢使用单例的，因为这是一个全局的东西，可以被各个模块共享使用。但是在系统架构时，为了可扩展性，会希望无共享架构。但是无共享会导致失效备援能力变弱。所以大佬的建议是:减少共享资源。我理解就是除了那些必不可少的资源需要共享，其他的资源可以通过让两个应用服务器彼此做备援服务器的方法来实现援救。
去耦合中间件这个不好解释，总是中间件很有用就对了，’通过完全姐耦合来避免大部分失效模式’
这一章写了那么多，因为他竟然有94页！所以看得我心力憔悴。
第二章:容量
这一章看名字就大概明白意思了。各种暴力环境呗。大用户，高并发，大容量储存，之类的…
写几个印象深刻的点：
容量的神话: 1.”CPU很便宜”。但是机箱很贵啊！4个CPU用一个机箱，那5个CPU可能就需要2个机箱，此时每个CPU的成本就被抬高了啊。2.”存储很便宜”。但是服务器不止一台，而且需要考虑RAID的影响，操作系统大小，应用程序大小等等。所以购买的容量远远小于可以储存数据的容量。根据乘法效应来算，这储存还是挺贵的。3.”带宽很便宜”。现在一般两种带宽服务，按时间计费，固定带宽不限流量，每月支付固定的金额；按流量支付，每月流量小于一个阈值，就可以支付稍低的固定费用，但是如果流量超出则会付出惨痛的代价。于是讨厌的爬虫脚本，或者服务器中传输垃圾信息(每次1kb，累计起来也是钱啊)都会导致带宽变得很昂贵。
JSON的黑暗面这个其实不难理解，因为有的程序员会使用json来执行函数或者命令，这个操作是很有风险的，万一个黑客猜到了，就完蛋了。
昂贵的空白图片,多余的HTML表格,刷新按钮,空白->这些都是HTML中浪费的空间，他们虽然不会影响什么，但是，会浪费很多的流量(都是钱啊！)
‘海外来的RMI’， 这个故事我还没看懂～。～
第三章:一般设计问题
虚拟IP地址，使用虚拟IP地址，可以用作失效备援。一堆失效备援服务器一个作为主动运行服务器，另一台作为备援服务器，他们有自己真实的IP，也会有一个虚拟IP。但是虚拟IP只会指向正在运作的主要服务器，当主要服务器故障之后，便通过将备用服务器迁移到这个虚拟IP上来保证服务可用。
第四章:运营
这一章还没看完，不着急。
注意，上面被这样标记的部分就是书中原话的意思～
End
嗯，这是看了那么多一口气写的笔记，所以花了我2小时的时间，下次读书笔记还是一边读一遍写吧！