之前的博文中，我講解了Linux容器技術(shù)的相關(guān)實現(xiàn)，比如如何使用Docker來建立流線型的開發(fā)和測試體驗。因為可以實現(xiàn)跨不同類型基礎(chǔ)設(shè)施的兼容（比如，在AWS上，容器也可以如實體服務(wù)器上一樣輕松的運(yùn)行），容器讓代碼的部署異常便捷。在實際工作中，測試和開發(fā)環(huán)境的細(xì)微不同很可能會導(dǎo)致應(yīng)用程序的部署失敗；因此在這種情況下，對于開發(fā)和測試工作，容器技術(shù)可以讓開發(fā)者豁免很多預(yù)想之外的工作和相互推脫。

在本篇文章中，我們將討論是什么特性讓容器技術(shù)如此適應(yīng)開發(fā)和測試工作，同樣適用于在AWS平臺上構(gòu)建一個基于微服務(wù)的架構(gòu)。對于Web應(yīng)用程序來說，微服務(wù)架構(gòu)可以讓應(yīng)用程序的代碼庫更加敏捷，并且容易管理。下面，我們將介紹這個架構(gòu)為何可以大幅提升開發(fā)者生產(chǎn)效率的原因，并了解它能夠快速迭代和擴(kuò)充一個代碼庫的原理。對于快速發(fā)展中的創(chuàng)業(yè)公司來說，微服務(wù)架構(gòu)可以讓開發(fā)團(tuán)隊在研發(fā)過程中更加的敏捷和靈活。

Web開發(fā)簡史

首先，我們先簡潔地回顧下20年內(nèi)基于Web開發(fā)的歷史，它可以讓我們知悉微服務(wù)架構(gòu)為什么可以在Web開發(fā)領(lǐng)域如此的盛行，同時也順便了解這個架構(gòu)可以解決的問題。

在Web應(yīng)用程序開發(fā)的早期，應(yīng)用程序通常使用Common Gateway Interface（CGI）建立，這個接口為網(wǎng)絡(luò)服務(wù)器提供了處理瀏覽器發(fā)來的HTTP請求時執(zhí)行腳本（通常情況下用Perl編寫）的能力。CGI的擴(kuò)展性非常很好，因為它需要為每個輸入請求都建立一個Perl進(jìn)程。為了解決這個問題，那個時代的網(wǎng)絡(luò)服務(wù)器通常都會添加模塊化的支持。Apache，現(xiàn)下最為流行的網(wǎng)絡(luò)服務(wù)器之一，增加了“mod_perl”讓Perl代碼可以在內(nèi)部運(yùn)行，這樣一來，CGI腳本就可以在更少的時間內(nèi)執(zhí)行。

即使對比傳統(tǒng)的CGI類似mod_perl這些技術(shù)有了很大的提升，但仍然存在問題。也就是說，負(fù)責(zé)視圖層（比如，在HTML頁面上執(zhí)行一個動態(tài)模塊）的代碼通常會被混入應(yīng)用程序邏輯代碼中。這就意味著，完成一個簡單的任務(wù)，比如在HTML列表中增加一列，或者在form中增加一個元素，通常需要修改一個低等級的應(yīng)用程序代碼。因此，Web程序開發(fā)技術(shù)下一個階段中衍生了“server pages”，它允許在HTML嵌入執(zhí)行代碼。這樣一來，應(yīng)用程序邏輯代碼與視圖代碼被很好的分離。在Java開發(fā)領(lǐng)域，一個被稱為“Model 2”的設(shè)計模式得以快速演變，在這里，應(yīng)用程序代碼放到Java servlets中，數(shù)據(jù)則通過Java Beans進(jìn)行，視圖層邏輯則使用了Java server pages，詳見下圖：

圖1：Model 2設(shè)計模型

隨后，在Java領(lǐng)域，“Model 2”模式在很短的時間就演化成了“Model-View-Controller（MVC）”框架，比如Apache Struts。而在其他領(lǐng)域，Ruby on Rails則非常盛行。在MVC模式中，控制器類會定義方法，通過“route”類映射成URL模式被調(diào)用。 控制器方法會利用“model”類封核心應(yīng)用程序?qū)嶓w的業(yè)務(wù)邏輯和數(shù)據(jù)。最后，每個控制方法都會渲染一個“view”用于顯示，并修改相應(yīng)模式類的方法。在這種模式下，業(yè)務(wù)、應(yīng)用程序、視圖邏輯被很好的分離，如圖2：

圖2：MVC設(shè)計模型

REST協(xié)議的盛行

就在MVC被廣泛接受并成為網(wǎng)絡(luò)開發(fā)途徑的同時，進(jìn)程間通信（IPC）也開始利用上了基于文本的序列化格式，比如XML和JSON。而在類似SOAP這些協(xié)議實現(xiàn)跨HTTP IPC的不久后，網(wǎng)絡(luò)開發(fā)已不再限制于給瀏覽器建立交付內(nèi)容的應(yīng)用程序，為其他程序執(zhí)行操作和交付數(shù)據(jù)的網(wǎng)絡(luò)服務(wù)也逐漸走上歷史的舞臺。這種基于服務(wù)的架構(gòu)擁有非常強(qiáng)大的功能，因為它消除了代碼庫共享的依賴性，從而開發(fā)者可以更進(jìn)一步的解耦應(yīng)用程序組件。而SOAP協(xié)議和相關(guān)的WS-*標(biāo)準(zhǔn)也變得越來越復(fù)雜，并更加依賴于應(yīng)用程序服務(wù)器的實現(xiàn)，至此開發(fā)者開始投身更為輕量級的REST協(xié)議。同時，隨著移動設(shè)備的劇增，Web UX development逐漸走向AJAX和JavaScript框架，應(yīng)用程序開發(fā)者開始廣泛使用REST在客戶端設(shè)備和網(wǎng)絡(luò)服務(wù)器之間做數(shù)據(jù)傳輸。

后來人們發(fā)現(xiàn)，MVC框架同樣非常適合開發(fā)REST端點。REST面向資源的特性被很好的映射成了控制器和模型理念，如圖3所示：

圖3：MVC的REST端點

Monolithic架構(gòu)

因此，曾今由模型、視圖層、控制器組成，主要用于給應(yīng)用程序交付HTML內(nèi)容的MVC應(yīng)用程序發(fā)生了本質(zhì)上的變化——它們不僅可以支撐傳統(tǒng)的HTML，也可以通過REST端點來支撐JSON。應(yīng)用程序被部署為一個單一的文件（比如Java）或者同一個目錄下的文件合集（比如Rails）。然而不容忽視的是，所有應(yīng)用程序代碼都運(yùn)行在相同的進(jìn)程中。因此在縮放過程中，開發(fā)者需要將應(yīng)用程序代碼的多個副本部署到多個所需的服務(wù)器上。下圖解析了Monolithic架構(gòu)：

圖片4：Monolithic架構(gòu)

在Monolithic架構(gòu)中存在著很多的問題。首先，隨著應(yīng)用程序的功能和服務(wù)越來越多，代碼將變得越來越復(fù)雜。對于新的開發(fā)者來說，這一點非常頭疼。新型集成開發(fā)環(huán)境在加載、編譯整個應(yīng)用程序代碼時也可能存在問題，同時這個過程的耗時也可能非常長。此外，因為所有程序代碼都運(yùn)行在服務(wù)器上的相同進(jìn)程中，導(dǎo)致應(yīng)用程序某個組成的擴(kuò)展也非常難。如果某個服務(wù)是內(nèi)存密集型的，而另一個是CPU密集型的，那么服務(wù)器必須有足夠的內(nèi)存和CPU來滿足每個服務(wù)的需求。因此，鑒于每個服務(wù)器都使用非常高的CPU和內(nèi)存，基礎(chǔ)設(shè)施的整體花費(fèi)可能會非常高，特別是在縱向擴(kuò)展策略下。最后非常微妙的是，應(yīng)用程序的組成通常也會映射到研發(fā)團(tuán)隊的結(jié)構(gòu)上。UX工程師負(fù)責(zé)UI組件的建立，中間層開發(fā)者通常負(fù)責(zé)建立服務(wù)器端點，而數(shù)據(jù)庫工程師和DBA們則負(fù)責(zé)數(shù)據(jù)訪問組件和數(shù)據(jù)庫。如果某個UX工程師期望給增加一些顯示，他往往需要來自中間層和數(shù)據(jù)庫工程師的配合。就像水一樣，人們通常期望以最少的阻力執(zhí)行，每個工程師也都期望為其負(fù)責(zé)的應(yīng)用程序嵌入盡可能多的邏輯。鑒于這些問題，隨著時間的推移，代碼將越來越難以管理。

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

微服務(wù)架構(gòu)的發(fā)明就是用來解決這些問題。定義在Monolithic架構(gòu)應(yīng)用程序中的服務(wù)將拆分成獨(dú)立的服務(wù)，它們在不同的主機(jī)上進(jìn)行獨(dú)立的部署。

圖片5：微服務(wù)架構(gòu)

每個微服務(wù)都對應(yīng)了一個獨(dú)立的業(yè)務(wù)功能，也只定義了該功必須的一些操作。這聽起來比較類似面向服務(wù)架構(gòu)（SOA），事實上，微服務(wù)架構(gòu)和面向服務(wù)的架構(gòu)確實有很多共同的特性。兩個架構(gòu)都使用服務(wù)的模式組織代碼，兩種架構(gòu)在不同的服務(wù)間都建立了非常明確的邊界。然而，面向服務(wù)的架構(gòu)起源于Monolithic應(yīng)用程序交互的需求，通常彼此都會提供一個API（基于SOAP）。在面向服務(wù)架構(gòu)中，集成重度依賴于中間件，特別在企業(yè)服務(wù)總線（EBS）中。微服務(wù)架構(gòu)通常會利用一個消息總線，但是無論任何情況在消息層都不會存在邏輯——它純粹的被用于服務(wù)之間的交互。這與ESB有著非常顯著的差別，ESB包含了大量邏輯——用于消息路由、模式驗證、消息翻譯和業(yè)務(wù)規(guī)則。因此，對比傳統(tǒng)的面向服務(wù)架構(gòu)，微服務(wù)架構(gòu)往往更為簡單，不會包含用于定義服務(wù)間接口的同級別控制和規(guī)范化數(shù)據(jù)建模。通過使用微服務(wù)，開發(fā)將非常快速，服務(wù)的衍變也只需匹配業(yè)務(wù)的需求。

微服務(wù)架構(gòu)的另一個核心優(yōu)勢就是服務(wù)可以基于資源的需求進(jìn)行獨(dú)立擴(kuò)展。取代運(yùn)行包含大量CPU和內(nèi)存的大服務(wù)器，微服務(wù)可以被部署在更小的主機(jī)上，這些主機(jī)只需要滿足其部署服務(wù)的需求。同時，開發(fā)者可以根據(jù)業(yè)務(wù)的需求選擇開發(fā)語言，比如：一個圖像處理服務(wù)可以使用類似C++這樣的高性能語言實現(xiàn)，一個執(zhí)行數(shù)學(xué)或者靜態(tài)操作的服務(wù)可以使用Python實現(xiàn)，對資源進(jìn)行增刪查改的基礎(chǔ)操作則往往通過Ruby進(jìn)行。在微服務(wù)中，開發(fā)者并不需要考慮Monolithic架構(gòu)中使用的“一刀切”模型——比如只使用MVC框架和單一的編程語言。

然而，不容忽視的是，微服務(wù)同樣存在一些劣勢。因為服務(wù)通常部署在多個主機(jī)上，很難持續(xù)跟蹤指定服務(wù)究竟運(yùn)行在某臺主機(jī)上。同時，因為微服務(wù)架構(gòu)使用的主機(jī)容量往往小于Monolithic架構(gòu)，隨著微服務(wù)架構(gòu)不停的橫向擴(kuò)展，主機(jī)數(shù)量將以一個非常恐怖的速度增長。在AWS環(huán)境中，微服務(wù)架構(gòu)中獨(dú)立服務(wù)需要的資源往往會小于最小的EC2實例類型。從而造成了超量配置并浪費(fèi)開銷。此外，如果服務(wù)使用不同的編程語言將開發(fā)，這就意味著每個服務(wù)的部署都需要完全不同的庫和框架，從而服務(wù)的部署非常復(fù)雜。

容器的用武之地

Linux容器技術(shù)的使用可以很大程度上緩解微服務(wù)架構(gòu)所帶來的問題。Linux容器技術(shù)使用了類似cnames和namespaces這樣的內(nèi)核接口，它允許不同容器共享相同的內(nèi)核，同時容器之間還進(jìn)行了完全的隔離。Docker執(zhí)行環(huán)境使用了一個被稱為libcontainer的模塊，它標(biāo)準(zhǔn)化了這些接口。Docker同樣為容器鏡像提供了一個類GitHub的資源庫DockerHub，讓容器的共享和發(fā)布非常簡單，也正是這種相同主機(jī)上的容器隔離簡易了不同語言開發(fā)的微服務(wù)代碼部署。使用Docker，我們可以創(chuàng)建一個DockerFile來描述所有用到的語言、框架和服務(wù)間庫的依賴性。舉個例子，下面代碼中的DockerFile可以用來定義一個微服務(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"

使用這個鏡像建立的容器可以便捷地被部署到一個主機(jī)上，這個主機(jī)同時還運(yùn)行了另一個使用Java和DropWizard 定義的Docker鏡像所建立的容器。容器執(zhí)行緩解隔離了主機(jī)上運(yùn)行的不同容器，因此不存在使用不同語言、庫和框架容器所造成的沖突問題。

同時值得高興的是，近期發(fā)布的Amazon EC2 Container Service（Amazon ECS）可以幫你搞定所有這些工作。使用Amazon ECS，你可以定義一個被稱為“cluster”的計算資源池，一個cluster由一個或以上的EC2實例組成。Amazon ECS負(fù)責(zé)管理集群中所有基于容器的應(yīng)用程序，提供 telemetry和logging，并管理集群的容量優(yōu)化，進(jìn)行高效的任務(wù)調(diào)度。Amazon ECS提供了一個“任務(wù)內(nèi)容（task definition）”的理念，它可以定義組成一個應(yīng)用程序的一組容器。task definition中的每個容器都指定了該容器所需的資源，而Amazon ECS將基于集群中的可用資源來調(diào)度這個任務(wù)的執(zhí)行。

微服務(wù)可以非常便捷地被定義為一個任務(wù)，它可以由兩個容器組成——一個負(fù)責(zé)運(yùn)行服務(wù)終端代碼，另一個負(fù)責(zé)運(yùn)行數(shù)據(jù)庫。Amazon ECS可以管理這些容器之間的依賴性，同時也可以跨集群進(jìn)行資源平衡。同時，Amazon ECS還可以無縫的訪問多個AWS重點服務(wù)，比如Elastic Load Balancing、Amazon EBS、Elastic Network Interface和Auto Scaling。通過Amazon ECS，使用 Amazon EC2部署應(yīng)用程序的所有基本特征都對基于容器的應(yīng)用程序可用。

此外，類似Amazon ECS 這樣的容器解決方案還可以簡化“service discovery（服務(wù)搜尋）”這樣的實現(xiàn)。因為微服務(wù)往往會跨多個主機(jī)部署，并根據(jù)負(fù)載進(jìn)行縮放，service discovery更有利于服務(wù)之間的定位。在最簡單的情況下，可以使用負(fù)載均衡器來進(jìn)行，但是在更為復(fù)雜的環(huán)境中，一個真正的分布式配置服務(wù)非常有必要，比如Apache Zookeeper。使用Amazon ECS API，與類似Zookeeper這樣的第三方工具整合將非常容易。配置了Zookeeper的容器可以被添加到一個task definition中，并可以通過Amazon ECS在集群中的Amazon EC2調(diào)度執(zhí)行。

從許多方面來看，使用容器技術(shù)實施微服務(wù)架構(gòu)轉(zhuǎn)變都與過去20年Web開發(fā)的衍變非常類似。許多這些衍變都是為了更好的利用計算資源，以及更方便的維護(hù)越來越復(fù)雜的Web應(yīng)用程序。如我們所見，使用Linux容器技術(shù)來實現(xiàn)微服務(wù)架構(gòu)完全匹配了這兩個需求。在本文中，我們簡單地接觸了使用Amazon ECS來定義一個微服務(wù)架構(gòu)，但是容器在分布式系統(tǒng)中的使用已經(jīng)遠(yuǎn)超過了微服務(wù)。在分布式系統(tǒng)中，越來越多的容器成為了first class citizens，而在未來的報告中，我將討論為什么 Amazon ECS對管理給予容器的計算是至關(guān)重要的。