在 2012年的時候，我在豆瓣做 Douban App Engine ( a.k.a DAE)。那時候我遇到了一個問題，就是如何隔離 Engine 的 Runtime 和應(yīng)用本身的 Runtime，如果不學(xué) GAE 那樣大規(guī)模 Mock Python 的話，無論怎么做隔離性上終究不會太***。

[[150437]]

在 2013年春節(jié)過后，DAE 在豆瓣內(nèi)部已經(jīng)支撐起多數(shù)服務(wù)和應(yīng)用，而我也因為職業(yè)規(guī)劃準(zhǔn)備離職去穿越亞洲，這時候一個叫 Docker 的虛擬化方案進入了我的視野。回想起 2012年我遇到的隔離性問題的，當(dāng)時的我立刻被這個方案給吸引住了，即便在戰(zhàn)火紛飛的阿富汗腹地，也靠著僅有的當(dāng)?shù)鼐W(wǎng)絡(luò)關(guān)注著這個項目的狀態(tài)。

從我個人來看，隨著業(yè)務(wù)的增長服務(wù)也會被逐步拆分，為了提高整體的服務(wù)器利用率和調(diào)度效率，平臺自動化將會是一種比較好的選擇。對應(yīng)用耦合的，一般稱為 PaaS，平臺即服務(wù)，如果對硬件耦合的，一般稱為 IaaS，基礎(chǔ)設(shè)施即服務(wù)。如果純粹靠 PaaS，隔離性上會比較讓人擔(dān)憂，如果是完全的 IaaS，過重的 overhead 會使得硬件利用率達不到預(yù)期以至于成本的失控。有些開源項目結(jié)合 IaaS 和 PaaS 去做自動化平臺在我看來也不是一個很好的選擇，畢竟公司千千萬萬，業(yè)務(wù)技術(shù)線也不能一概而論，二次開發(fā)也需要考慮平衡硬件和人力成本。所以我覺得一個好的平臺應(yīng)該做到嚴(yán)謹?shù)母綦x，無痛的擴展，簡單的部署，可靠的支撐等幾個方面，同時也不能損耗太多的性能，并且能易于上層的開發(fā)，降低公司成本。Docker 本身是個不錯的基礎(chǔ)技術(shù)，在隔離性和性能上取得了較好的平衡，相比之下 VM 雖然隔離很嚴(yán)謹，相對性能就損耗比較高了。并且 Docker 提供了一系列適合二次開發(fā)的 API，可以方便的低成本的做出一個適合公司本身自己技術(shù)棧的自動化平臺，這對于很多發(fā)展型的公司而言那是極好的。

隨著時間的推移，在容器方面我們也看到了很多后來者對于 Docker 的挑戰(zhàn)，如 CoreOS 帶來的 rocket，如有著更高隔離性的 Hyper 等。但在目前來說，我認為 Docker 的地位短時間來說很難被改變。一來大多數(shù)的公司主要以 Docker 作為基礎(chǔ)組件構(gòu)建對內(nèi)的自動化平臺，對更高層次的內(nèi)核安全性需求沒那么強烈，另外一方面基于 Docker API 的周邊組件也趨于成熟，短期內(nèi)其他競品沒那么完備的生態(tài)環(huán)境。隨著 Docker 本身母公司的其他產(chǎn)品諸如 Docker Machine，Docker Swarm 等的成熟，以及業(yè)界第三方的產(chǎn)品如 Kubernetes 和 Mesos 等，Docker 在集群編排和調(diào)度領(lǐng)域的優(yōu)勢還會進一步擴大。

我依稀記得 2014年我來到芒果TV開始搞 Docker 相關(guān)自動化平臺時的情景，雖然當(dāng)時 Docker 在業(yè)內(nèi)很火，但是實際上在公司內(nèi)部使用的還是太少，太多公司只是用其做做實驗性質(zhì)的測試和體驗。在 2015 年初始，新浪和騰訊兩家的分享引爆了國內(nèi)的容器圈，使用 Docker 作為其服務(wù)器集群調(diào)度和編排的公司如雨后春筍般冒了出來。同時 Docker 本身也在不斷的進化，如 1.5 引入的 stats 接口，如 1.7 引入的日志模式，如 1.8 引入的 Volume，Docker 雖然不***但已經(jīng)足矣勝任生產(chǎn)環(huán)境下大規(guī)模使用。而未來即將到來的 libnetwork 等技術(shù)，也將會在 SDN 這塊帶來新的變革。

我不好說未來一定會怎樣，是 Docker 勝出亦或是其他技術(shù)，但 Docker 所引發(fā)的這個趨勢，將會在未來的一段日子里面，不斷的影響著平臺層面的開發(fā)人員。變革，早已開始。

原文鏈接：http://dockone.io/article/702