1. 互连层是可以真正构建高可用性的地方

1.1. 流量管理

1.2. 负载均衡

1.3. 服务发现

2. 不同规模的解决方案

2.1. 在小公司中

2.1.1. 只有少数开发人员的小企业可以直接使用DNS条目

2.1.2. 生成变更的开发人员较少，变更频度变低

2.1.3. 可能根本就没有独立的运维团队

2.1.4. 所有的开发人员都一起工作、一起吃饭

2.2. 在大型公司中

2.2.1. 服务发现

2.2.1.1. 可以处理服务的频繁变更，同时也能处理这些服务中实例位置的频繁变更

2.2.1.2. 本身就是另一个服务，所以它能增大运维团队的影响力

2.2.1.3. 在一家大公司，每个开发人员都不会知道其他开发人员做出的变更

2.2.1.3.1. 让服务消费方随时跟进其服务提供方IP地址的变更是不现实的

2.2.1.3.2. 在高度虚拟化、云或容器基础设施中尤其如此

3. 使用DNS

3.1. 当服务不经常发生变动时适合使用DNS

3.2. 对小型团队来说，直接使用DNS可能是最佳选择，特别是在基础设施变动不频繁的时候，这样的基础设施包括专用的物理机和长期使用的虚拟机

3.3. IP地址会比较稳定，DNS就有了用武之地

3.4. 当客户端去调用服务时，该服务提供方可能只有一个DNS名字，这意味着提供方负责负载均衡和高可用性

3.5. 提供方有多个DNS名字，那么负载均衡和高可用性就需要由调用方负责了

3.6. 服务发现是人际交互的过程，之后在配置中设置DNS名字

3.7. 团队需要找到服务所有者，并努力从他们那获取某个或全部DNS名字

3.8. 当使用DNS时，要通过一个逻辑服务名字（而不是物理主机名）来调用

3.9. 只须在一个地方（域名服务器的数据库）而不是每个消费应用程序中修改别名

4. 基于DNS的负载均衡

4.1. DNS轮询负载均衡调度是最早的技术之一

4.1.1. 提供了一种低成本的负载均衡方式

4.1.2. 轮询机制分配IP地址并不能保证负载被均匀分配，均匀分配仅在初始连接时发生

4.1.3. 当其中一个实例变得繁忙时，DNS服务器也是无法知晓的，它只会一直把某个特定连接分配到这个“步履蹒跚”的实例

4.1.4. 该技术在OSI模型的应用层（第7层）上执行

4.1.5. 在地址解析期间（而不是服务请求期间）有效

4.2. 前端IP地址对客户端可见且可访问

4.3. 客户端掌握了过多的控制权，这是DNS轮询的一个缺陷

4.4. 当调用方是长期运行的企业系统时，也不适用DNS轮询负载均衡

5. 基于DNS的GSLB

5.1. global server load balancing 全局服务器负载均衡

5.2. 普通DNS服务器只包含域名和地址的静态数据库

5.3. GSLB服务器还能够追踪实例池的健康状况和响应能力，只对外提供那些通过了健康状况检查的底层地址

5.4. 不同的GSLB服务器会为同一请求返回不同的IP地址

5.4.1. 可以在多个本地池间实现负载均衡

5.4.2. 为客户端提供最近的访问点

5.4.2.1. 会优先把流量发给最近的实例池

5.5. 全局流量管理器可以为选择路由搜集大量的相关信息

5.5.1. 当全局流量管理器与本地负载均衡器结合使用时，DNS的优势能有效发挥

5.6. 会使用加权分布和一系列负载均衡算法，用于灾难恢复策略，甚至可以用作滚动部署过程

6. DNS的可用性

6.1. DNS的价值在于其服务器可以满足地址解析的请求

6.2. DNS属于基础设施中不可见的那部分

6.3. DNS服务的中断会导致重大的事故

6.4. 不要将DNS服务器托管在与生产环境相同的基础设施上

6.5. 要确保有两个或两个以上的DNS服务提供方，且其服务器位于不同的地点

6.6. 公共系统状态监控页面需要使用不同的DNS服务提供方

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