2005與2015軟體應用部署方式的比較

banq發表於2015-06-09
原文網址 : http://jdon.com/47358
近期攜程網站由於程式設計師登入生產現場誤操作導致整個網站長期無法訪問，這些現象反映了國內很多大型網站的應用部署運營還是停留在2005年的階段，該文展示了2015年的生產現場運營現狀。

在過去十年中，構建和釋出應用程式的方式已經發生顯著變化，這篇文章比較了2005年和2015在Java/JVM上應用部署的不同。

2005 = Multi-App Containers / App Servers / Monolithic Apps
2015 = Microservices / Docker Containers / Containerless Apps

2005年我們基本都是以WAR檔案作為專案結果，其包含Java的Web應用和有關依賴庫包，這個應用被部署到一個單個的應用伺服器，稱為容器，因為它包含一個或多個應用，這個應用伺服器提供了很多基礎服務比如HTTP伺服器，服務目錄或共享庫包等等，不幸的是部署多個應用在一個容器中在擴充套件性 部署性和資源使用上有很多磕磕絆絆，應用伺服器將應用和底層系統依賴隔離開來，這樣避免“it works on my machine” 問題（只在我機器上能夠執行），但是事情變得不是很平滑，因為系統依賴和配置遊離於應用伺服器也就是容器之外。

在2015年，應用能夠以作為自我包容單元的方式部署，應用自身包含一切，它直接執行在標準的系統依賴之上就可以，在Java世界，一個無容器containerless應用是一個ZIP檔案，其包含包含基於JVM執行需要的一切依賴庫包，大多數開發框架已經切換到這種containerless方式，比如Play框架， Dropwizard和Spring Boot等等。

系統級別的更完整可移植的自我包容單元有 Docker 和 LXC，不同於過去將很多應用部署到一個應用伺服器容器中，一個個單個應用加入到Docker image，然後可以部署到一個或多個伺服器中。

微服務在這裡扮演了重要角色，因為以一個個微服務部署可以分離獨立，而傳統的應用伺服器當部署其中一個應用時需要重啟整個伺服器，這也就是企業部署速度是蝸牛的原因，部署應用是一件非常危險的工作，必須提前幾個月與眾多團隊協調好，熱部署只是一個承諾，從來沒有在生產環境實現過。

而微服務啟用了獨立團隊部署自己的應用的願望，微服務能夠快速準備 快速部署和擴充套件服務的能力，這些需求正好能夠將containerless應用執行在底層Docker容器中實現。

2005 = 手工部署
2015 = 持續提交 /持續部署
2005年是手工部署，多個整體單一monolithic應用捆綁在一起，透過手工配置上傳到生產環境。
2015是持續遞交和持續部署，每天可以部署提交幾百次。

2005 = Persistent Servers / “祈禱它不會當機”
2015 = 不變的基礎設施/ Ephemeral Servers
今天，Netflix的Chaos Monkey能夠隨機關閉伺服器，以確保我們各自準備工作完成就緒，然後啟動，可以瞬間進行應用例項的增加和減少，因為基礎設施的不變性，我們解決生產問題再也不需要SSH登入到主機（banq注：近期攜程停機事件是由於程式設計師登入生產環境誤操作導致，採取微服務+Docker+不變基礎設施環境，這種情況能夠避免），日誌服務被匯出到外部服務，能夠以實時流方式檢視。

2005 = Ops Team運營團隊
2015 = DevOps 開發運營合一
在2005年運營團隊拿到WAR檔案，負責部署 管理和監控它，開發人員手機無需24小時開機，因為運營人員可以在生產環境凌晨3點出現問題時做一些事情解決，但是最大的風險就是在軟體交接時造成了很大的緩慢。

今天開發人員將會對投入生產的程式碼一直負責到底，類似New Relic, VictorOps, 和 Slack這樣服務能夠幫助開發人員負責起運營職責，DevOps文化正在逐漸普及。

Comparing Application Deployment: 2005 vs. 2015 |

相關文章