有容雲：微服務容器化的挑戰和解決之道

注： 本文根據6月是18日七牛雲微服務課堂-微服務容器化的挑戰和解決之道演講內容整理而成，演講者：有容雲聯合創始人兼首席架構師馬洪喜，與大家一起探討了如何通過容器技術將微服務和 DevOps 落地。

嘉賓介紹： 馬洪喜，此前擔任 Rancher Labs 中國區技術負責人、Citrix 公司資深架構師、Oracle 公司虛擬化產品開發經理等職務，在容器雲、IaaS 雲、桌面雲建設方面擁有豐富的經驗。

單體架構 VS 微服務架構

傳統單體架構存在各種各樣的問題，如載入編譯耗時長、程式碼管理複雜、橫向擴充套件難、各模組之間的耦合程度高等，與之相比，微服務架構則具一系列優勢。

微服務架構則優勢：

1. 模組可以獨立提供服務，邊界清晰、易於維護，可以促成新的開發模式，使模組外包，未來微服務模組市場的出現成為可能。

2. 微服務可以用不同語言編寫，易於引入新技術。

3. 未來可能會形成微服務應用商店模型，快速的組合和重構。

4. 模組間鬆耦合，不同 SLA 保障計劃。

5. 更好的可擴充套件性和魯棒性。

下面我們看一個微服務的架構示例 ：有容雲AppHouse。

上圖是 AppHouse 採用的架構設計。按照服務職能的切割，每一個微服務都跑在一個或者一組容器中，迎合了微服務主流的設計思路。

微服務和容器發展不可分割，以前存在各種各樣切割服務的難點，而容器技術的出現使得服務可以切割得更小，成為支撐微服務很好的平臺。下面讓我們看看在非容器化的傳統的 IT 基礎設施之上，如果嘗試使用微服務會存在哪些挑戰。

容器可以輕鬆實現微服務化後的 DevOps

Netflix 雲架構總監說微服務和 Docker 的結合是一種顛覆。Docker可以為微服務提供一個完美的執行環境。

1. 獨立性。一個容器就是一個完整的執行環境，不依賴外部任何的東西。

2. 細粒度。一臺物理機器可以同時執行成百上千個容器，其計算粒度足夠的小。

3. 快速建立和銷燬。容器可以在秒級進行建立和銷燬，非常適合服務的快速構建和重組。

4. 完善的管理工具。數量眾多的容器編排管理工具，能夠快速的實現服務的組合和排程。

微服務化與容器化，誰先誰後?

目前，許多傳統企業都非常關注微服務。但是，我們需要意識到，利用容器技術將傳統系統進行微服務改造不可能一步到位，並且也不是一定要把你的應用改造成微服務。

微服務改造本身是一個漫長的過程，如果你是 SOA 的應用，甚至是更傳統的，那麼可以考慮先將應用轉到容器平臺上執行，然後我們可以先體驗容器帶來的感受，再考慮如何將應用往微服務方向改造。

支援微服務的容器管理平臺需要解決的問題

在容器上跑微服務是所有人的共識，問題在於如何支撐微服務。從管理微服務的角度看，未來微服務需要實現跨主機、跨雲、跨資料中心。當系統被微服務打散後，一些功能需要放到阿里雲，一些功能需要放到企業中心，如何在服務平臺上實現跨雲的管理，這是帶給容器管理平臺的挑戰。另外，一部分微服務跑在阿里雲，一部分微服務跑在本地，如何保證它的安全性，並且按照預想的安全策略去做也是一個挑戰。

大家知道，微服務通過一組功能相同的微服務例項，對外提供統一的服務。當微服務例項擴容時，如何讓它們自動的提供服務，不需要手動調整負載均衡配置，這也是容器管理平臺需要考慮的問題。此外，容器管理平臺還要實現服務的註冊和服務的發現、微服務版本的管理和微服務的升級與降級等，這個過程需要考慮到灰度釋出策略和已有會話的處理等工作。當然，這隻 是一部分例子，除此之外還會涉及到生命週期管理、團隊協作和應用配置管理等各個方面的功能點。

面向微服務的容器網路和儲存實現架構討論

接下來和大家分享一下使用容器進行微服務支撐的另外兩個技術挑戰點：

第一個挑戰是微服務模式下如何使用容器網路。

大家關注容器技術，知道容器的網路發展速度很快，比如 CNI、CNM 等各類網路模型出現。在談容器網路的時候，大家很容易會陷入一個誤區，即過度追求技術的時尚性，例如 Overlay , SDN 等等，這些技術與容器配合當然是未來的方向，但今天考慮把容器技術真正落地，隧道網路不一定適合每個企業。很多企業既希望容器像虛擬機器一樣直接使用業務 IP ，又不希望 IP 資源過渡消耗。因此產品設計要關注使用者的實際使用需求。

第二個挑戰是微服務模式下的容器儲存方案。

一個大的系統，不同的微服務模組，對包括儲存、計算、網路都有不同的 SLA 要求，譬如做資料處理的模組與做圖片歸檔的模組對儲存要求是不一樣的。是不是有一天我們定義應用對接儲存的規格時，可以通過寫一行配置引數，不同的儲存指向和 SLA ，比如資料處理模組對接到跨多主機 SSD 盤陣的分散式儲存上，圖片歸檔可能是放在 SATA 盤陣或是公有云儲存，比如七牛雲上呢？這可能是未來支援微服務的平臺必須具備的功能之一。

剛才提到，微服務時代似乎確實需要極強的容器管理平臺，幫我們更好的管理微服務。而這樣一個平臺需要考慮到多方面功能點，以下是一些成熟的容器管理平臺要解決的問題。

微服務的橫向擴充套件

在產品設計上，我們在思考有沒有好的方式，能夠根據使用者量訪問情況做到對微服務模組的自動擴容( AutoScale )，這也是大家比較關心的問題。否則花了很大力氣改造微服務，做完後卻發現這個平臺不具備根據使用者的訪問自動擴充套件服務的能力，微服務的價值也大打折扣。

微服務容器化下的安全架構考慮

每個企業都會關心資訊保安。上了容器後，大家也會關心如何解決容器環境下的安全挑戰。

傳統的模式不太適用於新的容器時代或者微服務時代。大家想象一個場景，以前虛擬機器時代，數量是有限的，對於一個企業來說，虛擬機器有幾百臺，還是採用手動管理安全策略。現在容器數量可能一萬甚至十萬個，容器的建立和刪減完全由系統自動決定。傳統的人工策略已然不適用，因此需要新的能夠適應未來容器時代和微服務時代的安全模型。

有容雲的容器安全產品設計，是以應用為中心的角度考慮容器時代的安全挑戰。比如整個微服務拓撲的可見度，我們能不能把容器之間的通訊完全呈現出來，讓大家直觀看到哪些微服務模組之間存在資料通訊及其質量。當你的一個內部微服務模組突然之間開始將大量資料傳送到網際網路，你需要得到一個告警，並去處理，看看是不是被黑客攻擊了。還有諸如容器漏洞熱補丁以及映象掃描等功能，都是從容器安全形度考慮要去解決的問題。

微服務的日誌聚合設計

傳統時代，我們的日誌不大會直接列印到標準輸出，而一般會由團隊達成一致，存於某個指定目錄。

在微服務架構下，大家知道容器的玩法，對於日誌收集，推薦的做法是將容器內微服務產生的日誌列印到標準輸出，然後通過外部收集器統一收集、處理和分析。有容雲的產品可以把微服務模組日誌全部集中處理。有可能一些傳統元件沒有辦法把日誌輸出到標準輸出，還是放在目錄下的日誌檔案裡，這時我們需要一個手段將其儲存。當然有很多技術可以選擇，我們的產品採用的是“日誌處理夥伴容器”和“資料卷共享”技術，這種方式不是侵入式的，無需在微服務容器內注入其它元件。

私有映象服務在 DevOps 環境的選擇

在容器映象管理中，需要對映象許可權進行管理。舉個例子，映象可以被自動化的流水線自動生成，放入映象庫的“開發”庫(對應有容雲AppHouse中的一個Project)時，映象只是產生了，並未經過測試。如果運營人員一不小心把這樣的映象從映象庫拉下來，將對生產造成很大的影響。

對於我們來說，關注點在於如何將映象和 DevOps 開發流程進行匹配。比如映象進入開發庫，只有測試人員才有許可權進行測試。測試通過後，版本經理一定要做一個審批通過的動作，這樣容器映象才能在生產、運營中看到，才可以有許可權把它拉進來。這是映象設計倉庫方面的一些考慮，相信我們未來在市面上會看到功能越來越豐富的產品。

容器驅動的輕量級 PaaS 解決方案架構示例

如果用容器驅動微服務開發，是不是需要有一個 PaaS 平臺直接對整個開發專案的生命週期進行管理？其實 PaaS 是很多企業，包括前文提到的傳統金融行業，很關注的解決方案。新的 PaaS 時代，大家更關注的問題是容器驅動的 PaaS 如何去做。大家可以想象一下，未來市場上會看到這樣一些 PaaS 產品，你只要註冊一個賬號就能登入到這個 PaaS 平臺，在上面你可以定義整個專案的生命週期，可以管理你的 Bug，管理你的專案，也可以完成協作等等。

通過靈活擴充套件、可配置的方式實現微服務應用商店模型

圖中可能有大家熟悉的軟體。在這樣的平臺上，我們是不是能夠很容易獲得這樣的微服務模組？比如，需要形成大資料處理的能力時，它是不是唾手可得，不需要自己去開發？我們是不是可以形成基於微服務模組交易的市場？

大資料處理中有一個很大的難點，資料專家和業務專家中間有一個很大的鴻溝，比如說醫療資料如何建模、如何寫邏輯等等，這方面我們是不是可以通過一種外掛的模式，把醫療專家的經驗通過資料處理模組進行封裝，並通過一定形式進行分享。我想這些都是潛在的發展模式。也許未來，我們會看到蓬勃發展的微服務模組的交易市場。以上是我今天分享的內容，謝謝大家！

本文來源：http://www.youruncloud.com/blog/83.html

溫馨提示

對Docker容器技術或容器生產實施感興趣的朋友歡迎加群討論。我們彙集了Docker容器技術落地實施團隊精英及業內技術派高人，線上為您分享Docker技術乾貨。我們的宗旨是為了大家擁有更專業的平臺交流Docker實戰技術，我們將定期邀請嘉賓做各類話題分享及回顧，共同實踐研究Docker容器生態圈。 加微信群方法: 1.關注【有容雲】公眾號 2.留言”我要加群” QQ群號:454565480