第一章：RD/OP 實際上在寫同一個分布式系統

1、每個應用都是集群的一部分，每個RD都有一套自己的集群管理方式

有的設計得非常簡單：一個配置文件，讀取一下數據庫的ip和端口

有的設計得非常復雜：使用zookeeper這樣的名字服務，自己做監控，自己部署代碼，自己做服務發現等

RD的視角很少考慮運維的問題，RD視角出發的集群管理基本上是以程序能夠運行起來為標準的。

RD沒法不考慮集群管理，因為沒有這個，程序是無法獨立運行的。

RD沒法太多的去考慮集群管理，因為大部分的應用的開源的，無法假設實際的運維工具棧。

2、每個運維系統都是在給應用打補丁，每個OP都在給RD擦屁股

運維系統與分布式應用沒有什么區別。運維系統實際上是在做adapter，把每個接入的應用建模成一樣的分布式應用。

OPDEV實際上不是在寫運維自動化系統，他們在寫的是一個分布式系統的集群管理模塊。

OP實際上不是在接入系統，而是在把各種亂七八糟，半拉子的分布式應用改造成可運維的模式。

一堆互相做法不同的系統，每個系統又由RD/OP兩種角色的人各搞半拉子工程拼接而來。

=================

第二章：面向場景面向過程的思維

發布：新的版本上線

變更：所有對已有版本的改動

配置更新：變更的一種，用某種接口修改配置使其生效

擴容縮容：變更的一種，增加機器

開區合服：變更的一種，增加一個業務上的set

故障處理：變更的一種，修復線上機器的故障

過程，傳文件：需要一種通用的文件傳輸機制

過程，執行腳本：需要一種通用的獲取ip，腳本執行機制

過程，調用API：需要一種通用的調用云服務的api的機制

過程，組合：面向每個場景的每個操作，都要有一個過程。更大的組合是對一堆過程拼裝。

結果是一大堆無法重用的腳本，無法審查，無法驗證。bash/ant 等語言不是唯一問題，沒有足夠好的人來寫腳本也不是唯一問題。為什么需要這么多大體上是重復腳本，才是問題。

unscalable thinking

==============

第三章：對狀態進行建模

idea：對狀態進行建模。比對實際的狀態和預期的狀態得出動作。

想法很好，但是實踐起來發現這個事情其實很坑：

問題1，從上往下事無巨細的描述狀態：從最上層的每個機器上運行多少個進程，到最底層的有幾個文件，都有什么內容。

問題2，靜態地描述全局：需要描述有多少個ip地址，每個ip上都部署了什么，每個配置文件里的依賴項都是靜態確定的

問題3，動作非常難搞對：無法測試這個部署腳本。很多時候在一個空機器上運行會掛掉，但是在我的機器上運行就是成功。

問題4，跑起來太慢了，而且不可靠：需要從外網下載一堆東西，很慢。即便不用下載，運行一堆apt-get也快不到哪里去

================

第四章：docker

docker解決的問題是狀態可以是一個很大粒度的東西。不用細粒度到文件級別，可以把一個進程的所有依賴打包成一個黑盒。apt-get還是yum，就沒關系了。

================

第五章：名字服務，服務注冊，服務發現

smartstack做的事情其實是名字服務的統一化。構建一個進程和服務級別的名字服務（大部分運維出發的CMDB，都是IP級別的），然后把所有人的名字服務全部統一成一個，可以網絡依賴問題。

================

第六章：marathon & helix?

這兩項工具其實干的事情是類似的。與其事無巨細地描述預期的狀態，不如給一定一些規則，讓系統去自動決定最佳的狀態是什么。給定5臺機器不同負載，上面要跑10個進程，marathon會幫我搞定每臺機器上跑哪些進程。

helix也是類似，告訴helix需要多少個partition，都應該是什么狀態，由helix去分配。

==================

第七章：detc

現狀：一堆互相做法不同的系統，每個系統又由RD/OP兩種角色的人各搞半拉子工程拼接而來。用一大堆腳本，以過程化的思維去管理系統。

預期：一堆系統雖然功能不同，但是用完全一致的方式來管理。接管所有RD/OP承擔的集群管理工作，全盤地處理問題。以面向狀態地思維去建模，雖然仍然有腳本，但是都是原子化可復用的。

?

轉載于:https://www.cnblogs.com/taowen/p/4910137.html

總結

以上是生活随笔為你收集整理的集群管理要点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。