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伺服器可以工作