在11月25日的GITC全球互聯網技術大會上，來自華為、網易、樂視、京東、騰訊、金山、小米、新浪、思科、聯想等公司的技術專家們共聚一堂，就當下流行的互聯網技術及行業趨勢進行了積極探討。
網易蜂巢首席架構師堯飄海受邀出席本次大會并發表演講，分享了支撐現代化的互聯網應用所需要的新一代云計算平臺的特點，以及網易如何基于OpenStack、Kubernetes和Docker等開源技術構建網易新一代云計算平臺網易蜂巢，并總結了整個架構過程優化的環節。
堯飄海從基礎服務、平臺服務、DevOps和微服務等方面解析了在設計網易蜂巢的過程中所做的思考和選擇。他表示，使用容器技術并不等于實現了DevOps和微服務，真正的DevOps和微服務的關鍵在于工具鏈和架構的支持，這正是網易蜂巢目前的重點工作。
容器不等于微服務
抓住轉瞬即逝的“風口”對于互聯網業務的發展尤為重要，而開始“飛起來”之后的關鍵，則是產品能夠跟上業務爆發的節奏，故而對于支持互聯網業務的新一代云計算平臺而言，保證產品快速迭代落地和永遠在線是其基本特性之一。事實上，網易蜂巢實施云計算的初衷，就是以提升產品開發效率作為平臺設計的導向，以改變互聯網的軟件生產方式為目的，從而滿足支持網易互聯網業務快速發展的需求。
面對互聯網業務的需求，開源技術Docker以容器、鏡像的特點，能保證開發運行環境一致，支持輕便、快速地迭代和擴容，問世不久就成為云計算領域的寵兒。當前的技術圈，沒有聽說過Docker 以及基于Docker實現DevOps、微服務的人可能不是很多，不過，對于Docker的精髓是什么，如何使用Docker，如何把業務Docker化，以及Docker與DevOps、微服務的關系，能夠真正理清頭緒的企業并不是很多。
堯飄海表示，認為微服務等于容器或者自助運維就是走入了誤區，例如，只是借助模板實現一套自動化的流程，把源代碼進行版本號的管理，并不能把環境和軟件整體打包成服務提供給用戶，所以還需要一整套的方法論和工具，才能解決微服務的交付問題。
工具鏈是新一代云計算平臺的重心
借用工業4.0的理念框架，堯飄海從現在化軟件生產的角度解析了新一代容器云的技術棧。工業4.0包括智能工廠、智能生產和智能物流，智能工廠的建設是一個從集中式到分布式轉變的過程，這與Docker容器的build-ship-run的模式相吻合。支持微服務和DevOps這兩個功能體系，云計算平臺依賴的技術實現，包括容器的技術、容器編排管理技術以及能夠支持容器和編排的基礎服務。
基于容器技術和編排服務是構建網易蜂巢容器云計算平臺的方案之一。根據實踐得到的經驗，新一代云計算平臺包括三個部分：提供穩定可靠的基礎服務(包括計算、存儲、網絡);融合從IaaS層到PaaS層之間的切換，能夠提供PaaS的服務(關系數據庫、負載均衡、緩存、對象存儲);DevOps的工具鏈和微服務架構支持。堯飄海表示，第三部分是網易蜂巢目前要重點解決的問題。
網易蜂巢的架構之路
堯飄海詳細介紹了網易蜂巢如何實現新一代云計算平臺，重點解析了基礎服務、編排調度相關的優化。因為網易云是網易內部成熟技術的商業化，作為網易云的基礎服務，網易蜂巢也是在網易私有云的基礎上封裝成為公有云服務的，網易蜂巢的構建，也是給網易多年積累的私有云不斷賦予公有云的特征的過程。
資源隔離的優化。安全性、多租戶的資源隔離是公有云必備的特征，而容器的安全性和隔離性是讓人擔憂的短板，但是把網易IaaS層非常成熟的方案(天然具有安全性、隔離性的特征)和容器技術結合起來，就可以把公有容器云的系統架構做好。
異構解耦。IaaS和容器的結合并不容易，網易私有云底層用OpenStack - 代碼實現用的是Python，而Docker、Kubernetes則依賴于Go語言，二者天然存在語言的異構性，并且OpenStack的代碼量太大，重構是不現實的。在架構設計上，網易蜂巢應用了微服務架構的理念解決平臺本身的異構語言通訊問題，通過引入消息中間件的模式解決來解決語言的依賴，因為OpenStack的RPC通訊模型依賴于MQ。
異步化。引入MQ，整個操作的流程就是異步化的，整個RPC的流程，從一臺云主機的生成到最后的服務，經過裸系統運行，再掛載網絡、存儲到服務落地，過程非常漫長。
簡化網絡。私有云的內部網絡，包括私有網絡、外網、IDC間的機房網絡、VPC的互通、VPN等七種網絡模型，路由非常復雜，而大部分公有云用戶不會用到這么復雜的網絡，所以需要進行簡化，做到對于普通用戶而言只有一個外網和一個內網的兩層網絡模型，最多加上一個VPN，另外針對大公司提供VPC網絡。
性能優化。精簡完網絡上線之后，如果使用傳統的API調用模型，并發在五個以上時，性能會受到影響，創建速度滿足不了容器秒級啟動的需求(傳統VM的啟動要求可能是分鐘級的)，所以需要進一步優化速度。這個環節有兩個思路，其一是采用CoreOS這樣理念前衛的操作系統來加速系統啟動，但對于做了很多年云計算的公司來說，轉型是很痛苦的、漫長的，也會遭到大部分人的抵制。蜂巢選擇了另外一種思路，就是分析出運行過程中的耗時大戶并將其優化。因為內核依賴的版本基本是固定的，抓取底層的數據，針對整個系統啟動的過程把時間序列統計打印出來，發現整個云平臺架構在大部分的時間都非常依賴于Networking Service，這是對DHCP的依賴帶來的消耗，所以網易蜂巢把DHCP過程解決掉，一開始就把IP注入進去，同時注入的還有路由信息，因為做完網絡的減法之后，注入路由、DNS服務器配置規則的方式非常輕量，通過網絡API接口就可以一次拿出注入。最終優化的結果，是5s左右的時間就能夠完成云主機的啟動到服務的整個過程。
按可用域多層調度。編排管理需要調度，網易蜂巢通過Kubernetes提供的框架做多層調度，實現高可用、持續集成以保證服務永遠在線。最簡單的調度資源是云主機，不僅要保證某一個服務不會調用同一臺物理機，還要保證它們在不同的可用域，做到機房之間的調度。
PaaS融合。PaaS服務，比如負載均衡，Kubernetes原生的負載均衡比較簡單，是單臺Nginx的模型運行服務，可能無法滿足商用、大流量的場景，網易蜂巢通過LB Controller，以插件化的模式把它融合到整個服務平臺上。
多租戶授權機制。Kubernetes提供給公有云用戶使用，其實有一個授權的過程，比如Kubernetes根據Namespace最多只能做到邏輯上的隔離，如果兩個租戶使用同一個Kubernetes集群，針對多租戶隔離需要額外做一個授權的機制，網易蜂巢把多租戶的完全隔離也融入到服務平臺上。
基礎工作做完之后，IaaS和PaaS層編排成服務調用，還需要很長的異步過程，需要按照指令的模式，讓指令可以做到重放，至少是唯一的、可分解的。此外，為了滿足公有云用戶的需求，網易蜂巢還解決了一些非功能性挑戰，例如可視化的運維能力，以及跨機房的容量規劃、風控系統等。
