DINP是又一個基于Docker開發(fā)的PaaS平臺。

DINP 包含如下組件：

dinp-server master組件，控制集群中所有計算節(jié)點

dinp-agent Agent，部署在所有計算節(jié)點，收集各個節(jié)點運行狀態(tài)和container列表

dinp-builder 編配平臺，負責把用戶代碼打包為Docker image

dinp-dash Dashboard，用戶操作的入口

dinp-router 負責請求的路由等功能

dinp-hm Health Monitor，對APP的rs進行7層健康檢查

dinp-common 公共函數(shù)、數(shù)據(jù)結構

之所以用了“又”字，是因為現(xiàn)在的PaaS平臺著實很多，DINP只不過是又造了個輪子，下面給大家說說這個輪子與其他輪子的不同點。

1. DINP只接管web應用

PaaS 平臺是個規(guī)范性很強的平臺，app要用PaaS托管，必須要滿足1、2、3...n條規(guī)范才可以。web應用通常無狀態(tài)，邏輯簡單，部署方式統(tǒng)一故而可以 使用PaaS托管。但對于一些分布式大型軟件、復雜的rpc服務，部署架構復雜，并不適合用PaaS托管。有所為有所不為，DINP只接管web應用。

2. DINP不接管代碼的編譯環(huán)節(jié)

像 tsuru之類的PaaS，從代碼的push就開始接管了。他們通常要求用戶把代碼push到指定repo的指定分支，以此觸發(fā)git receiver，git receiver與后端其他組件協(xié)同，拉取用戶最新代碼，下載dependency，編譯，打包等等。但是在國內，因為一些原因，下載 dependency是一個很費勁的過程。如果這個動作放到平臺來做，用戶每次要上線了都要等待一個漫長的過程是不可接受的。

所以，DINP不接管代碼的編譯環(huán)節(jié)，需要用戶自己通過科學上網(wǎng)的方式搞定。比如Java，用戶把最終的war包扔給DINP即可，而不能是扔一 堆.java源文件和pom.xml；比如Golang，用戶把編譯好的二進制扔給DINP即可，而不能扔一堆.go源文件；比如Python，用戶最好 提前下載好相關lib庫，然后加入環(huán)境變量，而不是提供一個pip_requirements.txt，當然，對于一些特別容易安裝的lib庫，用戶提供 一個pip_requirements.txt也未嘗不可，DINP也支持，但是不推薦。

3. DINP夠簡單

如果你對 Docker比較熟悉，那DINP對你來說會很簡單，我們并沒有做太多事情，你理解起來也會相對輕松。PaaS中需要一個通用打包規(guī)范，我們使用了 Dockerfile；PaaS中需要一個SCM存放發(fā)布包，我們使用了Docker Registry；PaaS中需要一個container來run app，我們使用了Docker。另外PaaS中需要一個七層router，我們使用了CloudFoundry提供的gorouter。DINP的絕大 部分組件都是Golang寫的，靜態(tài)編譯的語言部署起來超方便。Dashboard和UIC是用Java寫的，基于JFinal框架，很簡單的，相信我。

4. DINP的架構

用戶把代碼打包為.tar.gz，交給Builder打包為一個Docker image

拿到Builder產(chǎn)出的Docker image去Dashboard創(chuàng)建一個App，設置好實例數(shù)、內存大小、image地址，O了。Dashboard把用戶填寫的這些信息寫入MySQL

Server定期從MySQL同步用戶期望的數(shù)據(jù)，姑且稱之為desired state

部署在所有計算節(jié)點的Agent與Server之間有心跳通信，收集本機的剩余內存量和container列表，姑且稱之為real state

Server對比desired state和real state，發(fā)現(xiàn)某個App的實例數(shù)少了就去調度新的計算節(jié)點創(chuàng)建新實例，如果發(fā)現(xiàn)某個App實例數(shù)多了，就干掉多余的實例

Server同時會分析real state，組織出路由信息寫入redis

Router定期從redis中獲取路由信息

Router通常部署多個，前面部署LVS，注冊一個域名，比如apps.io，把*.apps.io這個泛域名解析到LVS VIP，整個流程就通了

5. 服務接入

如 果你玩過CloudFoundry，會很敏感的發(fā)現(xiàn)，DINP沒有接管MySQL、Memcache、Redis、MQ等等服務。為什么呢？我們的想法是 這樣的：專業(yè)的人做專業(yè)的事，在公司里，MySQL、Redis之類的服務已經(jīng)有DBA團隊運維管理了很久了。他們是最懂的人，他們已經(jīng)形成了一整套成熟 的部署規(guī)范，運維流程。只要提供一個連接地址，一個賬號讓PaaS上的App連上去就行了，何必非要把MySQL與DINP做很強的關聯(lián)整合呢

補充

DINP在公司內部小規(guī)模用了幾個月，沒有出什么問題，大家可以玩一玩了。

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎知識，讓我們一起攜手，引領人工智能的未來！

標簽： Mysql 大數(shù)據(jù) 代碼 通信 域名 域名解析 云計算

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。