變革早已始：對平臺開發(fā)的一些思考
在 2012年的時候，我在豆瓣做 Douban App Engine ( a.k.a DAE)。那時候我遇到了一個問題，就是如何隔離 Engine 的 Runtime 和應用本身的 Runtime，如果不學 GAE 那樣大規(guī)模 Mock Python 的話，無論怎么做隔離性上終究不會太***。
在 2013年春節(jié)過后，DAE 在豆瓣內部已經支撐起多數(shù)服務和應用，而我也因為職業(yè)規(guī)劃準備離職去穿越亞洲，這時候一個叫 Docker 的虛擬化方案進入了我的視野?；叵肫?2012年我遇到的隔離性問題的，當時的我立刻被這個方案給吸引住了，即便在戰(zhàn)火紛飛的阿富汗腹地，也靠著僅有的當?shù)鼐W(wǎng)絡關注著這個項目的狀態(tài)。
從我個人來看，隨著業(yè)務的增長服務也會被逐步拆分，為了提高整體的服務器利用率和調度效率，平臺自動化將會是一種比較好的選擇。對應用耦合的，一般稱為 PaaS，平臺即服務，如果對硬件耦合的，一般稱為 IaaS，基礎設施即服務。如果純粹靠 PaaS，隔離性上會比較讓人擔憂，如果是完全的 IaaS，過重的 overhead 會使得硬件利用率達不到預期以至于成本的失控。有些開源項目結合 IaaS 和 PaaS 去做自動化平臺在我看來也不是一個很好的選擇，畢竟公司千千萬萬，業(yè)務技術線也不能一概而論，二次開發(fā)也需要考慮平衡硬件和人力成本。所以我覺得一個好的平臺應該做到嚴謹?shù)母綦x，無痛的擴展，簡單的部署，可靠的支撐等幾個方面，同時也不能損耗太多的性能，并且能易于上層的開發(fā)，降低公司成本。Docker 本身是個不錯的基礎技術，在隔離性和性能上取得了較好的平衡，相比之下 VM 雖然隔離很嚴謹，相對性能就損耗比較高了。并且 Docker 提供了一系列適合二次開發(fā)的 API，可以方便的低成本的做出一個適合公司本身自己技術棧的自動化平臺，這對于很多發(fā)展型的公司而言那是極好的。
隨著時間的推移，在容器方面我們也看到了很多后來者對于 Docker 的挑戰(zhàn)，如 CoreOS 帶來的 rocket，如有著更高隔離性的 Hyper 等。但在目前來說，我認為 Docker 的地位短時間來說很難被改變。一來大多數(shù)的公司主要以 Docker 作為基礎組件構建對內的自動化平臺，對更高層次的內核安全性需求沒那么強烈，另外一方面基于 Docker API 的周邊組件也趨于成熟，短期內其他競品沒那么完備的生態(tài)環(huán)境。隨著 Docker 本身母公司的其他產品諸如 Docker Machine，Docker Swarm 等的成熟，以及業(yè)界第三方的產品如 Kubernetes 和 Mesos 等，Docker 在集群編排和調度領域的優(yōu)勢還會進一步擴大。
我依稀記得 2014年我來到芒果TV開始搞 Docker 相關自動化平臺時的情景，雖然當時 Docker 在業(yè)內很火，但是實際上在公司內部使用的還是太少，太多公司只是用其做做實驗性質的測試和體驗。在 2015 年初始，新浪和騰訊兩家的分享引爆了國內的容器圈，使用 Docker 作為其服務器集群調度和編排的公司如雨后春筍般冒了出來。同時 Docker 本身也在不斷的進化，如 1.5 引入的 stats 接口，如 1.7 引入的日志模式，如 1.8 引入的 Volume，Docker 雖然不***但已經足矣勝任生產環(huán)境下大規(guī)模使用。而未來即將到來的 libnetwork 等技術，也將會在 SDN 這塊帶來新的變革。
我不好說未來一定會怎樣，是 Docker 勝出亦或是其他技術，但 Docker 所引發(fā)的這個趨勢，將會在未來的一段日子里面，不斷的影響著平臺層面的開發(fā)人員。變革，早已開始。
