云服務(wù)下的最佳拍檔

金琦 邱元陽 劉宗凡 倪俊杰 楊磊

編者按：隨著互聯(lián)網(wǎng)、云計算的高速發(fā)展，人們對數(shù)據(jù)信息化服務(wù)依賴程度越來越深。以往的單體應(yīng)用架構(gòu)和面向服務(wù)化應(yīng)用的架構(gòu)逐漸不能滿足業(yè)務(wù)的需求。而微服務(wù)這種分布式架構(gòu)的興起，是云計算應(yīng)用快速發(fā)展的必然產(chǎn)物，也將是未來整個軟件應(yīng)用架構(gòu)向靈活多變、低耦合、高擴(kuò)展性、動態(tài)伸縮發(fā)展的方向之一。與此同時，以Docker為代表的容器虛擬化技術(shù)將極大減少微服務(wù)應(yīng)用實現(xiàn)大規(guī)模部署、落地的成本。

在上一期的文章中，我們介紹了Docker的概念、基本使用方法、基本使用體驗，可能有的讀者嘗試過搭建Docker環(huán)境，拉取把程序和環(huán)境合在一起的鏡像來運(yùn)行容器，開發(fā)環(huán)境、測試環(huán)境、業(yè)務(wù)使用環(huán)境就能非常方便地保持一致。甚至你會想到既然使用容器技術(shù)能帶來這么多方便.是否能把更多的學(xué)校業(yè)務(wù)進(jìn)行容器化，這樣的想法很好，現(xiàn)在我們耳熟能詳?shù)摹拔⒎?wù)”就是將一個大系統(tǒng)拆分拆解為多個容器，將每一個微服務(wù)單獨部署在云平臺的一個容器中，把多個接口用常用HTTP API進(jìn)行封裝，對外提供一個簡單明了的接口，實現(xiàn)多個個體應(yīng)用服務(wù)部署上的獨立和統(tǒng)一，從而使服務(wù)有更高的可靠性。

第一代顯示技術(shù)CRT

金琦：經(jīng)過一個周期的教育信息化建設(shè)，當(dāng)前教育信息化又衍生和積累了一些新現(xiàn)象和新問題.教育信息化發(fā)展呈現(xiàn)出智能化、開放化，個性化與社交化等特征?！爸腔坌@”逐漸取代“數(shù)字校園”，而云服務(wù)是智慧校園的主要技術(shù)載體。在云服務(wù)模式中，各類資源和應(yīng)用以不同的形式動態(tài)地、碎片化地、按需地提供給師生及管理者，實現(xiàn)對教學(xué).學(xué)習(xí)、管理的無縫服務(wù)，從而使學(xué)校從龐雜的信息化系統(tǒng)建設(shè)中解放出來，更多地關(guān)注教學(xué)和學(xué)習(xí)本身。云服務(wù)具有低成本部署、高效資源應(yīng)用、受客戶端訪問等特征，可大大降低學(xué)校信息化建設(shè)的門檻?！督逃畔⒒?.0行動計劃》明確提出，“充分利用云計算、大數(shù)據(jù)、人工智能等新技術(shù)，構(gòu)建全方位、全過程、全天候的支撐體系，助力教育教學(xué)、管理和服務(wù)的改革發(fā)展”。

邱元陽：云服務(wù)是目前各行業(yè)包括教育行業(yè)廣泛應(yīng)用的一種信息化服務(wù)模式。它采用虛擬化技術(shù)調(diào)配資源（網(wǎng)絡(luò)，服務(wù)器、存儲、應(yīng)用和服務(wù)等），允許用戶根據(jù)需求通過網(wǎng)絡(luò)申請資源，而這些資源以最小化的管理和交互成本來快速供應(yīng)和釋放。云服務(wù)主要分為三種服務(wù)模式（如圖1），這個分法主要是從用戶體驗的角度出發(fā)的。

（1）基礎(chǔ)設(shè)施即服務(wù)（laaS.Infrastructure as aService），是指用戶通過網(wǎng)絡(luò)可以獲得計算機(jī)基礎(chǔ)設(shè)施的服務(wù)。目前主要通過虛擬化技術(shù)采用模塊化建設(shè)，對計算、存儲、網(wǎng)絡(luò)、安全等基礎(chǔ)IT設(shè)施進(jìn)行資源池化，通過統(tǒng)一的云平臺管理系統(tǒng)實現(xiàn)自動化、智能化、集中化的業(yè)務(wù)編排和調(diào)度管理。目前對學(xué)校來說，關(guān)心的是由各類大數(shù)據(jù)采集器、傳感器、網(wǎng)絡(luò)設(shè)備等構(gòu)成能夠識別學(xué)生不同訴求并提供個性化學(xué)習(xí)模式的物聯(lián)網(wǎng)環(huán)境。

（2）平臺即服務(wù)（PaaS，Platform as a Service）.是指把軟件開發(fā)的平臺作為一種可以獲得的服務(wù)，交給用戶使用。主要實現(xiàn)平臺核心組件，包括設(shè)備管理，通信協(xié)議互聯(lián)、流媒體處理、安全管理、移動服務(wù)管理等。目前對學(xué)校來說，關(guān)心的是為師生建立起統(tǒng)一的便捷的資源獲取途徑及資源平臺。

（3）軟件即服務(wù)（saaS，Software as a Service），是指用戶不需要購買并安裝軟件，直接使用服務(wù)商云端提供的軟件，只需管理自己的業(yè)務(wù)數(shù)據(jù)就可以了。對學(xué)校來說，關(guān)心的是覆蓋校園各類管理、教務(wù)教學(xué)、個性學(xué)習(xí)和評測、云盤和云桌面等功能，能夠隨時隨地為學(xué)生、教師、家長、公眾等不同用戶提供全方位、個性化的全流程應(yīng)用與服務(wù)。

劉宗凡：上面講的云服務(wù)體系架構(gòu)從用戶體驗角度的確容易理解，因為從這個角度而言，它們之間關(guān)系是獨立的，畢竟它們面對不同類型的用戶。另外，我們也可以從技術(shù)角度理解，就這個角度而言.它們并不是簡單的繼承關(guān)系（PaaS基于Iaa.而SaaS基于PaaS）.因為首先SaaS可以是基于PaaS或者直接部署于laaS之上，其次PaaS可以構(gòu)建于laaS之上，也可以直接構(gòu)建在物理資源之上。有了Docker的加入，PaaS將有更大的發(fā)揮空間，甚至在云計算的基礎(chǔ)領(lǐng)域部分取代laaS。目前的laaS只是取代了傳統(tǒng)的服務(wù)器，其環(huán)境和應(yīng)用的部署與傳統(tǒng)相比差異很小，只是在運(yùn)維上有很大的改變。PaaS這種開關(guān)式的環(huán)境搭建顯然比laaS要方便很多，符合技術(shù)發(fā)展的趨勢。如果只是為部署一般應(yīng)用，PaaS就可以勝任，但laaS大行其道的原因就是，每個應(yīng)用方都有不同的需求，而有些獨特的需求在公有云模板化的運(yùn)行環(huán)境中無法支撐.這樣超出模板外的需求可用Web API來實現(xiàn)，如果對資源有需求則用單獨的laaS來實現(xiàn)，這樣就可以覆蓋多數(shù)需求。

在PaaS層中，以前都是服務(wù)商提供應(yīng)用開發(fā)框架和部署工具，大多數(shù)PaaS解決方案都用容器來定義應(yīng)用單元，隔離和管理應(yīng)用運(yùn)行。但是，在一個傳統(tǒng)的PaaS中，應(yīng)用容器是被平臺控制的，對用戶是不可見的。一個叫DotCloud的PaaS服務(wù)商認(rèn)識到用戶對底層的容器技術(shù)更感興趣，于是在2013年將其容器技術(shù)開源，這就是后來的Docker，將應(yīng)用容器的控制權(quán)從平臺服務(wù)商交到用戶手中，是一個明智的選擇。現(xiàn)在應(yīng)用容器可以被用做一個可插拔的應(yīng)用交付和運(yùn)維單元，這樣應(yīng)用方的信息化建設(shè)就可以不再被鎖定到一個平臺上了。在Docker的體系中，關(guān)鍵的有兩個——Docker Register和Docker Engine，前者負(fù)責(zé)構(gòu)建和分發(fā)應(yīng)用鏡像，后者負(fù)責(zé)構(gòu)建容器。這樣的組合方式.符合云服務(wù)中的軟件即服務(wù)（SaaS）理念，用戶可以在各自的數(shù)據(jù)中心內(nèi)建立私有的Docker Register，形成屬于自己的私有集群，以應(yīng)對大規(guī)模的應(yīng)用擴(kuò)展需求。Docker很像一個集裝箱，通過LXC技術(shù)先進(jìn)行整合鏡像，再集中匯總進(jìn)行分發(fā)。特點體現(xiàn)在，具有標(biāo)準(zhǔn)的鏡像結(jié)構(gòu)既實現(xiàn)了對不同資源實行不同存儲的功能，也能滿足大規(guī)模的托管服務(wù)，對于有主機(jī)集群的云服務(wù)平臺，通過分解應(yīng)用構(gòu)建。發(fā)布等方式實現(xiàn)對云計算技術(shù)的開發(fā)，在實現(xiàn)云服務(wù)平臺的構(gòu)建的同時，還可以進(jìn)行優(yōu)化和自動化維護(hù)環(huán)境，使得工作效率能夠得到有效提升，在降低成本的同時，滿足了接下來我們要重點討論的微服務(wù)架構(gòu)所需要的資源。

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

金琦：以前教育行業(yè)的軟件架構(gòu)多為單體架構(gòu)，信息化業(yè)務(wù)單一，系統(tǒng)構(gòu)建并不復(fù)雜，所有的代碼、數(shù)據(jù)庫、業(yè)務(wù)文件都部署在一臺機(jī)器上，即使碰到類似閱卷、選課并發(fā)訪問量大的情況.應(yīng)對也就是對硬件軟件進(jìn)行改造（如增加緩存，把應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)進(jìn)行分離、單機(jī)改為集群），這依然是單體架構(gòu)的思想。但隨著學(xué)校信息化的進(jìn)一步發(fā)展，對軟件的依賴也逐漸加深，需要信息化部門為學(xué)校加速業(yè)務(wù)處理效率和提高數(shù)據(jù)挖掘能力的時候，通常就會遇到“信息孤島”，即學(xué)校的業(yè)務(wù)數(shù)據(jù)沉淀在應(yīng)用內(nèi)部，無法被其他應(yīng)用有效使用。應(yīng)用程序孤島效應(yīng)主要集中在業(yè)務(wù)和數(shù)據(jù)的兩個方面。業(yè)務(wù)模塊只能在應(yīng)用程序的邊界內(nèi)使用，無法突破邊界提供外部的調(diào)用。數(shù)據(jù)也同樣被應(yīng)用程序看作是程序的一部分，數(shù)據(jù)的產(chǎn)生、讀取、寫入，定義解釋都強(qiáng)依賴于應(yīng)用程序的代碼，甚至于脫離應(yīng)用程序代碼，數(shù)據(jù)就會變成一堆無法讀懂的垃圾數(shù)據(jù)。此時的學(xué)校信息化服務(wù)就逐漸成為業(yè)務(wù)信息流動的阻礙，進(jìn)而成為學(xué)校業(yè)務(wù)進(jìn)一步發(fā)展的阻礙.但是此時的學(xué)校又沒有足夠的資源去突破“孤島”。

倪俊杰：其實業(yè)界對單體系統(tǒng)并不是沒有解決方案，而且解決方案很早就提出來了，就是SOA（面向服務(wù)架構(gòu)），其大致的意思就是在不破壞應(yīng)用程序獨立性的前提下，由應(yīng)用程序把功能以服務(wù)的形式暴露，提供給外部通過標(biāo)準(zhǔn)協(xié)議進(jìn)行調(diào)用，實現(xiàn)需求方各個應(yīng)用之間的交互和協(xié)作，達(dá)到打破應(yīng)用“孤島”效應(yīng)的效果。但SOA事實上是針對大型企業(yè)的特點，如遵從企業(yè)服務(wù)總線對項目模塊化，而非學(xué)校比較需要的服務(wù)模塊化，所以從部分學(xué)校的SOA實踐來看，其實施效果并不理想。主要的原因在于不同應(yīng)用的服務(wù)之間協(xié)作涉及到大量和各自業(yè)務(wù)相關(guān)的數(shù)據(jù)操作，各應(yīng)用缺乏統(tǒng)一業(yè)務(wù)處理流程，難以統(tǒng)一。所以從學(xué)校的角度來看，為了實現(xiàn)SOA需要對應(yīng)用進(jìn)行大量的定制化開發(fā)，實施難度和代價都比較高：平臺升級需要重新構(gòu)建、編譯、打包部署，學(xué)校應(yīng)用整個服務(wù)層是有多少個服務(wù)實例就必須要有多少個配套的虛擬機(jī)工作才能把這套系統(tǒng)支撐起來，總體看運(yùn)維成本也比較高，制約了SOA在學(xué)校的推廣和落地的速度。但是通過應(yīng)用之間的聯(lián)通來打破“孤島效應(yīng)”，實現(xiàn)學(xué)校應(yīng)用之間的高效協(xié)作，是提高學(xué)校業(yè)務(wù)運(yùn)轉(zhuǎn)效率的一種正確的方式。我們不能簡單地說一種架構(gòu)比另一種架構(gòu)更好，這主要取決于正在構(gòu)建的應(yīng)用程序的目的。SOA更適合需要與許多其他應(yīng)用程序集成的大型復(fù)雜企業(yè)應(yīng)用程序環(huán)境。也就是說，小型應(yīng)用程序不適合SOA架構(gòu)，因為它們不需要消息中間件組件。而微服務(wù)架構(gòu)可以為開發(fā)人員提供更大的控制權(quán)，所以更適合于學(xué)校這樣可以較小和良好地分割并有基于Web系統(tǒng)和移動應(yīng)用的使用場景，所以SOA和微服務(wù)這兩種不同類型的體系結(jié)構(gòu)是根據(jù)不同的場景需求來選擇的。

邱元陽：關(guān)于微服務(wù).本刊2017年第7期《弱水三千，只需一腦殼足矣——容器與微服務(wù)》一文做了簡單且形象的類比說明，接下來我們對微服務(wù)做個深入闡述，微服務(wù)可以看作是SOA服務(wù)化的升級版，微服務(wù)是一種架構(gòu)風(fēng)格.其概念源于Martin Fowler在2014年寫的—篇博文Micro services，他提出微服務(wù)是一種架構(gòu)風(fēng)格，提倡將應(yīng)用系統(tǒng)按照一定的原則將大系統(tǒng)拆分成一系列小型服務(wù)，每個服務(wù)只需要專注于單一的業(yè)務(wù)功能即可，并且服務(wù)之間可以互相獨立運(yùn)行，采用輕量級HTTP API進(jìn)行通信，來滿足業(yè)務(wù)和用戶的需求。其強(qiáng)調(diào)服務(wù)的獨立性、無狀態(tài)、功能職責(zé)單一化，強(qiáng)調(diào)通過多個微服務(wù)的組合實現(xiàn)復(fù)雜業(yè)務(wù)，強(qiáng)調(diào)通過服務(wù)的替換和升級實現(xiàn)對企業(yè)業(yè)務(wù)的敏捷支持。通過將服務(wù)細(xì)分，微服務(wù)有望解決SOA過程中的“大”和“笨重”的問題，真正實王見IT對業(yè)務(wù)支持的“隨需而動”。

在傳統(tǒng)經(jīng)典分層架構(gòu)模式下（如表現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層），業(yè)務(wù)雖然在邏輯劃分上有模塊和組件，但常作為一個整體進(jìn)行編譯、打包、部署、運(yùn)維，因此在物理部署層面依然是一個“單塊”。圍繞這種架構(gòu)模式，我們可以看到很多常用的IDE集成開發(fā)環(huán)境和編程框架（如eclipse、spring等），它們?yōu)殚_發(fā)者提供便捷的開發(fā)、調(diào)試、測試、部署等體驗，讓開發(fā)者可以通過工具、框架快速生成應(yīng)用原型而不必將大量精力花在服務(wù)分解和分布式設(shè)計上。但是伴隨著業(yè)務(wù)和功能的累積擴(kuò)張，應(yīng)用體積也隨機(jī)迅速擴(kuò)大，單塊架構(gòu)難以適應(yīng)這種快速變化的需求，并且面臨開發(fā)效率低、交付周期長、技術(shù)轉(zhuǎn)型難等一系列的挑戰(zhàn)。

微服務(wù)架構(gòu)則是從架構(gòu)層面出發(fā)，將應(yīng)用系統(tǒng)按照一定的邊界分解成一系列的獨立微服務(wù)（如圖2），每個微服務(wù)與傳統(tǒng)應(yīng)用中的邏輯模塊或組件相當(dāng).但是可以獨立地進(jìn)行編譯、部署、運(yùn)行，具有獨立部署、復(fù)雜度可控、技術(shù)選型靈活和高擴(kuò)展性的特征。微服務(wù)的主要優(yōu)點有：職責(zé)單一，每個服務(wù)只做一件事情，并通過定義良好的接口清晰表述服務(wù)邊界：業(yè)務(wù)粒度微小，由于體積小、復(fù)雜度低，每個微服務(wù)可由一個小規(guī)模開發(fā)團(tuán)隊完全掌控，易于保持高可維護(hù)性和開發(fā)效率：隔離性好，每個微服務(wù)都可以獨立部署，互相隔離，互不影響，一個服務(wù)停機(jī)不會影響其他服務(wù)：管理容易，每個服務(wù)可以獨立地進(jìn)行開發(fā)部署，可以針對業(yè)務(wù)特點使用不同的開發(fā)語言，系統(tǒng)不會長期限制在某個技術(shù)上：微服務(wù)的系統(tǒng)架構(gòu)還讓微服務(wù)與微服務(wù)之間在結(jié)構(gòu)上“松耦合”，而在功能上則表現(xiàn)為一個統(tǒng)一的整體。這種所謂的“統(tǒng)一的整體”表現(xiàn)出來的是統(tǒng)一風(fēng)格的界面、統(tǒng)一的權(quán)限管理、統(tǒng)一的安全策略、統(tǒng)一的上線過程、統(tǒng)一的日志和審計方法、統(tǒng)一的調(diào)度方式、統(tǒng)一的訪問入口等。

當(dāng)然.像任何其他技術(shù)一樣，微服務(wù)架構(gòu)也存在不足，主要表現(xiàn)在：

（1）通信成本高。在單體應(yīng)用中的一個函數(shù)或進(jìn)程調(diào)用在微服務(wù)架構(gòu)下可能變成了一個HTTP遠(yuǎn)程調(diào)用，網(wǎng)絡(luò)延遲會帶來更長的耗時.造成更高的通信成本。

（2）數(shù)據(jù)一致性問題。在單體應(yīng)用中數(shù)據(jù)通常存儲在一個數(shù)據(jù)庫中，保證數(shù)據(jù)的—致性很容易，而在微服務(wù)架構(gòu)下，通常不同的微服務(wù)有不同的數(shù)據(jù)庫，但往往一個操作可能會涉及多個微服務(wù)的互相調(diào)用，當(dāng)服務(wù)很多時整個調(diào)用鏈路變長，調(diào)用失敗的風(fēng)險高，在這種分布式架構(gòu)下更難保證數(shù)據(jù)的一致性和可靠性。

（3）部署復(fù)雜。微服務(wù)化后服務(wù)實例變多，造成更多需要部署、配置和監(jiān)控的部分，此外，一個應(yīng)用的改變可能會波及多個服務(wù).擴(kuò)展和監(jiān)控難度更大。微服務(wù)架構(gòu)在容器云中的實踐

金琦：將業(yè)務(wù)系統(tǒng)組件化和服務(wù)化的“微服務(wù)技術(shù)”，為系統(tǒng)建設(shè)者提供了一個更好的選擇，讓系統(tǒng)建設(shè)者更專注于解決業(yè)務(wù)問題本身。通過前面的討論，我們已經(jīng)了解了單體應(yīng)用、SOA和微服務(wù)應(yīng)用的優(yōu)點和缺點。在實際的業(yè)務(wù)場景中，我們應(yīng)該怎么去規(guī)劃和構(gòu)建屬于學(xué)校自己的微服務(wù)呢？

楊磊：對于“微服務(wù)”的概念以及特點相信大家已經(jīng)有一定的了解了，其實單從概念來說.是比較容易理解的。那應(yīng)該如何把一個單體應(yīng)用拆分成多個微服務(wù)呢？下面我以“課堂考勤辦公業(yè)務(wù)”為例，通過對該單體應(yīng)用的拆分，一起來了解一下微服務(wù)體系應(yīng)該有哪些構(gòu)成。

首先，我們從學(xué)校集成門戶界面中訪問課堂考勤辦公業(yè)務(wù)，可以將這個業(yè)務(wù)拆分成三個獨立的子微服務(wù)：學(xué)校排課微服務(wù).學(xué)生選課微服務(wù)、數(shù)據(jù)中心微服務(wù)。

（1）學(xué)校排課微服務(wù)。包含根據(jù)時間點全校所有教學(xué)班排課的XML表，建立對應(yīng)排課Javabean對象，然后利用JDK自帶的JAXB解析包，可以方便地將該XML表解析轉(zhuǎn)換成排課對象，并對外暴露接口/courseschedule，提供排課列表Json數(shù)據(jù)。

（2）學(xué)生選課微服務(wù)。該模塊依賴數(shù)據(jù)中心微服務(wù)，完成學(xué)生選課功能，并公布選課情況接口/report/t class_selection/{class_selection}。

（3）數(shù)據(jù)中心微服務(wù)。公布教師信息接口/report/teacherlD/{teacherlD}和公布學(xué)生信息接口/report/studentlD/{studentlD}。

其次.我們結(jié)合開發(fā)框架Spring cloud來闡述一下“微服務(wù)”在技術(shù)層面的實現(xiàn)和架構(gòu)。Spring Cloud是一系列框架、組件的有序集合，擁有功能完善的、輕量級的微服務(wù)實現(xiàn)組件，如服務(wù)發(fā)現(xiàn)治理、服務(wù)容錯、服務(wù)網(wǎng)關(guān)、服務(wù)配置，負(fù)載均衡、消息總線、服務(wù)跟蹤等方面均有經(jīng)過實踐檢驗的成熟組件。系統(tǒng)采用Eureka做服務(wù)注冊與發(fā)現(xiàn)，Zuul做路由API網(wǎng)關(guān)，Ribbon做負(fù)載均衡，Hystrix做服務(wù)熔斷，Spring Cloud Config做統(tǒng)一管理微服務(wù)配置。

這樣，微服務(wù)的基礎(chǔ)組件就都有了，結(jié)合上一步拆分出的微服務(wù)，可做出如圖3所示的架構(gòu)圖。

從圖3中可以看到一所學(xué)校有諸如“學(xué)校排課…數(shù)據(jù)中心”等多個業(yè)務(wù)，拆分多個模塊后，就會出現(xiàn)多樣的問題，而springCloud提供了一整套的解決方案，從而可以統(tǒng)一管理各服務(wù)中心的配置，并且在運(yùn)行期間可以動態(tài)修改配置文件。

CAS解決學(xué)校的師生在多個微服務(wù)之間切換時，需要重復(fù)登錄的問題完成統(tǒng)一認(rèn)證。

ZUUL網(wǎng)關(guān)根據(jù)URL轉(zhuǎn)發(fā)請求到不同的微服務(wù)。例如，教師用戶請求訪問課堂考勤微服務(wù)接口，網(wǎng)關(guān)再把所有請求轉(zhuǎn)發(fā)到具體的學(xué)校排課。學(xué)生選課、數(shù)據(jù)中心相關(guān)微服務(wù)中，其中的映射關(guān)系如下：

Eureka專門給各種服務(wù)提供注冊登記，配置服務(wù)注冊中心的URL地址。一個微服務(wù)就是一個節(jié)點，是一個完整的應(yīng)用程序，并且可獨立運(yùn)行部署。系統(tǒng)除了前面和業(yè)務(wù)相關(guān)的微服務(wù)外，還有API網(wǎng)關(guān)節(jié)點、配置中心Config—Server節(jié)點，Turbine的Hystrix監(jiān)控節(jié)點等。這些節(jié)點都是以Eureka客戶端形式注冊在Eureka服務(wù)端，然后各個節(jié)點間采用輕量級Feign組件就可以實現(xiàn)相互調(diào)用通信了，同時也實現(xiàn)了對各種服務(wù)可用性的監(jiān)控。

Ribbon是支持負(fù)載均衡，默認(rèn)的負(fù)載均衡策略是輪詢，我們也可以根據(jù)自己實際的需求自定義負(fù)載均衡策略。

Hystrix通過添加延遲容忍和容錯邏輯，幫助控制這些分布式服務(wù)之間的交互。Hystrix通過隔離服務(wù)之間的訪問點、停止級聯(lián)失敗和提供回退選項來實現(xiàn)這一點，這些都可以提高系統(tǒng)的整體彈性。

金琦：我們做了服務(wù)的拆分，也完成了單個微服務(wù)的技術(shù)實現(xiàn)，為了讓微服務(wù)可以為學(xué)生和教師提供服務(wù)，需要將完成的微服務(wù)進(jìn)行部署上線。針對微服務(wù)的部署，有什么最佳的實踐呢？

劉宗凡：基于微服務(wù)的思想是可以不用容器技術(shù)的.但由于微服務(wù)應(yīng)用由數(shù)十甚至上百個服務(wù)組成，服務(wù)使用不同的語言和框架編寫。每個服務(wù)都是一個迷你應(yīng)用，有自己特定的部署.資源、擴(kuò)展和監(jiān)視要求。例如，需要根據(jù)服務(wù)的需求為每個服務(wù)運(yùn)行一定數(shù)量的實例。此外.必須為每個服務(wù)實例提供相應(yīng)的CPU、內(nèi)存和I/O資源。更有挑戰(zhàn)性的是.盡管如此復(fù)雜.部署服務(wù)也必須要快速、可靠和具有成本效益。所以我們只是利用容器化技術(shù)簡化微服務(wù)創(chuàng)建、集成、部署、運(yùn)維的整個流程，推動微服務(wù)在云端的大規(guī)模實踐，下面以一個容器云平臺為例，說明各個流程的實踐（如圖4）。

（1）在容器云平臺，用戶可以很方便地創(chuàng)建微服務(wù)項目，并在項目中與代碼倉庫進(jìn)行關(guān)聯(lián)，輕松選擇代碼項目進(jìn)行構(gòu)建。每當(dāng)開發(fā)人員提交代碼時，系統(tǒng)可以自動將存于代碼倉庫的微服務(wù)程序快速構(gòu)建成新的容器鏡像，經(jīng)過持續(xù)集成自動化驗證后轉(zhuǎn)化為隨時可以部署的容器鏡像.用戶可以將這個微服務(wù)一鍵部署到容器云平臺上。

（2）在鏡像倉庫支持加入平臺以外的任意鏡像源.如可以加入Docker官方和社區(qū)的優(yōu)質(zhì)鏡像，用戶可以根據(jù)自己的業(yè)務(wù)需要.像搭積木一樣自由組合、復(fù)用各種容器化微服務(wù)，輕松集成應(yīng)用。例如，用戶需要一個通用的tomcat網(wǎng)站服務(wù)或者M(jìn)ySQL數(shù)據(jù)庫，可以直接在鏡像中選擇適合的數(shù)據(jù)庫服務(wù)鏡像，并與其業(yè)務(wù)連接起來?？梢砸淮尾渴鸲鄠€鏡像并為每個鏡像的容器設(shè)定CPU和內(nèi)存占用。從配置部署到啟動只需要幾分鐘。

（3）平臺支持升級回滾。平臺部署有完整的版本管理，每次升級會生成一個部署版本，可以隨意選擇一個舊版本進(jìn)行回滾，部署出現(xiàn)異常時可以指定版本恢復(fù)。

我們用Docker容器快速編排所有節(jié)點，其中這三個示例的微服務(wù)節(jié)點都要啟動三個實例以作負(fù)載均衡。系統(tǒng)運(yùn)行在阿里云服務(wù)器上，不同節(jié)點采用不同的端口，如學(xué)校排課微服務(wù)microservice-classschedules-report提供面向用戶接口/report/classscheduleslD/{classscheduleslD}，供用戶查詢學(xué)校最新的排課數(shù)據(jù)。同時訪問Turbine聚合節(jié)點，可以監(jiān)控多個微服務(wù)運(yùn)行狀態(tài)。

后記

雖然微服務(wù)架構(gòu)帶來了諸多優(yōu)勢，但構(gòu)建、部署、維護(hù)分布式的微服務(wù)系統(tǒng)并不容易。而容器所提供的輕量級的、面向應(yīng)用的虛擬化運(yùn)行環(huán)境為微服務(wù)提供了理想的載體。同樣，基于容器技術(shù)的云服務(wù)將極大地簡化容器化微服務(wù)創(chuàng)建、集成、部署、運(yùn)維的整個流程，從而推動微服務(wù)在云端的大規(guī)模實踐。

構(gòu)建復(fù)雜的應(yīng)用確實非常困難，而微服務(wù)架構(gòu)模式可以使構(gòu)建復(fù)雜應(yīng)用變得簡單化。微服務(wù)架構(gòu)的誕生和容器技術(shù)的流行幾乎是同時發(fā)生的，是互聯(lián)網(wǎng)時代倒逼傳統(tǒng)技術(shù)和架構(gòu)而產(chǎn)生的變革，基于容器技術(shù)的PaaS平臺給開發(fā)者提供了一個部署和管理微服務(wù)的簡單方法，它把所有這些問題都打包內(nèi)置解決了。