注：
本文根據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，管理你的項目，也可以完成協作等等。
通過靈活擴充、可配置的方式實作微服務應用商店模型
圖中可能有大家熟悉的軟體。在這樣的平台上，我們是不是能夠很容易獲得這樣的微服務子產品？比如，需要形成大資料處理的能力時，它是不是唾手可得，不需要自己去開發？我們是不是可以形成基于微服務子產品交易的市場？
大資料進行中有一個很大的難點，資料專家和業務專家中間有一個很大的鴻溝，比如說醫療資料如何模組化、如何寫邏輯等等，這方面我們是不是可以通過一種插件的模式，把醫療專家的經驗通過資料處理子產品進行封裝，并通過一定形式進行分享。我想這些都是潛在的發展模式。也許未來，我們會看到蓬勃發展的微服務子產品的交易市場。以上是我今天分享的内容，謝謝大家！
溫馨提示
對Docker容器技術或容器生産實施感興趣的朋友歡迎加群454565480讨論。我們彙集了Docker容器技術落地實施團隊精英及業内技術派高人，線上為您分享Docker技術幹貨。我們的宗旨是為了大家擁有更專業的平台交流Docker實戰技術，我們将定期邀請嘉賓做各類話題分享及回顧，共同實踐研究Docker容器生态圈。