lyingSeven的博客

读后总结与感想兼导读

混沌工程

适应性

版本问题

为部署而设计

控制层

控制层

安全性

安全性

互联层之路由和服务

负载均衡器是系统服务中不可或缺的组成部分，不能将其仅仅视为网络基础设施的一部分

要确保在系统失效时至少有一台DNS服务器可以工作

对早期人类来说，那些能探知不存在的模式的人比不能探知真实模式的人更容易将基因传递下来

只要将配置信息存放在与源代码不同的存储库中，将其锁好，仅对有权访问的人开放，并且管理员能够根据过程、程序和执行人等授予或撤销对相关配置信息的访问权限，那么配置信息也可以存放在版本控制系统中

“一层层抹泥”的方法更新机器的状态有两大挑战

如今通过足够多的主机保证各个服务的负载均衡，使得单台主机的损失不再是灾难性的

在生产环境中配置多个网络接口的另一种常见方法，是绑定或分组

由于集成点是导致系统不稳定的首要原因，因此“既可集成，又能解耦”是件好事

让服务器通过限制自己的工作量保护自己

有时，为了实现系统级稳定性，放弃组件级稳定性就是所能做的最好的事情

定时刷新缓存是最简单的缓存失效机制

断路器能有效防止集成点、层叠失效、系统容量失衡和响应缓慢等危及稳定性的反模式出现，它能与超时模式紧密协作，跟踪调用超时失败

使用通用网关为连接处理、错误处理、查询执行和结果处理提供模板

SELECT TOP 15 colspec FROM tablespec -- Oracle（since 8i） SELECT colspec FROM tablespec WHERE rownum ＜= 15 -- MySQL and PostgreSQL SELECT colspec FROM tablespec LIMIT 15

快速返回系统失效信息，能使调用方的系统快速完成事务处理，最终成功或是系统失效，取决于应用程序的逻辑

如果系统具有韧性，那么它可能会减慢处理速度，甚至当无法在允许的时间内处理事务时，就开始出现“快速失败”

在所有可行的方案中，选择最简单的那个来做

5.2.2.1. 将其控制在不进行缓存所用时间以内。

5.5.2.2. 在创建弱引用对象时，可以将大型或昂贵的对象作为其有效载荷。7.4.2.1. 可以调小TIME_WAIT间隔，尽快恢复使用这些端口。5.5.2.1. 当该对象的引用只剩下软引用时，则软引用就可以被回收。7.4.3.1. 互联网上的bogon是一个真实但影响较小的问题。5.5.2.3. 垃圾回收对象都是有效载荷，而不是弱引用本身。7.2.2.1. 最多可以有64511个连接。3.2.2.1. 数量庞大而非常危险。7.3.3.1. 需要很多内核缓冲区。3.2.1.1. 高级持久威胁。

没有设置超时时间的集成点，必定会导致层叠失效

6.6.1.1. “拒绝连接”是非常快速的系统失效，只需要几毫秒的时间就能返回给调用方6.10.2.1. 无法安装在Docker容器或AWS实例中。

10.5.5.1. 调用方知道可能永远不会收到回复，因此它必须将其作为处理协议本身的一部分来处理。10.5.3.2. 被阻塞的那些调用方会一直等待从CF系统的EJB中读取它们期待的响应。10.5.4.1. 其中一个服务组出现的问题就不会拖垮CF系统的所有用户。1.1.2.1. 如果一个系统只能处理一种事务，那么它就是专用系统。1.1.2.2. 混合工作负载是系统能处理的不同事务类型的组合。1.8.2.2. 在边界或外部接口处发生的不受控制的状况。1.2.1.2. 庞大的多层应用程序和服务器网络。

5.2.1.1. 软件事故的事后分析实际上更难完成，因为事件结束了，没有留下可供分析的实物。

务实的架构师更可能讨论诸如内存使用情况、CPU的需求、带宽的需求，以及超线程和CPU绑定的优缺点等问题