基于容器和微服務加速迭代速度實踐

本文來自網易蜂巢解決方案首席架構師劉超在2016年12月10日，SFDC大會上的演講，主要講述了網易蜂巢根據具體的業務場景和架構，進行逐步微服務化，容器化的實踐。

坊間一直有“網易出品，必屬精品”的言論流傳，網易云音樂、考拉海購、有道云筆記、網易云課堂等都是深受大家喜愛的應用，而這些應用的背后，都少不了網易蜂巢的支撐。目前網易95%以上的應用都已經部署在了網易蜂巢上，基于蜂巢，考拉扛過了6·18、雙11，每天更新達700余次，網易云音樂用戶也已經達到2億，成為最受歡迎的音樂播放器之一。

網易蜂巢是網易云推出的云計算基礎服務，用丁爸爸的話就是為“解放全中國的程序員”而生的。網易蜂巢的發展也經歷了從基于虛擬機的私有云平臺，向基于容器的公有云平臺的轉變歷程。平臺層從虛擬機向容器的轉變，另整個迭代過程和環境的管理帶來了極大的便捷性，而容器的使用也讓應用層不得不進行調整，架構上要向微服務遷移，流程上則要DevOps轉變。

上圖是網易蜂巢整個平臺的架構，從下向上依次是硬件層、IaaS層和PaaS層。

硬件上，網易云全部都是五星級的機房，多線BGP網絡接入，萬兆網絡互聯，全SSD存儲。

其次是網易云是基于OpenStack的自研IaaS：

計算：定制KVM系統鏡像，實現云主機IP靜態化，優化OpenStack創建云主機流程；

網絡：二層至四層網絡過濾防止MAC/IP欺騙，基于Linux TC修改OVS實現網絡QoS；

存儲：云硬盤架構基于iscsi和Ceph實現，優化Ceph核心模塊OSD；

最上層是高可用，高性能的PaaS，蜂巢在這個方面的積累非常深厚：

數據庫：網易定制的MySQL內核分支，主從切換數據零丟失，提供健康檢查和SQL優化工具；

緩存服務：主從熱備、跨可用域部署，自動容災，高性能單筆延時毫秒級；

對象存儲：高可用性為99.99%，高可靠性三備份8個9，基于自研分布式非結構化存儲系統。

對于開發者來說，之前基于虛擬機的部署，操作上是比較簡單的。只要調用IaaS層的API，把虛擬機創建出來；數據庫、對象存儲等中間件放到PaaS平臺就可以了。如果應用比較少，直接手工部署就可以了，但是如果應用量比較大，或者分的服務比較多，就需要用到一些自動化部署的工具，比如Puppet、Chef和Ansible。之所以要用到這些工具是因為,僅僅資源層面的彈性，并不能滿足互聯網快速迭代的需求。比如電商大促期間，原來10臺機器，要擴展到20臺，另外的10靠虛擬機還是要手工一臺臺去部署，整個擴展的速度還是達不到要求，就要靠腳本做一些事情。

上圖就是一個電商系統的雛形，對于一個互聯網+的應用，為了系統快速上線，進行觀念的驗證，多數都會采取集約化的單體架構，主要包括用戶管理、商戶管理、訂單管理、商品管理、支付管理這么幾塊。這樣做的好處是易開發、易測試、易部署、易運維。

但是隨著業務的飛速發展，整個應用的架構會變得很復雜，網絡流量、用戶請求、日活都會大幅度增長，功能也會越來越完善，比如用戶的個性化推薦、積分系統，商戶的供應商管理、物流管理，這時單體架構的好處幾乎都會消失，服務器的重復部署和數據庫的查詢都會成為瓶頸，整個系統的迭代速度也會慢下來，一個功能的修改可能要牽扯到很多模塊。

為了解決這個問題，就要進行應用架構的改造，比如加上負載均衡器和緩存服務器，數據庫進行讀寫分離，使用中間件把大服務拆成小服務，服務之間通過消息組件進行交互，這樣應用首先可以水平擴容了，比如下訂單特別的忙，3個節點不夠就可以擴成9個節點，結合腳本還能實現彈性的伸縮。

這樣的改造后也會出現新的隱憂，比如隨著系統模塊的增多，每個模塊又有自己的開發環境、測試環境和生產環境，應用的管理成本會變得很高；另外，虛擬機的部署效率是很差的，因為每創建一個虛機都是有內核的；產品發布慢，業務上線慢；依賴組件搭建麻煩（服務發現、分流）；監控，日志管理復雜。

容器的誕生恰好彌補了虛擬機的這些不足：

l首先，容器非常輕量級，如果你要跑一個2G的程序，創建一個2G內存就夠了，因為內核是共享的；

l另外的好處是易遷移和環境的一致性，容器的鏡像將所有的應用、環境、配置、依賴都打包在內了，鏡像無論在哪里啟動都能保持一致，而且整個鏡像非常小。

l最后，鏡像是有版本的，這個版本和環境的一致性結合起來，就可以保證我們能很放心地進行版本的回滾，進行版本控制。

當然容器在追求這些優勢的同時，也犧牲了一些特性，比如內核共享使得容器間的隔離不足，在公有云中會存在安全隱患；應用的遷移也是應用邏輯的遷移，數據是遷移不了的，這就要求應用是無狀態的；此外，容器的網絡、存儲、日志和配置功能都不夠完善，需要做很多優化。

網易蜂巢在采用容器作為部署單元的同時，進行了很多優化工作，去解決這些問題：

蜂巢在編排方面的優化：

l支持多租戶:默認kubernates的namespace只隔離replication controller，pod等資源，網易實現節點，存儲、網絡的租戶隔離；

l調度性能優化：kubernetes調度優化，任務串行隊列改為多個優先級隊列；

l集群擴展性：根據Pod/Node/Replication Controller等資源到拆分不同的etcd集群

蜂巢在容器方面的優化：

l虛擬化扁平二層網絡，基于VXLAN實現租戶隔離，外網網卡直接掛載到容器內部；

l有狀態容器掛載云盤，可實現跨主機遷移；

l提供統一的日志收集，分析，搜索服務，利于分布式架構問題定位；

l引入服務端APM解決細粒度性能分析，迅速發掘性能瓶頸

總之，蜂巢就是用IaaS層和容器層緊密結合的方式來解決了以上提到的各種問題，比如：

l使用虛擬機解決內核隔離問題

l使用IaaS層能力解決網絡和存儲問題

l使用Kubernetes解決編排和配置問題

l使用統一日志和監控解決容器日志監控問題

l有狀態容器暫時解決狀態保持問題

其中有狀態的容器只是暫時的方案，還是建議進行應用的無狀態化改造，主要就是把內存中的數據保存到緩存中，把用戶數據保存到數據庫中，把文件保存到分布式存儲中，這樣應用中只包含商務邏輯，無論怎么擴展都只是商務邏輯的擴展，下面的存儲也都有自己的集群，不需要應用層做過多的考慮。

Kubernetes的編排方式，會讓應用拆成微服務后，能以一種非常優雅的方式進行部署、編排、自發現、自修復和實現CI/CD，比如一個應用拆成了A、B、C、D四個服務，如果中間那臺機器掛了，Kubernetes會把B服務和C服務移到另外2臺沒有掛的機器上。

容器還有一個特性就是啟動后IP地址會變，而Kubernetes的服務間引用是通過服務名實現的，這就讓容器的自修復成為了可能。另外Kubernetes的機制還讓容器的動態擴展變得非常容易。

另外，Kubernetes還能讓整個開發的流程變得很優雅，一方面容器的鏡像可以使業務的代碼、系統庫、權限完全一致，所有的配置通過容器的編排也會保持一致，這樣從Dev到Ops的各種環境維護的都是一套東西，開發人員一旦提交了代碼，代碼可以通過hook的方式觸發到容器平臺，容器平臺會自動把當前的代碼打包成鏡像，一分鐘之內測試環境就會更新，就可以進行自動化測試，測試完成后Ops就可以一鍵部署到生產環境，形成一套非常順暢的DevOps流程。

上面就是經過蜂巢微服務化后的一個比較理想的電商系統的簡版架構。

整個網易蜂巢的特色在于聚焦應用，解放開發者。對于互聯網+公司和創業公司來說，無論是IaaS平臺還是PaaS平臺，無論是數據庫、分布式存儲還是緩存，想要做好調優還是非常花時間和精力的，就算是用Kubernetes，想要用好，做好二層網絡的打通，和統一的存儲，也是很有難度的。我們希望蜂巢的用戶都能聚焦于自己的業務和產品，把基礎設施的部分交給云平臺來做。

另外，蜂巢是一個全開源的平臺，包括MySQL、Redis、Kubernetes和OpenStack都是當下最流行的開源技術，以便讓平臺的應用接口和行為習慣符合大多數開發者的習慣。蜂巢會作為一個知識輸出的平臺，服務于企業的微服務化改造。

提問環節

提問： 您剛才提到容器的隔離度不夠，所以蜂巢是在IaaS層的虛擬機上再做容器的，請問是如何對性能、開銷和啟動時間進行調優的呢？

劉超： 這個調優首先要找到慢的原因，比如容器啟動比較慢，我們發現IaaS層OpenStack的很多操作對于容器平臺并不是必要的，我們就把KVM弄得很簡單，把IP做成靜態化的配置，使得整個啟動過程從分鐘級降到了秒級，在啟動第一個容器的時候會多幾秒的時間，后續的容器如果虛擬機的資源足夠完全沒有損耗了。

 

來自：http://www.jianshu.com/p/5199edb079f0