1. 物理主機
1.1. 以前資料中心硬體就是建立在單個物理機器的高可靠性上的
1.2. 如今通過足夠多的主機保證各個服務的負載均衡，使得單臺主機的損失不再是災難性的
1.2.1. 希望每臺主機都盡可能便宜
1.2.2. 資料中心的硬體設備都是一次性的消耗品
2. 資料中心的虛擬機
2.1. 應用程式并不會直接在硬體上運行，21世紀初的虛擬化浪潮將直接在物理機器上運行軟體的方式淘汰了
2.2. 虛擬化不利的一面是系統性能的可預測性不強
2.2.1. 所有虛擬機相互爭奪資源，并且會隨機地變慢，而“客戶機作業系統”幾乎不可能監控到這一點
2.3. 當將應用程式設計為在虛擬機上運行時，必須要確保任何一臺主機的損失或減速都不會對其造成影響
2.3.1. 分布式編程技術需要整個集群的同步回應才能繼續發揮作用
2.3.2. 密切注意集群管理器或資源鎖管理器等“特殊”的機器，除非存在無須重新配置即可取而代之的另一臺機器
2.3.3. 留心應用程式對請求或事件發生順序的依賴
2.3.3.1. 沒有人會將其設計到系統中，但這種依賴可能會意外地蔓延到系統中
2.4. 虛擬機使得所有有關時鐘的問題都變得更糟
2.4.1. 不要相信作業系統的時鐘
2.4.2. 如果人類使用的時間很重要，可以使用類似本地網路時間協議服務器等外部時間來源
3. 資料中心的容器
3.1. 永遠不會再問生產環境是否與QA環境一致這樣的問題
3.2. 提供行程隔離和虛擬機封裝技術，以及開發人員容易掌握的構建程序
3.3. 任何單個容器的“身份”都很短暫，因此，不應該基于每個容器實體來配置
3.4. 容器沒有太多的本地存盤空間
3.4.1. 應用程式必須依靠外部存盤系統存盤檔案、資料甚至是快取
3.5. 所有的證書授權資訊都必須提供給容器
3.6. 聯網問題
3.6.1. 默認情況下，容器不會在主機上暴露任何埠
3.6.1.1. 在其自身的虛擬網路介面上暴露
3.6.2. 有選擇地將埠從容器轉發到主機
3.7. 確保在正確的機器上運行足夠多的正確型別的容器實體
3.7.1. 它們啟動時間非常快（是毫秒級而不是分鐘級）
3.7.2. 意味著容器實體將會像一團團小泡沫一樣在主機上時隱時現
3.8. Kubernetes、Mesos和Docker Swarm這樣的軟體包可以解決容器實體的聯網和分配調度問題
3.9. 除錯正在容器中運行的應用程式非常困難
3.9.1. 容器化的應用程式更需要將其“遙測”監控資料發送到資料采集器集中處理
4. 12要素應用程式
4.1. 指明了各種潛在部署障礙
4.1.1. 為解決各種障礙提供了參考方案
4.2. 基準代碼在版本控制系統中只有一份，每個版本只構建一次二進制包，并將其部署到各個環境中
4.3. 顯式宣告依賴關系
4.4. 在環境中存盤配置資訊
4.5. 把后端服務當作附加資源
4.6. 嚴格分離構建和運行
4.7. 以一個或多個無狀態行程運行應用程式
4.8. 通過埠系結提供服務
4.9. 通過行程模型進行擴展
4.10. 快速啟動和優雅終止可最大化穩健性
4.11. ⑩讓開發環境、預發布環境和生產環境盡可能一致
4.12. ⑾將日志視為事件流
4.13. ⑿將后臺管理任務當作一次性行程運行
5. 云上的虛擬機
5.1. 云原生系統將具有更好的運維特性，尤其在可用性和成本方面
5.2. 云上的虛擬機還與其他虛擬機共享物理主機，并可能與之爭奪資源
5.2.1. 無論時間長短，都會遇到虛擬機毫無征兆死機的情況
5.3. 機器“身份”的短暫性
5.3.1. 每次虛擬機啟動時其IP地址都會更改
5.3.2. 需要從亞馬遜那里租用彈性IP地址
6. 云上的容器
6.1. 在云上虛擬機中運行的容器，同時繼承了容器和云帶來的挑戰
6.2. 這些容器構建成一個整體的系統，從某種意義上講，容器的使用將復雜性這口“鍋”，從容器內部甩給了控制層
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556613.html
標籤：架構設計
上一篇：讀發布！設計與部署穩定的分布式系統（第2版）筆記18_基礎層之聯網
下一篇：返回列表