如果是為下一代大型移動(dòng)應(yīng)用的前端UI組件工作，那么談?wù)摷涌焖俣群推茐臇|西看上去還不錯(cuò)。當(dāng)進(jìn)入服務(wù)器領(lǐng)域時(shí)，就沒有人希望看到破壞了。業(yè)務(wù)在飛速發(fā)展，但是如果后臺(tái)基礎(chǔ)架構(gòu)包含手動(dòng)部署還帶有硬編碼配置的應(yīng)用程序的話，要想滿足這些變化中的需求就會(huì)變成噩夢(mèng)。本文介紹五大部署技術(shù)，使得即使是小團(tuán)隊(duì)也能夠部署靈活的，響應(yīng)式技術(shù)堆棧。

容器管理系統(tǒng)

Docker容器在過去兩年中占領(lǐng)了IT世界，這是有原因的。Unix chroot命令的演化，和內(nèi)核命名空間以及分層文件系統(tǒng)的組合，容器將應(yīng)用的完整依賴集合打包在一起，這樣可以將代碼快速部署到任何運(yùn)行著兼容內(nèi)核的服務(wù)器上。和硬件虛擬化不同，容器只會(huì)造成非常小的額外消耗，啟動(dòng)速度幾乎和進(jìn)程一樣快。上千個(gè)容器可以運(yùn)行在一個(gè)虛擬機(jī)實(shí)例里。它們使得不可變基礎(chǔ)架構(gòu)的理念成為現(xiàn)實(shí)，將安裝和配置狀態(tài)記錄成聲明格式，從而可以在任何時(shí)間可靠地重做。Ubuntu 16.04 LTS Canonical引入了LXD，一種更為集成的容器管理系統(tǒng)，將很多Docker和硬件虛擬化的優(yōu)勢(shì)引入到單個(gè)平臺(tái)上，增強(qiáng)了安全性和性能?，F(xiàn)在可以說，容器給云上軟件的部署和管理方式帶來了革命性的變化。

容器給用戶帶來了靈活性，可以幾乎在任何地方運(yùn)行服務(wù)，但是用戶仍然需要向這些服務(wù)發(fā)送請(qǐng)求。這意味著系統(tǒng)里的某個(gè)地方需要知道實(shí)現(xiàn)應(yīng)用程序的容器在哪里運(yùn)行，以及如何將流量路由到正確的地址和端口上。在RESTful的設(shè)計(jì)里，這里的需求包括基于第7層內(nèi)容來路由請(qǐng)求。強(qiáng)大的開源工具，比如NGINX和 HAProxy，讓用戶能夠快速實(shí)現(xiàn)自己的方案，但是手動(dòng)管理路由配置很容易出錯(cuò)，也會(huì)阻礙靈活性。服務(wù)發(fā)現(xiàn)框架，比如Consul， Apache Zookeeper和mesosphere幫助將面向服務(wù)架構(gòu)的發(fā)現(xiàn)和路由的搭建自動(dòng)化，它們?yōu)榉?wù)提供了中央化的配置存儲(chǔ)，提供了接口來聲明其生命周期事件，并且提供pub或者sub模型來將這些事件通知給其他組件。

哪種方案更適用取決于你當(dāng)前的代碼基和所處的開發(fā)階段。和普通代理不同，發(fā)現(xiàn)層涉及更多的服務(wù)和基礎(chǔ)架構(gòu)之間的合作，因此每種方案如何支持你已經(jīng)在使用的語言和工具，這是影響決策的重要因素。

如果實(shí)現(xiàn)了容器化和自動(dòng)服務(wù)發(fā)現(xiàn)之后，你就會(huì)得到集群。容器集群平臺(tái)意圖使構(gòu)建整個(gè)系統(tǒng)和構(gòu)建容器一樣能夠可靠地重復(fù)。它們填補(bǔ)了單個(gè)容器的運(yùn)行和讓很多不同容器運(yùn)行起來并且一起工作之間的空白，后者包括這些容器如何在特定數(shù)量的宿主機(jī)上運(yùn)行，使用特定的網(wǎng)絡(luò)規(guī)則，自動(dòng)擴(kuò)展參數(shù)，訪問存儲(chǔ)等等。領(lǐng)先的平臺(tái)包括Google的Kubernetes，Amazon Elastic Container service和Docker Compose，它們采用的是略微有所不同的方案，但是目標(biāo)和理念都很類似。每種方案都有優(yōu)勢(shì)和劣勢(shì)，但是這三種方案都是可以用于生產(chǎn)環(huán)境的工具，并且擁有一致的目標(biāo)：自動(dòng)化部署技術(shù)和整個(gè)堆棧層的配置。在其中做選擇時(shí)，需要重點(diǎn)考慮供應(yīng)商和服務(wù)代碼跨平臺(tái)的移植性。無論使用哪種方案，都需要研究自動(dòng)化工具，比如Ansible，Chef和可敬又很頑固的GNU Make，來將所有部分組合到一起，但是在這方面的努力一定會(huì)物有所值，因?yàn)槟軌驇椭@得可持續(xù)性和可擴(kuò)展性。

好了，集群已經(jīng)正在運(yùn)行了，并且集群有可發(fā)現(xiàn)的服務(wù)。因此，當(dāng)http請(qǐng)求到達(dá)集群的/awesome或者/awesomer/端點(diǎn)時(shí)，請(qǐng)求能夠分發(fā)到正確的地方，并且得到響應(yīng)。那么，如果終止SSL連接，并且在應(yīng)用的不同版本或者不同環(huán)境間路由呢？需要一個(gè)公開的入口點(diǎn)來處理這樣的事情，并且可以作為所有部署在其后的不同服務(wù)的網(wǎng)關(guān)?？梢源罱ㄒ粋€(gè)使用SSL的負(fù)載均衡器，但是通常負(fù)載均衡器不需要處理第7層的路由。可以在LB之后搭建一個(gè)代理來完成這部分工作，但是這時(shí)就需要考慮這個(gè)組件的配置，可擴(kuò)展性和故障轉(zhuǎn)移。如果能夠僅僅將整個(gè)API配置為云服務(wù)，并且一個(gè)命令就可以將其部署呢？Amazon的API Gateway就是這么做的，并且非常智能。甚至可以使用Swagger這樣的語言描述API，然后只需上傳，它就可以工作了。Google這方面還沒有提供直接的競(jìng)爭(zhēng)產(chǎn)品，但是他們顯然不會(huì)甘于落后，而且該領(lǐng)域已經(jīng)有Strongloop這樣的獨(dú)立解決方案了。

shake-n-bake網(wǎng)關(guān)是否適合于你的項(xiàng)目？在早期階段，應(yīng)該更值得投入到速度的提升以及管理上額外消耗的減少上。但是之后，會(huì)更加依賴于在你所在的使用層級(jí)里需要實(shí)際花費(fèi)多少工作。

上文提到的技術(shù)可以幫助實(shí)現(xiàn)復(fù)雜系統(tǒng)的完全自動(dòng)化部署，但是要達(dá)到這一目的其實(shí)并不需要那么多的后臺(tái)開發(fā)。如果你是個(gè)創(chuàng)業(yè)公司，僅僅想盡快部署一個(gè) API和服務(wù)呢？或者你可能是一家步入正軌的公司，想要實(shí)現(xiàn)零基礎(chǔ)架構(gòu)的靈活性，并且基于請(qǐng)求付費(fèi)。去年涌現(xiàn)了無服務(wù)器計(jì)算平臺(tái)，它們對(duì)于當(dāng)今真實(shí)的應(yīng)用程序而言已經(jīng)足夠健壯了。該領(lǐng)域的領(lǐng)導(dǎo)者是Amazon的Lambda，它允許快速部署用python、JavaScript和Java編寫的代碼。Lambda功能可以是一個(gè)腳本或者對(duì)其他服務(wù)有依賴和I/O的復(fù)雜應(yīng)用程序。它們可以被手動(dòng)調(diào)用或者被其他Amazon服務(wù)，比如S3生成的事件觸發(fā)。 當(dāng)和APIGateway搭配使用時(shí)，可以用來在零基礎(chǔ)架構(gòu)的環(huán)境里部署整個(gè)微服務(wù)的實(shí)現(xiàn)。其他主流云平臺(tái)也已經(jīng)大步邁入了該領(lǐng)域，比如Microsoft 的Azure Functions和Google的Cloud Functions。

從某種角度看，這些部署技術(shù)體現(xiàn)了云計(jì)算的絕大多數(shù)重要的特性：隱藏了大量底層的復(fù)雜性，盡量讓應(yīng)用能夠無縫工作，而用戶完全無需考慮底層的復(fù)雜度。