【资料图】

1.第一个拥有10亿用户的网站

1.1.2016年，Facebook宣布其每日活跃用户数量为11.3亿

1.2.对整个应用程序来说，“五个9”的可靠性远远不够，这每天会让成千上万的用户失望

1.3.假如按照六西格玛质量标准来衡量，那么Facebook每天会惹怒768000个用户

1.4.每页200个请求，每日11.3亿个活跃用户，每百万次机会有3.4个缺陷

2.当集成一个个的系统时，系统相互之间的紧耦合就会变为常态

2.1.大型系统往往比小型系统更快地陷入失效

2.2.紧耦合会令系统某一部分的裂纹开始蔓延并成倍增大，最终跨越层级或系统的边界

3.问题膨胀

3.1.轻微的失误转化为重大的系统失效

3.2.冷却监控和控制系统中隐藏的连锁反应，就是导致美国三里岛核反应堆事故的部分原因

4.每一个反模式都会在系统中产生、加速或增加裂纹

4.1.仅仅避免使用这些反模式还不够，因为所有事物都会出问题，失误不可能避免

4.2.不要假装可以消除所有可能的失误来源，无论是系统本身的失误还是人为引起的失误

4.3.要做最坏的假设，失误肯定会发生

5.集成点

5.1.集成点是系统的头号杀手

5.2.所有的都是集成项目

5.3.蝴蝶图

5.4.蜘蛛图

5.4.1.精心设计

5.4.2.随意设置

5.5.所有这些连接都是集成点，它们中的每一个都有可能破坏系统

5.6.小型服务的数量设计得越多，与SaaS提供商的整合程度就越高，越是采用API优先的策略，越会让情况变得更糟

6.套接字协议

6.1.较高层级的许多集成协议通过套接字运行

6.2.除了命名管道和进程间通信（共享内存），几乎所有的通信都基于套接字来实现

6.3.最简单的系统失效方式是远程系统拒绝连接

6.4.TCP部分则是一个关于如何在离散的数据包基础上，构建出看似连续连接的协议

6.4.1.TCP还定义了“同时打开”的握手方式，即在发送SYN/ACK之前，这两台机器会互相发送SYN数据包。然而在基于客户端-服务器交互的系统中，这是相对少见的

6.5.如果想要结束阻塞调用，就必须设置套接字超时时间。在超时情况下，程序能够处理相关的异常

6.6.网络系统失效按速度分为快慢两种

6.6.1.快速的网络系统失效，会让调用代码立即出现异常

6.6.1.1.“拒绝连接”是非常快速的系统失效，只需要几毫秒的时间就能返回给调用方

6.6.2.缓慢的系统失效，比如一个被丢弃的ACK，会让线程在抛出异常之前被阻塞几分钟

6.6.2.1.一个缓慢的响应比没有响应糟糕得多

6.7.问题

6.7.1.防火墙内的“已建立连接”表

6.7.1.1.该表是有时长限制的

6.7.1.2.即使TCP本身允许无限时长的连接，该表也不允许

6.7.1.3.防火墙丢弃了这些数据包，而不是通知发送方无法到达目标主机

6.7.1.4.闲置时长会轻松超过防火墙中配置的1小时闲置连接超时

6.7.2.TCP从来也不是为处于网络连接中间的那种智能设备而设计的，任何第三方都无法告诉连接终端它们的连接正在被拆除

6.8.方案

6.8.1.ping数据包本身就是解决方案所需要的，其可以用来重置防火墙连接的“最后数据包”时间，可以使连接保持活动状态

6.8.2.“无效连接检测”既能让连接保持活动状态，又可以让人睡个安稳觉

6.8.3.为了更好地理解问题，需要知道如何继续深入至少两个抽象层次，才能了解层次的“实际情况”，找到问题所在

6.9.tcpdump是从网络接口捕获数据包的常用UNIX工具

6.10.Wireshark可以在网线上嗅探数据包

6.10.1.类似tcpdump，但它也能在图形用户界面中显示数据包的结构

6.10.2.需要在X Window系统上运行

6.10.2.1.无法安装在Docker容器或AWS实例中

7.HTTP协议

7.1.所有基于HTTP的协议都使用套接字

7.2.可能会给调用方带来的影响

7.2.1.服务提供方可能会接受TCP连接，但不会响应HTTP请求

7.2.2.服务提供方可以接受连接但不能读取请求

7.2.3.服务提供方可能会发回调用方不知道该如何处理的响应状态

7.2.4.在服务提供方发回的响应中，可能带有调用方不期望或不知道如何处理的内容类型

7.2.4.1.当DNS查找失败时，互联网服务提供商可能会注入一个HTML页面

7.2.5.服务提供方可能声称要发送JSON，但实际上发送了纯文本，或者是内核二进制文件，抑或是Weird Al Yankovic创作的MP3音乐

7.3.建议

7.3.1.避免使用那些将响应直接映射到领域对象的客户端程序库

7.3.2.要将响应视为数据，除非已经确认响应符合设计预期

8.供应商的API程序库

8.1.阻塞是影响供应商API程序库稳定性的首要问题

8.1.1.无论是内部资源池、套接字读取指令、HTTP连接，还是最一般的Java序列化，处处可以发现不安全的编程实践

8.2.供应商可能会对其销售的服务器软件进行强化，但对客户端API程序库则很少这样做

8.3.程序库的代码只是出自常规开发工程师之手，与其他任何随机抽样的代码一样，在质量、风格和安全性等方面具有不稳定性

8.4.它们几乎不受控制

8.5.需要等待供应商官方补丁版本