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