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

[[167267]]

　　容器管理系統(tǒng)

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

　　服務(wù)發(fā)現(xiàn)框架

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

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

　　容器集群

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

　　即時生效的API

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

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

　　無服務(wù)器服務(wù)

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

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