如果是為下一代大型移動應用的前端UI組件工作，那么談論加快速度和破壞東西看上去還不錯。當進入服務器領域時，就沒有人希望看到破壞了。業(yè)務在飛速發(fā)展，但是如果后臺基礎架構包含手動部署還帶有硬編碼配置的應用程序的話，要想滿足這些變化中的需求就會變成噩夢。本文介紹五大部署技術，使得即使是小團隊也能夠部署靈活的，響應式技術堆棧。

[[167267]]

　　容器管理系統(tǒng)

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

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

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

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

　　容器集群

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

　　即時生效的API

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

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

　　無服務器服務

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

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