1. 面向恢復的計算

1.1. ROC,recovery-oriented computing

1.2. 加州大學伯克利分校和斯坦福大學的聯合研究專案

1.2.1. 其大部分作業致力于消除系統失效的根源，但也承認系統失效不可避免

1.2.2. 旨在提高系統面臨失效時的生存能力

1.3. 創始原則

1.3.1. 無論在硬體方面還是軟體方面，失效都是不可避免的

1.3.2. 建模和分析永遠都不會足夠完備，用推導的方法預測所有系統失效方式是不可能的

1.3.3. 人的行為是系統失效的主要原因

1.4. 如果在每次配置更改后，都必須重新啟動那些服務器，則無法恢復服務

1.5. 重啟組件而不是重啟整臺服務器的能力，是面向恢復的計算的一個關鍵概念

1.5.1. 在不重啟所有服務器的情況下恢復服務

1.5.2. 花費超過6小時的時間來完成所有服務器的重啟

1.5.3. 僅僅動態重新配置和重啟連接池這件事，只需不到5分鐘的時間

2. 為生產環境而設計

2.1. 將在生產環境中發現的問題視為頭等大事

2.2. 為執行運維操作的人們而設計

2.3. 圖示

3. 基礎層

3.1. 了解系統的物理基礎設施

3.2. 系統所有其他部分所依賴的機器和電纜

3.3. 厘清有關網路、主機名和IP地址之類的事情

3.4. 考慮持有代碼的那些設備：物理主機、虛擬機和容器等

3.5. 當系統跨越多個資料中心時會出現的一些特殊問題

4. 資料中心和云端的聯網

4.1. 相比桌面網路，包含更多冗余和安全性建設

4.2. 聯網時最大的誤解就是機器的主機名

4.3. 主機名可以用兩種方式來定義

4.3.1. 主機名是作業系統用來識別自身的名字

4.3.1.1. 機器的管理員可以設定該主機名和“默認搜索域”，將主機名和搜索域拼接在一起就構成了FQDN（全限定域名）

4.3.1.2. 即在運行hostname命令時所看到的內容

4.3.2. 系統的外部名字

4.3.2.1. 其他計算機希望使用這樣的主機名連接到目標機器

4.3.3. 無法保證機器自身的FQDN與DNS為該機器的IP地址所提供的FQDN相匹配

4.4. 兩個定義的根本區別

4.4.1. 機器使用其主機名標識整個機器

4.4.2. DNS名字僅用來標識IP地址，多個DNS名字可以被決議為同一個IP地址

4.4.3. 對負載均衡服務來說，一個DNS名字也可以被決議為多個IP地址，這意味著“DNS名字到IP地址”是一種“多對多”的關系

4.4.4. 許多實用程式和應用程式都假定機器自分配的FQDN是合法的DNS名字，決議后不會發生改變

4.4.4.1. 對開發機器來說基本上是正確的，但對生產環境的服務來說一般是錯誤的

4.5. 多網卡的多對多的關系

4.5.1. 一臺機器可能有多個網卡

4.5.2. 每個網卡可以連接到不同的網路，每個活動的網卡能在其特定網路上獲取IP地址，這被稱為多宿主（multihoming）

4.5.3. 資料中心中的每臺服務器一般都是多宿主的

4.5.4. 不知道存在多個網路介面的應用程式，最終就容易接受來自錯誤網路的連接

5. 備份操作

5.1. 會以突發的方式傳輸巨量的資料

5.2. 如果備份發生在生產環境網路上就會堵塞網路

5.3. 良好的資料中心網路設計，是將備份用的資料流量分流到其專用的網段上

5.3.1. 由單獨的交換機處理

5.3.2. 由生產環境交換機上的單獨虛擬局域網處理

5.4. 備份流量從生產環境網路中分離出來后，當執行備份操作時，應用程式用戶不會因此受到影響

6. 多網路編程

6.1. 默認情況下，監聽一個套接字的應用程式，會監聽所有網路介面上的連接請求

6.2. 編程語言庫總是有一個“簡單”的套接字監聽版本，這個“簡單”版本只是在主機的每個網路介面上打開一個套接字

6.3. 在生產環境中配置多個網路介面的另一種常見方法，是系結或分組

6.4. 要確定系結的網路介面，必須提供應用程式的名字或IP地址

6.5. 需要在套接字上監聽的服務器應用程式，必須添加可配置的屬性來定義服務器應系結的網路介面

6.6. 應用程式還必須指定發出流量的網路介面

6.6.1. 資料可以通過多條路由，流經目標IP地址所屬的不同網卡，并到達同一個目的地

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556560.html

標籤：架構設計

上一篇：互聯網高可用架構探討

下一篇：返回列表

讀發布！設計與部署穩定的分布式系統（第2版）筆記18_基礎層之聯網

1. 面向恢復的計算

1.1. ROC,recovery-oriented computing

1.2. 加州大學伯克利分校和斯坦福大學的聯合研究專案

1.2.1. 其大部分作業致力于消除系統失效的根源，但也承認系統失效不可避免

1.2.2. 旨在提高系統面臨失效時的生存能力

1.3. 創始原則

1.3.1. 無論在硬體方面還是軟體方面，失效都是不可避免的

1.3.2. 建模和分析永遠都不會足夠完備，用推導的方法預測所有系統失效方式是不可能的

1.3.3. 人的行為是系統失效的主要原因

1.4. 如果在每次配置更改后，都必須重新啟動那些服務器，則無法恢復服務

1.5. 重啟組件而不是重啟整臺服務器的能力，是面向恢復的計算的一個關鍵概念

1.5.1. 在不重啟所有服務器的情況下恢復服務

1.5.2. 花費超過6小時的時間來完成所有服務器的重啟

1.5.3. 僅僅動態重新配置和重啟連接池這件事，只需不到5分鐘的時間

2. 為生產環境而設計

2.1. 將在生產環境中發現的問題視為頭等大事

2.2. 為執行運維操作的人們而設計

2.3. 圖示

3. 基礎層

3.1. 了解系統的物理基礎設施

3.2. 系統所有其他部分所依賴的機器和電纜

3.3. 厘清有關網路、主機名和IP地址之類的事情

3.4. 考慮持有代碼的那些設備：物理主機、虛擬機和容器等

3.5. 當系統跨越多個資料中心時會出現的一些特殊問題

4. 資料中心和云端的聯網

4.1. 相比桌面網路，包含更多冗余和安全性建設

4.2. 聯網時最大的誤解就是機器的主機名

4.3. 主機名可以用兩種方式來定義

4.3.1. 主機名是作業系統用來識別自身的名字

4.3.1.1. 機器的管理員可以設定該主機名和“默認搜索域”，將主機名和搜索域拼接在一起就構成了FQDN（全限定域名）

4.3.1.2. 即在運行hostname命令時所看到的內容

4.3.2. 系統的外部名字

4.3.2.1. 其他計算機希望使用這樣的主機名連接到目標機器

4.3.3. 無法保證機器自身的FQDN與DNS為該機器的IP地址所提供的FQDN相匹配

4.4. 兩個定義的根本區別

4.4.1. 機器使用其主機名標識整個機器

4.4.2. DNS名字僅用來標識IP地址，多個DNS名字可以被決議為同一個IP地址

4.4.3. 對負載均衡服務來說，一個DNS名字也可以被決議為多個IP地址，這意味著“DNS名字到IP地址”是一種“多對多”的關系

4.4.4. 許多實用程式和應用程式都假定機器自分配的FQDN是合法的DNS名字，決議后不會發生改變

4.4.4.1. 對開發機器來說基本上是正確的，但對生產環境的服務來說一般是錯誤的

4.5. 多網卡的多對多的關系

4.5.1. 一臺機器可能有多個網卡

4.5.2. 每個網卡可以連接到不同的網路，每個活動的網卡能在其特定網路上獲取IP地址，這被稱為多宿主（multihoming）

4.5.3. 資料中心中的每臺服務器一般都是多宿主的

4.5.4. 不知道存在多個網路介面的應用程式，最終就容易接受來自錯誤網路的連接

5. 備份操作

5.1. 會以突發的方式傳輸巨量的資料

5.2. 如果備份發生在生產環境網路上就會堵塞網路

5.3. 良好的資料中心網路設計，是將備份用的資料流量分流到其專用的網段上

5.3.1. 由單獨的交換機處理

5.3.2. 由生產環境交換機上的單獨虛擬局域網處理

5.4. 備份流量從生產環境網路中分離出來后，當執行備份操作時，應用程式用戶不會因此受到影響

6. 多網路編程

6.1. 默認情況下，監聽一個套接字的應用程式，會監聽所有網路介面上的連接請求

6.2. 編程語言庫總是有一個“簡單”的套接字監聽版本，這個“簡單”版本只是在主機的每個網路介面上打開一個套接字

6.3. 在生產環境中配置多個網路介面的另一種常見方法，是系結或分組

6.4. 要確定系結的網路介面，必須提供應用程式的名字或IP地址

6.5. 需要在套接字上監聽的服務器應用程式，必須添加可配置的屬性來定義服務器應系結的網路介面

6.6. 應用程式還必須指定發出流量的網路介面

6.6.1. 資料可以通過多條路由，流經目標IP地址所屬的不同網卡，并到達同一個目的地