網易蜂巢：基於容器和微服務迭代加速實踐

內容來源：2016年12月10日，由SegmentFault舉辦的SFDC大會在杭州舉辦，網易蜂巢解決方案首席架構師劉超在主會中發表了題爲「網易蜂巢基於容器和微服務加快迭代速度實踐」的演講， 主要講述了網易蜂巢根據具體的業務場景和架構，進行逐步微服務化，容器化的實踐。本文轉載自網易雲微信公衆號。

摘要

坊間一直有「網易出品，必屬精品」的言論流傳，網易雲音樂、考拉海購、有道雲筆記、網易雲課堂等都是深受你們喜好的應用，而這些應用的背後，都少不了網易蜂巢的支撐。目前網易95%以上的應用都已經部署在了網易蜂巢上，基於蜂巢，考拉扛過了6·1八、雙11，天天更新達700餘次，網易雲音樂用戶也已經達到2億，成爲最受歡迎的音樂播放器之一。

嘉賓演講地址：

t.cn/R98FXfS

從私有到公有，從虛擬機到容器

網易蜂巢是網易雲推出的雲計算基礎服務，用丁爸爸的話就是爲「解放全中國的程序員」而生的。網易蜂巢的發展也經歷了從基於虛擬機的私有云平臺，向基於容器的公有云平臺的轉變歷程。平臺層從虛擬機向容器的轉變，給整個迭代過程和環境的管理帶來了極大的便捷性，而容器的使用也讓應用層不得不進行調整，架構上要向微服務遷移，流程上則要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個節點，結合腳本還能實現彈性的伸縮。

這樣的改造後也會出現新的隱憂，好比隨着系統模塊的增多，每一個模塊又有本身的開發環境、測試環境和生產環境，應用的管理成本會變得很高；另外，虛擬機的部署效率是不好的，由於每建立一個虛機都是有內核的；產品發佈慢，業務上線慢；依賴組件搭建麻煩（服務發現、分流）；監控，日誌管理複雜。

容器+微服務相得益彰

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

• 首先，容器很是輕量級，若是你要跑一個2G的程序，建立一個2G內存就夠了，由於內核是共享的；

• 另外的好處是易遷移和環境的一致性，容器的鏡像將全部的應用、環境、配置、依賴都打包在內了，鏡像不管在哪裏啓動都能保持一致，並且整個鏡像很是小；

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

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

網易蜂巢的進一步優化

網易蜂巢在採用容器做爲部署單元的同時，進行了不少優化工做，去解決這些問題：

蜂巢在編排方面的優化：

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

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

• 集羣擴展性：根據Pod/Node/Replication Controller等資源到拆分不一樣的etcd集羣；

蜂巢在容器方面的優化：

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

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

• 提供統一的日誌收集，分析，搜索服務，利於分佈式架構問題定位；

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

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

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

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

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

• 使用統一日誌和監控解決容器日誌監控問題

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

其中有狀態的容器只是暫時的方案，仍是建議進行應用的無狀態化改造，主要就是把內存中的數據保存到緩存中，把用戶數據保存到數據庫中，把文件保存到分佈式存儲中。這樣應用中只包含商務邏輯，不管怎麼擴展都只是商務邏輯的擴展，下面的存儲也都有本身的集羣，不須要應用層作過多的考慮。

基於Kubernetes的編排

蜂巢容器層的編排是Kubernetes開源技術，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都是當下最流行的開源技術，以便讓平臺的應用接口和行爲習慣符合大多數開發者的習慣。蜂巢會做爲一個知識輸出的平臺，服務於企業的微服務化改造。

提問環節

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

劉超：這個調優首先要找到慢的緣由，好比容器啓動比較慢，咱們發現IaaS層OpenStack的不少操做對於容器平臺並非必要的，咱們就把KVM弄得很簡單，把IP作成靜態化的配置，使得整個啓動過程從分鐘級降到了秒級，在啓動第一個容器的時候會多幾秒的時間，後續的容器若是虛擬機的資源足夠就徹底沒有損耗了。

以上就是我今天的分享，謝謝你們！