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

網易蜂巢是網易雲推出的雲端計算基礎服務，用丁爸爸的話就是為“解放全中國的程式設計師”而生的。網易蜂巢的發展也經歷了從基於虛擬機器的私有云平臺，向基於容器的公有云平臺的轉變歷程。平臺層從虛擬機器向容器的轉變，給整個迭代過程和環境的管理帶來了極大的便捷性，而容器的使用也讓應用層不得不進行調整，架構上要向微服務遷移，流程上則要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的編排方式，能讓應用拆成微服務後，以一種非常優雅的方式進行部署、編排、自發現、自修復和實現CI/CD。比如一個應用拆成了A、B、C、D四個服務，如果中間那臺機器掛了，Kubernetes會把B服務和C服務移到另外2臺沒有掛的機器上。

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

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