集羣管理要點

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

一、每一個應用都是集羣的一部分，每一個RD都有一套本身的集羣管理方式

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

有的設計得很是複雜：使用zookeeper這樣的名字服務，本身作監控，本身部署代碼，本身作服務發現等

RD的視角不多考慮運維的問題，RD視角出發的集羣管理基本上是以程序可以運行起來爲標準的。

RD無法不考慮集羣管理，由於沒有這個，程序是沒法獨立運行的。

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

二、每一個運維繫統都是在給應用打補丁，每一個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承擔的集羣管理工做，全盤地處理問題。以面向狀態地思惟去建模，雖然仍然有腳本，可是都是原子化可複用的。