基於容器雲的微服務架構實踐

近年來，微服務架構及容器技術備受關注，在各類文章、演講、部落格中頻頻亮相，成為業界最熱門的話題。在時尚的詞彙和熱情滿滿的討論背後，人們開始嚴肅的重新思考網際網路時代服務的架構以及應用開發、運維的方法。微服務以一種全新的架構設計模式，牽動了網際網路應用從設計到運維整個流程方法論的變革。‌‌而以Docker為代表的容器技術則為微服務理念提供了匹配的實現機制，進而實質性的改變了新一代應用開發和釋出的方式。 

什麼是微服務架構？

微服務架構（Microservices Architecture）是一種架構風格（Architectural Style）和設計模式，提倡將應用分割成一系列細小的服務，每個服務專注於單一業務功能，執行於獨立的程式中，服務之間邊界清晰，採用輕量級通訊機制（如HTTP/REST）相互溝通、配合來實現完整的應用，滿足業務和使用者的需求。

微服務作為架構模式的變革，其誕生絕非偶然。它是當傳統服務架構在網際網路時代遭遇挑戰時，人們對於架構模式，開發和運維方法論的一種反思。所以，在深入探討微服務架構之前，我們先回顧一下更為普遍的傳統服務架構。

傳統“單塊架構”：

在過去的10多年中，甚至是微服務日趨流行的當下，絕大多數應用採用的仍是我們更為熟悉的傳統架構，稱之為“單塊架構（Monolithic Architecture）”模式。此類架構系統通常以技術分層，例如最常見的“分層架構”中的表現層、業務邏輯層、資料層。而業務邏輯則可根據更具體的業務職責、功能進行模組化，形成邏輯元件。這裡需要提一下的是，“分層架構”雖然有邏輯上的模組和元件，但在物理部署架構層面仍是一個“單塊”，通常作為一個整體編譯、打包、部署、運維。“單塊架構”便是從物理部署角度，對於包括“分層架構”在內的應用架構模式的一種定義。

“分層架構”是軟體架構體系中的經典模式，也是長時間來應用架構實際上的標準。而單塊架構也有其一定優勢，體現為：

• 便於開發：大量常用的整合開發環境（IDE）和程式設計框架（如Rails，Django）都是圍繞傳統架構下單塊應用設計的。這些工具為開發者提供了方便和熟悉的開發、除錯體驗。
• 便於測試：由於整個應用包含在一個程式中，在常用工具的配合下應用可以很容易在開發、測試環境中啟動。然後採用UI自動化工具（如Selenium）便可簡單實現End-to-End測試。
• 便於部署：多數程式語言和框架都有特定的應用打包格式。部署只需將單一軟體包複製到執行環境。而這一過程也可透過現有工具實現自動化。

由於這些優點，在專案初期，單塊架構有一定的吸引力。開發者可以透過工具、框架快速生成應用原型，而不必花大量精力在服務分解和分散式架構設計上。但隨著業務的擴張和功能的累積，原本簡單的應用體積會迅速變大，此時單塊架構很難適應快速變更的需求，由於架構層面的侷限性，這類應用會面臨多重挑戰。

• 開發效率低：隨著應用複雜度的增加，越來越少開發人員對應用能有全域性性的深度理解。新功能開發和缺陷修復難度呈幾何性增加。程式碼修改的正確性無法保障。而龐大的程式碼庫需要更龐大的開發團隊來維護，無形中又增添了管理、溝通和協調的成本。另外，新加入的團隊成員需要花費大量的時間和精力來熟悉一個複雜的程式碼庫。
• 交付週期長：在單一程式的單塊架構下，任何微小的改動都需要重新編譯、整合、測試和部署整個應用。隨著應用體積的增大，交付流程和反饋週期都會相應變長，應用釋出的代價也隨之增加。於是應用交付週期變緩，交付間隙積累的程式碼變動增加，從而對於下次交付產生更大的壓力，形成惡性迴圈。
• 技術轉型難：單一程式、單塊架構意味著中心化的技術選型。比如，應用的不同邏輯組建通常需要採用相對統一的程式語言、框架和技術棧。這些在專案初始階段便已定型。之後，即便是應用中全新的邏輯元件，也很難採用不同的技術棧。而當應用達到一定規模後，全域性化的技術棧更新會面臨很高的風險。所以，單塊架構應用一旦定型，就很難再享受行業技術變更、發展所帶來的紅利。

由於這些結構性、系統性問題的存在，單塊架構下的應用越來越難適應網際網路時代快速變更的市場需求。微服務便是從架構層面出發，推動傳統應用開發、運維方式的變革，從而幫助企業快速響應市場需求、快速迭代、快速交付，在網際網路時代保持競爭力。

微服務架構的優勢：

在微服務架構下，我們將原本單一的應用按照功能邊界分解成一系列獨立、專注的微服務。每個微服務對應傳統應用中的一個元件，但是可以獨立編譯、部署和擴充套件。相對單塊架構，微服務具備以下優勢。

• 複雜度可控：在將應用分解的同時，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並透過定義良好的介面清晰表述服務邊界。由於體積小、複雜度低，每個微服務可由一個小規模開發團隊完全掌控，易於保持高可維護性和開發效率。
• 獨立部署：由於微服務具備獨立的執行程式，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當於具備一系列可並行的釋出流程，使得釋出更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付週期。
• 技術選型靈活：微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由於每個微服務相對簡單，當需要對技術棧進行升級時所面臨的風險較低，甚至完全重構一個微服務也是可行的。
• 容錯：當某一組建發生故障時，在單一程式的傳統架構下，故障很有可能在程式內擴散，形成應用全域性性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可透過重試、平穩退化等機制實現應用層面的容錯。
• 擴充套件：單塊架構應用也可以實現橫向擴充套件，就是將整個應用完整的複製到不同的節點。當應用的不同元件在擴充套件需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴充套件。

微服務架構的雲端實踐：

雖然微服務架構帶來了諸多優勢，但必須承認，構建，部署，維護分散式的微服務系統並不容易。而容器所提供的輕量級、面向應用的虛擬化執行環境為微服務提供了理想的載體。同樣，基於容器技術的雲服務將極大的簡化容器化微服務建立、整合、部署、運維的整個流程，從而推動微服務在雲端的大規模實踐。以下將以靈雀云為例，來說明各個流程的實踐：

建立

 

靈雀雲的映象構建和持續整合服務幫助使用者將獨立、可複用的微服務打包，轉化為隨時可以部署的容器映象。假設使用者的微服務程式，儲存於GitHub等程式碼託管服務中，使用者可以將這個程式碼倉庫構建成容器映象，並儲存在靈雀雲的映象倉庫中，使用者可以將這個微服務一鍵部署到我們的容器雲平臺。同時，靈雀雲提供了持續整合的功能，使用者可以選擇是否性使用。每當微服務的程式碼有變化時，就構建一個新的容器映象，以便以後部署使用。

整合

靈雀雲不僅在平臺的映象倉庫中彙集了大量來自Docker官方和社群的優質映象，也支援平臺以外的任意映象源。使用者可以自由組合、複用數以萬計的容器化微服務，像搭積木一樣輕鬆整合應用。比如，使用者需要一個通用的MySQL資料庫服務，他無需構建映象，可以直接在映象社群中選擇適合的資料庫服務映象，並與其微服務連結起來。

部署

 

微服務由於元件數量眾多，雲端部署成為實踐上的一個難點。靈雀雲以容器為應用釋出的載體，使用者不必指定傳統部署方式中繁瑣的步驟，只需提供容器映象和簡單的容器配置，平臺會將整個部署流程自動化。

 

靈雀雲還與docker-compose相容，實現對於由多個微服務容器組成的完整應用的一鍵部署。

運維

微服務由於獨立程式眾多，部署後的運維、管理成為實踐上的另一個難點。靈雀雲完全遮蔽底層雲主機和基礎架構運維，讓使用者專注於應用。同時，靈雀雲透過容器編排、自動修復、自動擴充套件、監控日誌等高階應用生命週期服務，實現容器化微服務的智慧託管，進一步幫助使用者降低運維成本和難度。

網路

微服務架構下各元件之間的溝通、協調對網路有較高要求，尤其在雲端實踐中，各個微服務元件的物理位置是動態的，且不受應用控制。靈雀雲提供完整的容器網路解決方案，支援負載均衡、服務發現、跨主機關聯，以及應用安全內網來確保微服務對內、對外網路的可用性及安全性。

• 首先，要實現服務的高可用性，負載均衡器是必不可少的，靈雀雲支援基於傳輸層和應用層的負載均衡，以滿足使用者不同需求。
• 負載均衡也可以實現服務發現，雲端部署服務時，各個元件部署的物理位置是有可能發生變化的。在靈雀雲，當使用者建立一個微服務的時候，不論這個服務是停止狀態還是執行狀態，我們都會為服務建立負載均衡器和一個域名，這樣其他服務就可以透過這個域名訪問該服務。即使服務中的容器例項被遷移，系統也會在它重新啟動後，將它掛載回原來的負載均衡器。
• 跨主機關聯，是指微服務的容器例項會被部署在不同的雲主機上，但會被關聯到該服務的負載均衡器上，以服務來自內網或外網的請求。
• 內部服務地址，對於很多微服務應用來說，這是個很重要的功能，比如在一個應用中，一個微服務需要訪問一個cache伺服器（比如memcached），但是出於安全的考慮，不希望外部請求訪問到這個cache伺服器，就可以使用靈雀雲的內部服務地址。系統同樣會建立負載均衡，以及域名，但是這個域名只供該使用者的其他服務訪問，外部應用，或其他使用者服務是無法訪問的。
• 專屬IP是靈雀雲最近新增的一個功能，有些使用者由於特殊需求，不希望和其他使用者共享IP，就可以申請一個專屬IP，並繫結在自己的應用上，以獲得更好的隔離性。 

儲存

微服務提倡多元化永續性（Polyglot Persistence），應用內的每個微服務可根據實際需求選擇最合適的資料服務。微服務一般分兩類，無狀態服務和有狀態服務，無狀態服務比如應用伺服器，他們通常是不儲存資料的，方便橫向的擴充套件。有狀態服務需要儲存資料，比如資料庫服務，快取服務。

Docker的特性，決定了容器本身的資料並不是持久化的，需要透過掛載Volume來實現資料的儲存。靈雀雲將永續性雲端儲存抽象成資料卷，可以直接掛載在容器上，並在容器重啟、遷移中自動重新掛載。可支援任意容器化資料服務，供微服務應用整合。同時，支援對微服務資料的備份，恢復，和下載，可以利用備份隨時恢復資料。

最後

微服務架構的誕生和容器技術的流行，幾乎是同時發生的，這並不是偶然。這是網際網路時代倒逼傳統技術和架構而產生的變革，最前線的開發者和他們所在的網際網路企業最先感受到了這場變革。靈雀雲希望與開發者一起共同引領這場變革，幫助網際網路企業真正專注於自身的核心業務，並在技術和架構上保持領先。