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