本文中，我們將探討容器的一些特性，在減輕開(kāi)發(fā)/測(cè)試工作量的同時(shí)，也使得它們非常適合在AWS中構(gòu)建一個(gè)微服務(wù)構(gòu)架。對(duì)于Web應(yīng)用程序來(lái)說(shuō)，微服務(wù)架構(gòu)可以讓?xiě)?yīng)用程序的代碼庫(kù)更加敏捷，并且容易管理。下面，我們將介紹這個(gè)架構(gòu)為何可以大幅提升開(kāi)發(fā)者生產(chǎn)效率的原因，并了解它能夠快速迭代和擴(kuò)充一個(gè)代碼庫(kù)的原理。對(duì)于快速發(fā)展中的創(chuàng)業(yè)公司來(lái)說(shuō)，微服務(wù)架構(gòu)可以讓開(kāi)發(fā)團(tuán)隊(duì)在研發(fā)過(guò)程中更加的敏捷和靈活。

Web開(kāi)發(fā)簡(jiǎn)史

首先，我們快速回顧一下過(guò)去20年的Web開(kāi)發(fā)歷史，這有助于解釋為什么微服務(wù)架構(gòu)變得如此流行，以及這一架構(gòu)解決的問(wèn)題。

在Web應(yīng)用開(kāi)發(fā)的最初階段，應(yīng)用都是使用通用網(wǎng)關(guān)接口（CGI）創(chuàng)建的。這個(gè)接口為Web服務(wù)器提供了一種在處理瀏覽器HTTP請(qǐng)求時(shí)執(zhí)行腳本（通常是使用Perl編寫(xiě)）的方法。由于對(duì)腳本資源的每個(gè)請(qǐng)求都需要啟動(dòng)一個(gè)Perl進(jìn)程處理，CGI架構(gòu)無(wú)法很好地?cái)U(kuò)展。為了解決這個(gè)問(wèn)題，當(dāng)時(shí)流行的Web服務(wù)器添加了模塊支持。Apache，如今***的Web服務(wù)器之一，添加了“mod_perl”模塊，在服務(wù)器內(nèi)部運(yùn)行Perl代碼，這使得CGI腳本能更快執(zhí)行。

盡管像mod_perl這樣的技術(shù)讓傳統(tǒng)CGI獲得了巨大提升，問(wèn)題依然存在。負(fù)責(zé)構(gòu)建視圖的代碼（比如解析頁(yè)面HTML的動(dòng)態(tài)部分）與應(yīng)用的業(yè)務(wù)邏輯混雜在一起。這意味著要完成一個(gè)簡(jiǎn)單的任務(wù)，比如在HTML表格中添加一列或在表單中添加一個(gè)新元素，都需要修改底層應(yīng)用代碼。因此，Web編程技術(shù)的下一輪革新成果“server pages”出現(xiàn)了，它是允許在HTML里嵌入可執(zhí)行代碼的模板框架?？梢愿逦貙?yīng)用邏輯與視圖邏輯分開(kāi)。在Java編程世界，一種名為“Model 2”的設(shè)計(jì)模式迅速出現(xiàn)，如圖1所示，它將應(yīng)用代碼放入Java servlet、數(shù)據(jù)放入叫Java Bean的類(lèi)中、視圖邏輯放入JSP：

“Model 2”很快演變成了如今廣泛使用的Model-View-Controller（MVC）設(shè)計(jì)模式。很多早期的MVC框架都是以Java為基礎(chǔ)的（如Apache Struts），不過(guò)其它框架如Ruby On Rails也在快速普及。在MVC設(shè)計(jì)模式中，“controller”類(lèi)定義了映射到“route”類(lèi)URL的方法。controller方法使用封裝了核心應(yīng)用實(shí)體業(yè)務(wù)邏輯和數(shù)據(jù)的“model”類(lèi)。***，每個(gè)controller方法渲染一個(gè)用于顯示和編輯相應(yīng)model類(lèi)數(shù)據(jù)的“view”。如圖2所示，這個(gè)模式將業(yè)務(wù)、應(yīng)用和視圖邏輯清晰地分離開(kāi)了：

REST協(xié)議崛起

在MVC作為Web開(kāi)發(fā)的事實(shí)選擇被快速采納的同時(shí)，進(jìn)程間通訊（IPC）演進(jìn)為使用以文本為基礎(chǔ)的系列化格式，如XML和JSON。像SOAP這樣的協(xié)議允許通過(guò)HTTP進(jìn)行IPC，很快Web開(kāi)發(fā)人員不再只是創(chuàng)建為瀏覽器提供內(nèi)容的Web應(yīng)用，還有為其它程序執(zhí)行任務(wù)并交付數(shù)據(jù)的Web服務(wù)。這種基于服務(wù)的架構(gòu)擁有非常強(qiáng)大的功能，因?yàn)樗藢?duì)共享代碼庫(kù)的依賴(lài)，允許應(yīng)用開(kāi)發(fā)人員更進(jìn)一步解耦應(yīng)用組件。SOAP協(xié)議和相關(guān)的WS-*標(biāo)準(zhǔn)很快變得越來(lái)越復(fù)雜，并且嚴(yán)重依賴(lài)于應(yīng)用服務(wù)器的具體實(shí)現(xiàn)，因此開(kāi)發(fā)人員遷移到更輕量的REST協(xié)議上。隨著移動(dòng)設(shè)備的廣泛使用，Web UX開(kāi)發(fā)轉(zhuǎn)移到了AJAX和JavaScript框架上，應(yīng)用開(kāi)發(fā)人員開(kāi)始擴(kuò)展REST的功能用于在客戶端設(shè)備與Web服務(wù)器間傳輸數(shù)據(jù)。

事實(shí)上，MVC框架也非常適合開(kāi)發(fā)REST端。如圖3所示，REST面向資源的特性被很好的映射成了控制器和模型理念，如圖3所示：

一體化架構(gòu)（Monolithic Architecure）

MVC應(yīng)用由模型、視圖和控制器組成，主要為應(yīng)用提供可變的HTML內(nèi)容，包括傳統(tǒng)的HTML和REST端的JSON。很多這類(lèi)應(yīng)用使用了一體化架構(gòu)。應(yīng)用以一個(gè)單一文件（如Java）或放置在同一目錄下的一組文件（如Rails）的形式進(jìn)行部署。所有應(yīng)用代碼運(yùn)行在同一進(jìn)程中。擴(kuò)展時(shí)要求將完全相同的應(yīng)用代碼部署到多臺(tái)服務(wù)器上。圖4是一體化架構(gòu)的表示：

一體化架構(gòu)存在一些問(wèn)題。首先，在添加功能和服務(wù)到應(yīng)用中時(shí)，代碼庫(kù)會(huì)變得非常復(fù)雜。對(duì)于新的開(kāi)發(fā)人員是個(gè)巨大挑戰(zhàn)。如今的IDE甚至在加載整個(gè)應(yīng)用代碼時(shí)會(huì)發(fā)生問(wèn)題，而且編譯與構(gòu)建時(shí)間非常久。因?yàn)樗械膽?yīng)用代碼都運(yùn)行在服務(wù)器的同一個(gè)進(jìn)程中，要擴(kuò)展應(yīng)用的其中一部分（就算可能）非常困難。假如有一個(gè)服務(wù)是內(nèi)存密集型的，另一個(gè)是CPU密集型的，服務(wù)器就必須提供足夠的內(nèi)存和CPU來(lái)處理每個(gè)服務(wù)的基本負(fù)載。如果每臺(tái)服務(wù)器都需要大量CPU和內(nèi)存，花費(fèi)不小，如果使用負(fù)載均衡進(jìn)行應(yīng)用的橫向擴(kuò)展，則費(fèi)用將更高。***，更微妙的是，隨著時(shí)間推移，工程團(tuán)隊(duì)架構(gòu)常常開(kāi)始呈現(xiàn)為應(yīng)用架構(gòu)。UX工程師被派去構(gòu)建UI組件，中間層開(kāi)發(fā)人員構(gòu)建服務(wù)端，數(shù)據(jù)庫(kù)工程師和DBA處理數(shù)據(jù)訪問(wèn)組件和數(shù)據(jù)庫(kù)。如果一個(gè)UX工程師想要添加一個(gè)數(shù)據(jù)到界面上，就必須與中間層和數(shù)據(jù)庫(kù)工程師協(xié)商。像水一樣，人類(lèi)傾向于選擇阻力最小的路徑，這意味著每個(gè)工程組都會(huì)在他們控制的應(yīng)用部分嵌入盡可能多的邏輯。時(shí)間一久，注定會(huì)產(chǎn)生難以維護(hù)的代碼。

#p#

微服務(wù)架構(gòu)

微服務(wù)架構(gòu)設(shè)計(jì)用于解決這個(gè)問(wèn)題。在一體化架構(gòu)中定義的服務(wù)被分解成一個(gè)個(gè)單獨(dú)的服務(wù)，并在不同主機(jī)上分開(kāi)部署。

每個(gè)微服務(wù)針對(duì)一個(gè)特定的業(yè)務(wù)功能，并且只定義該業(yè)務(wù)功能所需的操作。這聽(tīng)起來(lái)像是以服務(wù)為導(dǎo)向的架構(gòu)（SOA），實(shí)際上，微服務(wù)架構(gòu)與SOA有一些共通的特性。兩個(gè)架構(gòu)都將代碼組織成服務(wù)，二者都定義了清晰邊界來(lái)區(qū)隔服務(wù)。然而，SOA源于將提供API（通常以SOAP為基礎(chǔ)）的一體化應(yīng)用與其他應(yīng)用整合在一起的需求。在SOA中，整合嚴(yán)重依賴(lài)于中間件，特別是企業(yè)服務(wù)總線（ESB）。微服務(wù)架構(gòu)經(jīng)常使用消息總線，不過(guò)在消息層完全沒(méi)有邏輯，它簡(jiǎn)單的被用來(lái)在服務(wù)間傳送信息。這與ESB存在巨大差別，后者包含了大量消息路由、schema驗(yàn)證、消息轉(zhuǎn)換和業(yè)務(wù)規(guī)則的邏輯。由此可見(jiàn)，微服務(wù)架構(gòu)相比傳統(tǒng)SOA累贅更少，且在定義服務(wù)間接口時(shí)不要求相同級(jí)別的治理和規(guī)范的數(shù)據(jù)模型。使用微服務(wù)，開(kāi)發(fā)速度快并且服務(wù)可根據(jù)業(yè)務(wù)需要演進(jìn)。

微服務(wù)架構(gòu)的另一個(gè)關(guān)鍵優(yōu)勢(shì)在于，服務(wù)可以根據(jù)其資源需求進(jìn)行單獨(dú)擴(kuò)展。與運(yùn)行配備了大量CPU和內(nèi)存的大型服務(wù)器不同，微服務(wù)可以部署在僅包含該服務(wù)需要的資源的較小主機(jī)上。此外，每個(gè)服務(wù)可以使用最適合其操作執(zhí)行的語(yǔ)言來(lái)實(shí)現(xiàn)。圖像處理服務(wù)可以使用高性能語(yǔ)言如C++實(shí)現(xiàn)。執(zhí)行數(shù)學(xué)或統(tǒng)計(jì)操作的服務(wù)可以使用Python實(shí)現(xiàn)。執(zhí)行基本的資源CRUD操作的服務(wù)可以用Ruby實(shí)現(xiàn)。微服務(wù)架構(gòu)不要求一體化架構(gòu)的“一刀切”模型，后者通常使用單一的MVC架構(gòu)和單一的編程語(yǔ)言。

不過(guò)，微服務(wù)也有一些缺點(diǎn)。因?yàn)榉?wù)分布在多臺(tái)主機(jī)上，要了解哪臺(tái)主機(jī)運(yùn)行了某些服務(wù)可能會(huì)很困難。另外，盡管每臺(tái)主機(jī)可能不像運(yùn)行一體化架構(gòu)的主機(jī)那么強(qiáng)大，在微服務(wù)架構(gòu)橫向擴(kuò)展時(shí)，主機(jī)的數(shù)量將比一體化架構(gòu)增加得更快。在AWS環(huán)境中，即便最小的EC2實(shí)例類(lèi)型，微服務(wù)可能都不需要其全部資源，結(jié)果就是超量供給及成本上升。如果服務(wù)使用不同編程語(yǔ)言實(shí)現(xiàn)，意味著每個(gè)服務(wù)的部署都需要一個(gè)完全不同的庫(kù)與框架集合，使得部署到服務(wù)器非常復(fù)雜。

容器是解決之道

Linux容器可以減輕微服務(wù)架構(gòu)面臨的這些挑戰(zhàn)。Linux容器使用了內(nèi)核接口如別名（cname）和命名空間（namespace），允許多個(gè)容器共享同一個(gè)內(nèi)核，同時(shí)運(yùn)行時(shí)又與其他容器完全隔離。Docker執(zhí)行環(huán)境使用了一個(gè)叫l(wèi)ibcontainer的模塊，用于規(guī)范這些接口。Docker還提供了一個(gè)與GitHub類(lèi)似的名叫DockerHub的容器鏡像倉(cāng)庫(kù)，便于共享和分發(fā)容器。

同一臺(tái)主機(jī)上運(yùn)行的多個(gè)容器間的隔離性使得部署用不同語(yǔ)言和框架開(kāi)發(fā)的微服務(wù)代碼時(shí)非常簡(jiǎn)單。使用Docker，我們可以創(chuàng)建一個(gè)Dockerfile描述所有該服務(wù)使用的語(yǔ)言、框架和依賴(lài)庫(kù)。比如，以下Dockerfile可以用來(lái)定義一個(gè)微服務(wù)的Docker鏡像，在其中使用了Ruby和Sinatra框架：

FROM ubuntu:14.04 
MAINTAINER John Doe <jdoe@example.com> 
RUN apt-get update && apt-get install -y curl wget default-jre git 
RUN adduser --home /home/sinatra --disabled-password --gecos '' sinatra 
RUN adduser sinatra sudo 
RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers 
USER sinatra 
RUN curl -sSL https://get.rvm.io | bash -s stable 
RUN /bin/bash -l -c "source /home/sinatra/.rvm/scripts/rvm" 
RUN /bin/bash -l -c "rvm install 2.1.2" 
RUN /bin/bash -l -c "gem install sinatra" 
RUN /bin/bash -l -c "gem install thin" 

使用該鏡像創(chuàng)建的容器可以簡(jiǎn)單地放置到一臺(tái)運(yùn)行了另一個(gè)容器的主機(jī)上，即便這個(gè)容器創(chuàng)建自一個(gè)使用了Java和DropWizard框架的Docker鏡像。容器執(zhí)行環(huán)境將運(yùn)行在該主機(jī)上的容器彼此隔離開(kāi)，因此容器使用的語(yǔ)言、庫(kù)和框架依賴(lài)不會(huì)與其它容器相沖突。

容器的可移植性讓微服務(wù)的部署變得微不足道。要對(duì)運(yùn)行在指定主機(jī)上的服務(wù)進(jìn)行升級(jí)，只需要簡(jiǎn)單地停止運(yùn)行中的容器，然后啟動(dòng)以***版服務(wù)代碼的Docker鏡像創(chuàng)建的新的容器。該主機(jī)上的所有其它容器都不會(huì)受此變化影響。

容器還有助于提高主機(jī)資源利用率。如果指定的服務(wù)無(wú)法使用Amazon EC2實(shí)例的所有資源，可以啟動(dòng)其它服務(wù)容器來(lái)利用這些空閑資源。當(dāng)然，如果是手工在容器中部署服務(wù)、管理哪些服務(wù)運(yùn)行在哪些主機(jī)上以及監(jiān)控所有運(yùn)行容器的主機(jī)的利用率，事情將迅速變得難以掌控。

最近發(fā)布的Amazon EC2容器服務(wù)（Amazon ECS）就是用于解決這個(gè)問(wèn)題的。使用Amazon ECS，定義一個(gè)名叫“集群（cluster）”的計(jì)算資源池。一個(gè)集群由一個(gè)或多個(gè)Amazon EC2實(shí)例組成。Amazon ECS管理了運(yùn)行在集群里的所有容器應(yīng)用的狀態(tài)，提供自動(dòng)監(jiān)測(cè)和日志，管理集群的利用率，完成工作的高效調(diào)度。Amazon ECS提供了一個(gè)叫“任務(wù)定義（task definition）”的組件，用于定義一組包含應(yīng)用的容器。任務(wù)定義里的每個(gè)容器指明其所需資源，Amazon ECS將根據(jù)集群里的可用資源調(diào)度任務(wù)執(zhí)行。

微服務(wù)可以簡(jiǎn)單的定義成一個(gè)任務(wù)，并可由兩個(gè)容器組成——一個(gè)運(yùn)行服務(wù)端代碼，另一個(gè)是數(shù)據(jù)庫(kù)。Amazon ECS管理著容器間的依賴(lài)，以及集群里的資源均衡。Amazon ECS還提供了對(duì)彈性負(fù)載均衡（Elastic Load Balancing）、Amazon EBS、彈性網(wǎng)絡(luò)接口（Elastic Network Interface）及自動(dòng)擴(kuò)展（Auto Scaling）等重要的AWS服務(wù)的無(wú)縫訪問(wèn)。使用Amazon ECS，容器應(yīng)用也可以使用所有這些部署應(yīng)用到EC2的關(guān)鍵功能。

像Amazon ECS這樣的容器管理方案還簡(jiǎn)化了“服務(wù)發(fā)現(xiàn)（service discovery）”的實(shí)現(xiàn)。因?yàn)槲⒎?wù)經(jīng)常要跨多主機(jī)部署，并常常需要根據(jù)負(fù)載進(jìn)行伸縮，要讓一個(gè)服務(wù)知道如何定位另一個(gè)服務(wù)，服務(wù)發(fā)現(xiàn)就是必需的。最簡(jiǎn)單的方式，就是使用負(fù)載均衡器。不過(guò)很多情況下，還是有必要使用一個(gè)真正的分布式配置服務(wù)，比如Apache Zookeeper。Amazon ECS API可以整合像Zookeeper這樣的第三方工具。也能使用Amazon ECS管理Zookeeper集群?？梢允褂萌蝿?wù)定義將組成Zookeeper集群的容器分在一組，并通過(guò)Amazon ECS服務(wù)調(diào)度到集群的Amazon EC2主機(jī)上執(zhí)行。

從很多方面而言，使用容器實(shí)現(xiàn)微服務(wù)架構(gòu)是一項(xiàng)不同于過(guò)去20年Web開(kāi)發(fā)觀察到的進(jìn)化。這種進(jìn)化受到了如何更好的利用計(jì)算資源和維護(hù)日益復(fù)雜的web應(yīng)用的需求驅(qū)動(dòng)。如我們所見(jiàn)，通過(guò)Linux容器使用微服務(wù)架構(gòu)解決了這兩項(xiàng)需求。我們簡(jiǎn)要說(shuō)明了如何將微服務(wù)定義成Amazon ECS的一項(xiàng)任務(wù)，但是在分布式系統(tǒng)中使用容器遠(yuǎn)遠(yuǎn)不僅限于微服務(wù)。漸漸地，容器已經(jīng)成了所有分布式系統(tǒng)的“一等公民”，未來(lái)的文章中我們將探討類(lèi)似Amazon ECS這樣的工具如何在管理以容器為基礎(chǔ)的計(jì)算資源中發(fā)揮重要作用。

原文鏈接：http://dockerone.com/article/176