【技術(shù)分享】基于容器云的微服務(wù)架構(gòu)實(shí)踐
微服務(wù)架構(gòu)的誕生和容器技術(shù)的流行，幾乎是同時(shí)發(fā)生的，這并非偶然，而是互聯(lián)網(wǎng)時(shí)代倒逼傳統(tǒng)技術(shù)和架構(gòu)而產(chǎn)生的變革，而以Docker為代表的容器技術(shù)則為微服務(wù)理念提供了匹配的實(shí)現(xiàn)機(jī)制，本文作者從什么是微服務(wù)切入，詳細(xì)的介紹了微服務(wù)架構(gòu)的優(yōu)勢(shì)，最后從自身實(shí)踐出發(fā)，給出了微服務(wù)架構(gòu)的云端實(shí)踐。
近年來(lái)，微服務(wù)架構(gòu)及容器技術(shù)備受關(guān)注，在各類文章、演講、博客中頻頻亮相，成為業(yè)界最熱門的話題。在時(shí)尚的詞匯和熱情滿滿的討論背后，人們開(kāi)始嚴(yán)肅的重新思考互聯(lián)網(wǎng)時(shí)代服務(wù)的架構(gòu)以及應(yīng)用開(kāi)發(fā)、運(yùn)維的方法。微服務(wù)以一種全新的架構(gòu)設(shè)計(jì)模式，牽動(dòng)了互聯(lián)網(wǎng)應(yīng)用從設(shè)計(jì)到運(yùn)維整個(gè)流程方法論的變革。 而以Docker為代表的容器技術(shù)則為微服務(wù)理念提供了匹配的實(shí)現(xiàn)機(jī)制，進(jìn)而實(shí)質(zhì)性的改變了新一代應(yīng)用開(kāi)發(fā)和發(fā)布的方式。
什么是微服務(wù)架構(gòu)?
微服務(wù)架構(gòu)(Microservices Architecture)是一種架構(gòu)風(fēng)格(Architectural Style)和設(shè)計(jì)模式，提倡將應(yīng)用分割成一系列細(xì)小的服務(wù)，每個(gè)服務(wù)專注于單一業(yè)務(wù)功能，運(yùn)行于獨(dú)立的進(jìn)程中，服務(wù)之間邊界清晰，采用輕量級(jí)通信機(jī)制(如HTTP/REST)相互溝通、配合來(lái)實(shí)現(xiàn)完整的應(yīng)用，滿足業(yè)務(wù)和用戶的需求。
微服務(wù)作為架構(gòu)模式的變革，其誕生絕非偶然。它是當(dāng)傳統(tǒng)服務(wù)架構(gòu)在互聯(lián)網(wǎng)時(shí)代遭遇挑戰(zhàn)時(shí)，人們對(duì)于架構(gòu)模式，開(kāi)發(fā)和運(yùn)維方法論的一種反思。所以，在深入探討微服務(wù)架構(gòu)之前，我們先回顧一下更為普遍的傳統(tǒng)服務(wù)架構(gòu)。
傳統(tǒng)“單塊架構(gòu)”：
在過(guò)去的10多年中，甚至是微服務(wù)日趨流行的當(dāng)下，絕大多數(shù)應(yīng)用采用的仍是我們更為熟悉的傳統(tǒng)架構(gòu)，稱之為 “單塊架構(gòu)(Monolithic Architecture)”模式。此類架構(gòu)系統(tǒng)通常以技術(shù)分層，例如最常見(jiàn)的“分層架構(gòu)”中的表現(xiàn)層、業(yè)務(wù)邏輯層、數(shù)據(jù)層。而業(yè)務(wù)邏輯則可根據(jù)更具體的業(yè)務(wù)職責(zé)、功能進(jìn)行模塊化，形成邏輯組件。這里需要提一下的是，“分層架構(gòu)”雖然有邏輯上的模塊和組件，但在物理部署架構(gòu)層面仍是一個(gè)“單塊”，通常作為一個(gè)整體編譯、打包、部署、運(yùn)維。“單塊架構(gòu)”便是從物理部署角度，對(duì)于包括“分層架構(gòu)”在內(nèi)的應(yīng)用架構(gòu)模式的一種定義。
“分層架構(gòu)”是軟件架構(gòu)體系中的經(jīng)典模式，也是長(zhǎng)時(shí)間來(lái)應(yīng)用架構(gòu)實(shí)際上的標(biāo)準(zhǔn)。而單塊架構(gòu)也有其一定優(yōu)勢(shì)，體現(xiàn)為：
便于開(kāi)發(fā)：大量常用的集成開(kāi)發(fā)環(huán)境(IDE)和編程框架(如Rails，Django)都是圍繞傳統(tǒng)架構(gòu)下單塊應(yīng)用設(shè)計(jì)的。這些工具為開(kāi)發(fā)者提供了方便和熟悉的開(kāi)發(fā)、調(diào)試體驗(yàn);
便于測(cè)試：由于整個(gè)應(yīng)用包含在一個(gè)進(jìn)程中，在常用工具的配合下應(yīng)用可以很容易在開(kāi)發(fā)、測(cè)試環(huán)境中啟動(dòng)。然后采用UI自動(dòng)化工具(如Selenium)便可簡(jiǎn)單實(shí)現(xiàn)End-to-End測(cè)試;
便于部署：多數(shù)編程語(yǔ)言和框架都有特定的應(yīng)用打包格式。部署只需將單一軟件包復(fù)制到運(yùn)行環(huán)境。而這一過(guò)程也可通過(guò)現(xiàn)有工具實(shí)現(xiàn)自動(dòng)化。
由于這些優(yōu)點(diǎn)，在項(xiàng)目初期，單塊架構(gòu)有一定的吸引力。開(kāi)發(fā)者可以通過(guò)工具、框架快速生成應(yīng)用原型，而不必花大量精力在服務(wù)分解和分布式架構(gòu)設(shè)計(jì)上。但隨著業(yè)務(wù)的擴(kuò)張和功能的累積，原本簡(jiǎn)單的應(yīng)用體積會(huì)迅速變大，此時(shí)單塊架構(gòu)很難適應(yīng)快速變更的需求，由于架構(gòu)層面的局限性，這類應(yīng)用會(huì)面臨多重挑戰(zhàn)。
開(kāi)發(fā)效率低：隨著應(yīng)用復(fù)雜度的增加，越來(lái)越少開(kāi)發(fā)人員對(duì)應(yīng)用能有全局性的深度理解。新功能開(kāi)發(fā)和缺陷修復(fù)難度呈幾何性增加。代碼修改的正確性無(wú)法保障。而龐大的代碼庫(kù)需要更龐大的開(kāi)發(fā)團(tuán)隊(duì)來(lái)維護(hù)，無(wú)形中又增添了管理、溝通和協(xié)調(diào)的成本。另外，新加入的團(tuán)隊(duì)成員需要花費(fèi)大量的時(shí)間和精力來(lái)熟悉一個(gè)復(fù)雜的代碼庫(kù)。
交付周期長(zhǎng)：在單一進(jìn)程的單塊架構(gòu)下，任何微小的改動(dòng)都需要重新編譯、集成、測(cè)試和部署整個(gè)應(yīng)用。隨著應(yīng)用體積的增大，交付流程和反饋周期都會(huì)相應(yīng)變長(zhǎng)，應(yīng)用發(fā)布的代價(jià)也隨之增加。于是應(yīng)用交付周期變緩，交付間隙積累的代碼變動(dòng)增加，從而對(duì)于下次交付產(chǎn)生更大的壓力，形成惡性循環(huán)。
技術(shù)轉(zhuǎn)型難：?jiǎn)我贿M(jìn)程、單塊架構(gòu)意味著中心化的技術(shù)選型。比如，應(yīng)用的不同邏輯組建通常需要采用相對(duì)統(tǒng)一的編程語(yǔ)言、框架和技術(shù)棧。這些在項(xiàng)目初始階段便已定型。之后，即便是應(yīng)用中全新的邏輯組件，也很難采用不同的技術(shù)棧。而當(dāng)應(yīng)用達(dá)到一定規(guī)模后，全局化的技術(shù)棧更新會(huì)面臨很高的風(fēng)險(xiǎn)。所以，單塊架構(gòu)應(yīng)用一旦定型，就很難再享受行業(yè)技術(shù)變更、發(fā)展所帶來(lái)的紅利。
由于這些結(jié)構(gòu)性、系統(tǒng)性問(wèn)題的存在，單塊架構(gòu)下的應(yīng)用越來(lái)越難適應(yīng)互聯(lián)網(wǎng)時(shí)代快速變更的市場(chǎng)需求。微服務(wù)便是從架構(gòu)層面出發(fā)，推動(dòng)傳統(tǒng)應(yīng)用開(kāi)發(fā)、運(yùn)維方式的變革，從而幫助企業(yè)快速響應(yīng)市場(chǎng)需求、快速迭代、快速交付，在互聯(lián)網(wǎng)時(shí)代保持競(jìng)爭(zhēng)力。
微服務(wù)架構(gòu)的優(yōu)勢(shì)：
在微服務(wù)架構(gòu)下，我們將原本單一的應(yīng)用按照功能邊界分解成一系列獨(dú)立、專注的微服務(wù)。每個(gè)微服務(wù)對(duì)應(yīng)傳統(tǒng)應(yīng)用中的一個(gè)組件，但是可以獨(dú)立編譯、部署和擴(kuò)展。相對(duì)單塊架構(gòu)，微服務(wù)具備以下優(yōu)勢(shì)：
復(fù)雜度可控：在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無(wú)止境的積累。每一個(gè)微服務(wù)專注于單一功能，并通過(guò)定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個(gè)微服務(wù)可由一個(gè)小規(guī)模開(kāi)發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開(kāi)發(fā)效率;
獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無(wú)需編譯、部署整個(gè)應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。
技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個(gè)微服務(wù)相對(duì)簡(jiǎn)單，當(dāng)需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)較低，甚至完全重構(gòu)一個(gè)微服務(wù)也是可行的。
容錯(cuò)：當(dāng)某一組建發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過(guò)重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。
擴(kuò)展：?jiǎn)螇K架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展。
#p#
微服務(wù)架構(gòu)的云端實(shí)踐
雖然微服務(wù)架構(gòu)帶來(lái)了諸多優(yōu)勢(shì)，但必須承認(rèn)，構(gòu)建，部署，維護(hù)分布式的微服務(wù)系統(tǒng)并不容易。而容器所提供的輕量級(jí)、面向應(yīng)用的虛擬化運(yùn)行環(huán)境為微服務(wù)提供了理想的載體。同樣，基于容器技術(shù)的云服務(wù)將極大的簡(jiǎn)化容器化微服務(wù)創(chuàng)建、集成、部署、運(yùn)維的整個(gè)流程，從而推動(dòng)微服務(wù)在云端的大規(guī)模實(shí)踐。以下將以靈雀云為例，來(lái)說(shuō)明各個(gè)流程的實(shí)踐：
創(chuàng)建
靈雀云的鏡像構(gòu)建和持續(xù)集成服務(wù)幫助用戶將獨(dú)立、可復(fù)用的微服務(wù)打包，轉(zhuǎn)化為隨時(shí)可以部署的容器鏡像。假設(shè)用戶的微服務(wù)程序，存儲(chǔ)于GitHub 等代碼托管服務(wù)中，用戶可以將這個(gè)代碼倉(cāng)庫(kù)構(gòu)建成容器鏡像，并保存在靈雀云的鏡像倉(cāng)庫(kù)中，用戶可以將這個(gè)微服務(wù)一鍵部署到我們的容器云平臺(tái)。同時(shí)，靈雀云提供了持續(xù)集成的功能，用戶可以選擇是否性使用。每當(dāng)微服務(wù)的代碼有變化時(shí)，就構(gòu)建一個(gè)新的容器鏡像，以便以后部署使用。
集成
靈雀云不僅在平臺(tái)的鏡像倉(cāng)庫(kù)中匯集了大量來(lái)自Docker官方和社區(qū)的優(yōu)質(zhì)鏡像，也支持平臺(tái)以外的任意鏡像源。用戶可以自由組合、復(fù)用數(shù)以萬(wàn)計(jì)的容器化微服務(wù)，像搭積木一樣輕松集成應(yīng)用。比如，用戶需要一個(gè)通用的MySQL數(shù)據(jù)庫(kù)服務(wù)，他無(wú)需構(gòu)建鏡像，可以直接在鏡像社區(qū)中選擇適合的數(shù)據(jù)庫(kù)服務(wù)鏡像，并與其微服務(wù)鏈接起來(lái)。
部署
微服務(wù)由于組件數(shù)量眾多，云端部署成為實(shí)踐上的一個(gè)難點(diǎn)。靈雀云以容器為應(yīng)用發(fā)布的載體，用戶不必指定傳統(tǒng)部署方式中繁瑣的步驟，只需提供容器鏡像和簡(jiǎn)單的容器配置，平臺(tái)會(huì)將整個(gè)部署流程自動(dòng)化。
靈雀云還與docker-compose兼容，實(shí)現(xiàn)對(duì)于由多個(gè)微服務(wù)容器組成的完整應(yīng)用的一鍵部署。
#p#
運(yùn)維
微服務(wù)由于獨(dú)立進(jìn)程眾多，部署后的運(yùn)維、管理成為實(shí)踐上的另一個(gè)難點(diǎn)。靈雀云完全屏蔽底層云主機(jī)和基礎(chǔ)架構(gòu)運(yùn)維，讓用戶專注于應(yīng)用。同時(shí)，靈雀云通過(guò)容器編排、自動(dòng)修復(fù)、自動(dòng)擴(kuò)展、監(jiān)控日志等高級(jí)應(yīng)用生命周期服務(wù)，實(shí)現(xiàn)容器化微服務(wù)的智能托管，進(jìn)一步幫助用戶降低運(yùn)維成本和難度。
網(wǎng)絡(luò)
微服務(wù)架構(gòu)下各組件之間的溝通、協(xié)調(diào)對(duì)網(wǎng)絡(luò)有較高要求，尤其在云端實(shí)踐中，各個(gè)微服務(wù)組件的物理位置是動(dòng)態(tài)的，且不受應(yīng)用控制。靈雀云提供完整的容器網(wǎng)絡(luò)解決方案，支持負(fù)載均衡、服務(wù)發(fā)現(xiàn)、跨主機(jī)關(guān)聯(lián)，以及應(yīng)用安全內(nèi)網(wǎng)來(lái)確保微服務(wù)對(duì)內(nèi)、對(duì)外網(wǎng)絡(luò)的可用性及安全性。
1.首先，要實(shí)現(xiàn)服務(wù)的高可用性，負(fù)載均衡器是必不可少的，靈雀云支持基于傳輸層和應(yīng)用層的負(fù)載均衡，以滿足用戶不同需求。
2.負(fù)載均衡也可以實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，云端部署服務(wù)時(shí)，各個(gè)組件部署的物理位置是有可能發(fā)生變化的。在靈雀云，當(dāng)用戶創(chuàng)建一個(gè)微服務(wù)的時(shí)候，不論這個(gè)服務(wù)是停止?fàn)顟B(tài)還是運(yùn)行狀態(tài)，我們都會(huì)為服務(wù)創(chuàng)建負(fù)載均衡器和一個(gè)域名，這樣其他服務(wù)就可以通過(guò)這個(gè)域名訪問(wèn)該服務(wù)。即使服務(wù)中的容器實(shí)例被遷移，系統(tǒng)也會(huì)在它重新啟動(dòng)后，將它掛載回原來(lái)的負(fù)載均衡器。
3.跨主機(jī)關(guān)聯(lián)，是指微服務(wù)的容器實(shí)例會(huì)被部署在不同的云主機(jī)上，但會(huì)被關(guān)聯(lián)到該服務(wù)的負(fù)載均衡器上，以服務(wù)來(lái)自內(nèi)網(wǎng)或外網(wǎng)的請(qǐng)求。
4.內(nèi)部服務(wù)地址，對(duì)于很多微服務(wù)應(yīng)用來(lái)說(shuō)，這是個(gè)很重要的功能，比如在一個(gè)應(yīng)用中，一個(gè)微服務(wù)需要訪問(wèn)一個(gè)cache服務(wù)器(比如memcached)，但是出于安全的考慮，不希望外部請(qǐng)求訪問(wèn)到這個(gè)cache服務(wù)器，就可以使用靈雀云的內(nèi)部服務(wù)地址。系統(tǒng)同樣會(huì)創(chuàng)建負(fù)載均衡，以及域名，但是這個(gè)域名只供該用戶的其他服務(wù)訪問(wèn)，外部應(yīng)用，或其他用戶服務(wù)是無(wú)法訪問(wèn)的。
5.專屬IP是靈雀云最近新增的一個(gè)功能，有些用戶由于特殊需求，不希望和其他用戶共享IP，就可以申請(qǐng)一個(gè)專屬IP，并綁定在自己的應(yīng)用上，以獲得更好的隔離性。
存儲(chǔ)
微服務(wù)提倡多元化持久性(Polyglot Persistence)，應(yīng)用內(nèi)的每個(gè)微服務(wù)可根據(jù)實(shí)際需求選擇最合適的數(shù)據(jù)服務(wù)。微服務(wù)一般分兩類，無(wú)狀態(tài)服務(wù)和有狀態(tài)服務(wù)，無(wú)狀態(tài)服務(wù)比如應(yīng)用服務(wù)器，他們通常是不保存數(shù)據(jù)的，方便橫向的擴(kuò)展。有狀態(tài)服務(wù)需要存儲(chǔ)數(shù)據(jù)，比如數(shù)據(jù)庫(kù)服務(wù)，緩存服務(wù)。
Docker的特性，決定了容器本身的數(shù)據(jù)并不是持久化的，需要通過(guò)掛載Volume來(lái)實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)。靈雀云將持久性云存儲(chǔ)抽象成數(shù)據(jù)卷，可以直接掛載在容器上，并在容器重啟、遷移中自動(dòng)重新掛載?？芍С秩我馊萜骰瘮?shù)據(jù)服務(wù)，供微服務(wù)應(yīng)用集成。同時(shí)，支持對(duì)微服務(wù)數(shù)據(jù)的備份，恢復(fù)，和下載，可以利用備份隨時(shí)恢復(fù)數(shù)據(jù)。
微服務(wù)架構(gòu)的誕生和容器技術(shù)的流行，幾乎是同時(shí)發(fā)生的，這并不是偶然。這是互聯(lián)網(wǎng)時(shí)代倒逼傳統(tǒng)技術(shù)和架構(gòu)而產(chǎn)生的變革，最前線的開(kāi)發(fā)者和他們所在的互聯(lián)網(wǎng)企業(yè)最先感受到了這場(chǎng)變革。靈雀云希望與開(kāi)發(fā)者一起共同引領(lǐng)這場(chǎng)變革，幫助互聯(lián)網(wǎng)企業(yè)真正專注于自身的核心業(yè)務(wù)，并在技術(shù)和架構(gòu)上保持領(lǐng)先。
作者簡(jiǎn)介：
陳愷，2015年正式加盟靈雀云，任首席技術(shù)官。攜其十?dāng)?shù)年大規(guī)模、企業(yè)級(jí)分布式系統(tǒng)/云平臺(tái)研發(fā)經(jīng)驗(yàn)，打造基于容器技術(shù)、面向開(kāi)發(fā)者的云計(jì)算平臺(tái)。加入云雀科技之前，2004年在微軟從事Windows操作系統(tǒng)內(nèi)核(Kernel)的研發(fā)，2010年出任微軟云平臺(tái)Windows Azure首席架構(gòu)師/軟件開(kāi)發(fā)部經(jīng)理，專注于云計(jì)算/分布式系統(tǒng)的研發(fā)，組建、帶領(lǐng)團(tuán)隊(duì)開(kāi)發(fā)Azure最核心的中控系統(tǒng)(Fabric Controller)，管理并支撐整個(gè)云平臺(tái)后端，承載千萬(wàn)級(jí)規(guī)模應(yīng)用。
