DINP是又一個(gè)基于Docker開發(fā)的PaaS平臺(tái)。
DINP 包含如下組件：
dinp-server master組件，控制集群中所有計(jì)算節(jié)點(diǎn)
dinp-agent Agent，部署在所有計(jì)算節(jié)點(diǎn)，收集各個(gè)節(jié)點(diǎn)運(yùn)行狀態(tài)和container列表
dinp-builder 編配平臺(tái)，負(fù)責(zé)把用戶代碼打包為Docker image
dinp-dash Dashboard，用戶操作的入口
dinp-router 負(fù)責(zé)請(qǐng)求的路由等功能
dinp-hm Health Monitor，對(duì)APP的rs進(jìn)行7層健康檢查
dinp-common 公共函數(shù)、數(shù)據(jù)結(jié)構(gòu)
之所以用了“又”字，是因?yàn)楝F(xiàn)在的PaaS平臺(tái)著實(shí)很多，DINP只不過(guò)是又造了個(gè)輪子，下面給大家說(shuō)說(shuō)這個(gè)輪子與其他輪子的不同點(diǎn)。
1. DINP只接管web應(yīng)用
PaaS 平臺(tái)是個(gè)規(guī)范性很強(qiáng)的平臺(tái)，app要用PaaS托管，必須要滿足1、2、3...n條規(guī)范才可以。web應(yīng)用通常無(wú)狀態(tài)，邏輯簡(jiǎn)單，部署方式統(tǒng)一故而可以 使用PaaS托管。但對(duì)于一些分布式大型軟件、復(fù)雜的rpc服務(wù)，部署架構(gòu)復(fù)雜，并不適合用PaaS托管。有所為有所不為，DINP只接管web應(yīng)用。
2. DINP不接管代碼的編譯環(huán)節(jié)
像 tsuru之類的PaaS，從代碼的push就開始接管了。他們通常要求用戶把代碼push到指定repo的指定分支，以此觸發(fā)git receiver，git receiver與后端其他組件協(xié)同，拉取用戶最新代碼，下載dependency，編譯，打包等等。但是在國(guó)內(nèi)，因?yàn)橐恍┰颍螺d dependency是一個(gè)很費(fèi)勁的過(guò)程。如果這個(gè)動(dòng)作放到平臺(tái)來(lái)做，用戶每次要上線了都要等待一個(gè)漫長(zhǎng)的過(guò)程是不可接受的。
所以，DINP不接管代碼的編譯環(huán)節(jié)，需要用戶自己通過(guò)科學(xué)上網(wǎng)的方式搞定。比如Java，用戶把最終的war包扔給DINP即可，而不能是扔一 堆.java源文件和pom.xml；比如Golang，用戶把編譯好的二進(jìn)制扔給DINP即可，而不能扔一堆.go源文件；比如Python，用戶最好 提前下載好相關(guān)lib庫(kù)，然后加入環(huán)境變量，而不是提供一個(gè)pip_requirements.txt，當(dāng)然，對(duì)于一些特別容易安裝的lib庫(kù)，用戶提供 一個(gè)pip_requirements.txt也未嘗不可，DINP也支持，但是不推薦。
3. DINP夠簡(jiǎn)單
如果你對(duì) Docker比較熟悉，那DINP對(duì)你來(lái)說(shuō)會(huì)很簡(jiǎn)單，我們并沒(méi)有做太多事情，你理解起來(lái)也會(huì)相對(duì)輕松。PaaS中需要一個(gè)通用打包規(guī)范，我們使用了 Dockerfile；PaaS中需要一個(gè)SCM存放發(fā)布包，我們使用了Docker Registry；PaaS中需要一個(gè)container來(lái)run app，我們使用了Docker。另外PaaS中需要一個(gè)七層router，我們使用了CloudFoundry提供的gorouter。DINP的絕大 部分組件都是Golang寫的，靜態(tài)編譯的語(yǔ)言部署起來(lái)超方便。Dashboard和UIC是用Java寫的，基于JFinal框架，很簡(jiǎn)單的，相信我。
4. DINP的架構(gòu)
用戶把代碼打包為.tar.gz，交給Builder打包為一個(gè)Docker image
拿到Builder產(chǎn)出的Docker image去Dashboard創(chuàng)建一個(gè)App，設(shè)置好實(shí)例數(shù)、內(nèi)存大小、image地址，O了。Dashboard把用戶填寫的這些信息寫入MySQL
Server定期從MySQL同步用戶期望的數(shù)據(jù)，姑且稱之為desired state
部署在所有計(jì)算節(jié)點(diǎn)的Agent與Server之間有心跳通信，收集本機(jī)的剩余內(nèi)存量和container列表，姑且稱之為real state
Server對(duì)比desired state和real state，發(fā)現(xiàn)某個(gè)App的實(shí)例數(shù)少了就去調(diào)度新的計(jì)算節(jié)點(diǎn)創(chuàng)建新實(shí)例，如果發(fā)現(xiàn)某個(gè)App實(shí)例數(shù)多了，就干掉多余的實(shí)例
Server同時(shí)會(huì)分析real state，組織出路由信息寫入redis
Router定期從redis中獲取路由信息
Router通常部署多個(gè)，前面部署LVS，注冊(cè)一個(gè)域名，比如apps.io，把*.apps.io這個(gè)泛域名解析到LVS VIP，整個(gè)流程就通了
5. 服務(wù)接入
如 果你玩過(guò)CloudFoundry，會(huì)很敏感的發(fā)現(xiàn)，DINP沒(méi)有接管MySQL、Memcache、Redis、MQ等等服務(wù)。為什么呢？我們的想法是 這樣的：專業(yè)的人做專業(yè)的事，在公司里，MySQL、Redis之類的服務(wù)已經(jīng)有DBA團(tuán)隊(duì)運(yùn)維管理了很久了。他們是最懂的人，他們已經(jīng)形成了一整套成熟 的部署規(guī)范，運(yùn)維流程。只要提供一個(gè)連接地址，一個(gè)賬號(hào)讓PaaS上的App連上去就行了，何必非要把MySQL與DINP做很強(qiáng)的關(guān)聯(lián)整合呢
補(bǔ)充
DINP在公司內(nèi)部小規(guī)模用了幾個(gè)月，沒(méi)有出什么問(wèn)題，大家可以玩一玩了。
京公網(wǎng)安備 11010502049343號(hào)