1. 控制请求数量

1.1. 这个世界可以随时摧毁我们的系统

1.1.1. 要么拒绝工作

1.1.2. 要么扩展容量

1.1.3. 没有人会在与世隔绝的环境中使用服务，现在的服务大多必须处理互联网规模的负载

1.2. 系统的每次失效，都源自某个等待队列

1.3. 每个请求都会在它所经过的每一层上占用一个套接字，当请求被实例处理后，该实例就临时少了一个处理其他新请求的套接字

1.4. 可用套接字数量与服务每秒可以处理的请求数量之间存在一定关系，这取决于请求处理的持续时间

1.5. 服务完成请求处理的速度越快，其可处理的吞吐量就越高

1.6. 以太网本质上就是一个串行协议

1.6.1. 把数据包“放到”导线上需要时间，在端口繁忙时，任何待发送的数据包都必须排队

1.6.2. 当写入缓冲区已满时，TCP协议栈将不会接受任何新的写入，并且write调用将被阻塞

1.7. 服务器套接字上的“监听队列”

1.7.1. 如果监听队列已满，那么尝试连接的客户端会进行一系列的重试，最终放弃连接

1.8. 甩负载

1.8.1. 是控制传入请求数量的首要方式

1.8.2. 在高负载情况下最好把那些无法及时完成的工作“挡在门外”

1.8.3. 当套接字监听队列已满时，就可以快速进行甩负载，快速拒绝胜于慢速超时

1.8.4. 尽可能在网络的边缘拒绝额外的请求

1.8.4.1. 能尽早甩负载，从而避免在拒绝请求之前就已经占满多个层级上的资源

1.8.4.2. 请求进入系统越深，占用的资源就越多

1.8.5. 提供健康状况检查，允许负载均衡器保护应用程序

1.8.6. 服务可以通过度量自身响应时间，来协助解决高负载的问题

1.8.6.1. 检查自身的运维状态，查看是否能及时回复请求

1.8.7. 在因响应时间过长引发访问重试时，开始拒绝请求

1.8.8. 服务也应该有相对较短的监听队列

1.8.8.1. 每个请求都会在监听队列中等待一些时间，并花一些时间进行处理，称这两个时间之和为“驻留时间”

1.8.8.2. 监听队列是串行的，而处理是多线程的，所以排队时间最终会比处理时间要长

1.8.9. 需要知道该服务是直接面向互联网（适用于所有实用场景，请求数量无限），还是仅向内部开放（请求数量有限）

1.9. TIME WAIT

1.9.1. 关闭的套接字会在TIME_WAIT状态下保持一段时间，来让所有在互联网上游荡的“掉队”的包超时，或在其到达时被丢弃

1.9.2. 由于当前客户端并没有发送这些数据，因此导致TCP流不再同步。这样的数据包就被称为bogon

1.9.2.1. IME_WAIT则可以防止系统出现这种情况

2. 网络路由

2.1. 服务器必须要知道使用哪个接口才能访问特定的目标IP地址

2.1.1. 服务器的前端网络接口接入一个虚拟局域网与Web服务器通信

2.1.2. 服务器的后端网络接口接入另一个虚拟局域网与数据库服务器通信

2.1.3. 当涉及远程服务时（可能是第三方服务），路由就会变得更复杂

2.2. 现代操作系统力图使路由自动发生且不可见

2.2.1. 当一台服务器启动其主网卡时（只要操作系统认定其为主网卡），会将该网卡的主IP地址当作其“默认网关”，并将这个网关作为这台主机的路由表中的第一个条目

2.3. 总会出现的错误比间歇性的成功要好得多

2.4. 静态路由定义

2.4.1. 网络管理员对外都不赞同使用静态路由，但有时这是唯一可行的方法

2.5. 软件定义网络

2.5.1. 与虚拟化基础设施和基于容器的基础设施密切相关

2.5.2. 容器和虚拟机使用虚拟IP地址、虚拟局域网标记和虚拟交换机来创建一种“网络上的网络”

2.5.3. 数据包仍然在相同的网线上流动，但主机的IP地址不再牵涉其中，这就实现了虚拟交换机在物理交换机之外独立运维

2.6. 错误地配置路由，不仅会降低系统的可用性，还会泄露客户数据

2.7. 所有远程系统连接都应该使用电子表格或数据库来记录目标主机名字、地址和所需路由

2.7.1. 有人会需要这些信息来编写防火墙规则

3. 发现服务

3.1. 组织有太多的服务，使用DNS管理

3.2. 部署环境高度活跃

3.3. 调用方至少需要知道一个IP地址，才能访问某个特定服务

3.4. 可以在分布式数据存储（例如Apache ZooKeeper或etcd）上创建服务发现机制

4. 迁移虚拟IP地址

4.1. 虚拟IP地址意味着一个IP地址不会与一个以太网MAC地址严格绑定

4.2. 负载均衡器会使用虚拟IP地址将多个服务（每个都有自己的IP地址）复用到数量较少的物理接口上

4.3. IP地址的迁移通常用于通过主动方式和被动方式实现的数据库集群

4.3.1. 不能迁移应用程序内存中的状态

4.3.2. 所有非持久化的交互状态都将丢失

4.3.3. 任何通过虚拟IP地址调用数据库的应用程序，都应做好在发生此类故障转移时收到SQLException的“心理准备”