如果是為下一代大型移動應(yīng)用的前端UI組件工作，那么談?wù)摷涌焖俣群推茐臇|西看上去還不錯。當(dāng)進(jìn)入服務(wù)器領(lǐng)域時，就沒有人希望看到破壞了。業(yè)務(wù)在飛速發(fā)展，但是如果后臺基礎(chǔ)架構(gòu)包含手動部署還帶有硬編碼配置的應(yīng)用程序的話，要想滿足這些變化中的需求就會變成噩夢。本文介紹五大部署技術(shù)，使得即使是小團(tuán)隊也能夠部署靈活的，響應(yīng)式技術(shù)堆棧。
容器管理系統(tǒng)
Docker容器在過去兩年中占領(lǐng)了IT世界，這是有原因的。Unix chroot命令的演化，和內(nèi)核命名空間以及分層文件系統(tǒng)的組合，容器將應(yīng)用的完整依賴集合打包在一起，這樣可以將代碼快速部署到任何運(yùn)行著兼容內(nèi)核的服務(wù)器上。和硬件虛擬化不同，容器只會造成非常小的額外消耗，啟動速度幾乎和進(jìn)程一樣快。上千個容器可以運(yùn)行在一個虛擬機(jī)實例里。它們使得不可變基礎(chǔ)架構(gòu)的理念成為現(xiàn)實，將安裝和配置狀態(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)里的某個地方需要知道實現(xiàn)應(yīng)用程序的容器在哪里運(yùn)行，以及如何將流量路由到正確的地址和端口上。在RESTful的設(shè)計里，這里的需求包括基于第7層內(nèi)容來路由請求。強(qiáng)大的開源工具，比如NGINX和 HAProxy，讓用戶能夠快速實現(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)在使用的語言和工具，這是影響決策的重要因素。
容器集群
如果實現(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ù)和整個堆棧層的配置。在其中做選擇時，需要重點考慮供應(yīng)商和服務(wù)代碼跨平臺的移植性。無論使用哪種方案，都需要研究自動化工具，比如Ansible，Chef和可敬又很頑固的GNU Make，來將所有部分組合到一起，但是在這方面的努力一定會物有所值，因為能夠幫助獲得可持續(xù)性和可擴(kuò)展性。
即時生效的API
好了，集群已經(jīng)正在運(yùn)行了，并且集群有可發(fā)現(xiàn)的服務(wù)。因此，當(dāng)http請求到達(dá)集群的/awesome或者/awesomer/端點時，請求能夠分發(fā)到正確的地方，并且得到響應(yīng)。那么，如果終止SSL連接，并且在應(yīng)用的不同版本或者不同環(huá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這樣的獨立解決方案了。
shake-n-bake網(wǎng)關(guān)是否適合于你的項目？在早期階段，應(yīng)該更值得投入到速度的提升以及管理上額外消耗的減少上。但是之后，會更加依賴于在你所在的使用層級里需要實際花費(fèi)多少工作。