本文由 網易雲 發布。
作者：劉超 來自：網易雲 基礎服務
無論是在社區，還是在同客戶交流的過程中，總會被問到到底什么時候該用 Docker？什么時候用虛擬機？如果使用容器，應該使用哪個容器平台？
顯而易見，我不會直接給大家一個答案，而是希望從技術角度進行分析具體的場景。例如客戶是大公司還是小公司，將部署小集群還是大集群，傾向於私有雲還是公有雲，已經采購了 IaaS 還是沒有 IaaS，IT 運維能力強還是弱，是否需要物理機、虛擬機、容器的混合部署，是一般的並發系統還是高並發，這里面所應該做的技術選型都不一樣。舉個例子，如果你是一個初創型的主營業務非 IT 的小公司，自然不應該花大力氣在數據中心里面自己搭建一套大規模、高並發、高性能的容器平台。
接下來，首先，我們來談下什么情況下應該使用 Docker 的問題。
如上圖所示，左面是我們經常掛在嘴邊的所謂容器的優勢，但是虛擬機都能一一懟回去。
如果部署的是一個傳統的應用，這個應用啟動速度慢，進程數量少，基本不更新，那么虛擬機完全能夠滿足需求。
○ 應用啟動慢：應用啟動 15 分鍾，容器本身秒級，虛擬機很多平台能優化到十幾秒，兩者幾乎看不出差別；
○ 內存占用大：動不動 32G，64G 內存，一台機器跑不了幾個；
○ 基本不更新：半年更新一次，虛擬機鏡像照樣能夠升級和回滾；
○ 應用有狀態：停機會丟數據，如果不知道丟了什么，就算秒級啟動也沒有用，照樣恢復不了，而且還有可能因為丟數據，在沒有修復的情況下，盲目重啟帶來數據混亂；
○ 進程數量少：兩三個進程相互配置一下，不用服務發現，配置不麻煩
如果是一個傳統應用，根本沒有必要花費精力去容器化，因為白花了力氣，享受不到好處。
那么什么情況下，才應該考慮做一些改變呢：
傳統業務突然被互聯網業務沖擊了，應用老是變，三天兩頭要更新，而且流量增大了，原來支付系統是取錢刷卡的，現在要互聯網支付了，流量擴大了 N 倍。
這種情況下就只能：拆。
拆開了，每個子模塊獨自變化，相互影響變少。
拆開了，原來一個進程扛流量，現在多個進程一起扛。
這被稱為微服務。
微服務場景下，進程多，更新快，於是出現 100 個進程，每天一個鏡像。
容器樂了，每個容器鏡像小，沒什么問題，虛擬機哭了，因為虛擬機每個鏡像太大了。
所以微服務場景下，可以開始考慮用容器了。
這時虛擬機又怒了，我不用容器了，微服務拆分之后，用 Ansible 自動部署是一樣的。
這從技術角度來講沒有任何問題，問題是從組織角度出現的。一般的公司，開發會比運維多得多，開發寫完代碼就不用管了，環境的部署完全是運維負責，運維為了自動化，寫 Ansible 腳本來解決問題。
然而這么多進程，又拆又合並的，更新這么快，配置總是變，Ansible 腳本也要常改，每天都上線，不得累死運維。
所以在如此大的工作量情況下，運維很容易出錯，哪怕通過自動化腳本。這時，容器就可以作為一個非常好的工具運用起來。
除了容器從技術角度，能夠使得大部分的內部配置可以放在鏡像里面之外，更重要的是從流程角度，將環境配置這件事情，往前推了，推到了開發這里，要求開發完畢之后，就需要考慮環境部署的問題，而不能當甩手掌櫃。
這樣做的好處就是，雖然進程多，配置變化多，更新頻繁，但是對於某個模塊的開發團隊來講，這個量是很小的，因為 5-10 個人專門維護這個模塊的配置和更新，不容易出錯。
如果這些工作量全交給少數的運維團隊，不但信息傳遞會使得環境配置不一致，部署量也會大非常多。
容器是一個非常好的工具，就是讓每個開發僅僅多做 5% 的工作，就能夠節約運維 200% 的工作量，並且不容易出錯。
然而原來運維該做的事情開發做了，開發的老大願意么？開發的老大會投訴運維的老大么？
這就不是技術問題了，其實這就是 DevOps，DevOps 不是不區分開發和運維，而是公司從組織到流程能夠打通，看如何合作，邊界如何划分，對系統的穩定性更有好處。
所以微服務、DevOps、容器是相輔相成，不可分割的。不是微服務，根本不需要容器，虛擬機就能搞定，不需要 DevOps，一年部署一次，開發和運維溝通再慢都能搞定。
所以，容器的本質是基於鏡像的跨環境遷移。
鏡像是容器的根本性發明，是封裝和運行的標准，其它什么 namespace，cgroup，早就有了，這是技術方面。
在流程方面，鏡像是 DevOps 的良好工具。
容器是為了跨環境遷移的，第一種遷移的場景是開發、測試、生產環境之間的遷移。如果不需要遷移，或者遷移不頻繁，虛擬機鏡像也行，但總是要遷移，帶着幾百 G 的虛擬機鏡像，太大了。
第二種遷移的場景是跨雲遷移，跨公有雲，跨 Region，跨兩個 OpenStack 的虛擬機遷移都是非常麻煩，甚至不可能的，因為公有雲不提供虛擬機鏡像的下載和上傳功能，而且虛擬機鏡像太大了，一傳傳一天。
所以跨雲場景下，混合雲場景下，容器也是很好的使用場景。這也同時解決了僅僅私有雲資源不足，扛不住流量的問題。
所以這是我認為的容器的本質，是最終應該使用容器的正確姿勢，當然一開始你不一定完全按照這個來。
模式一：公有雲虛擬機
適合場景：初創公司，無信息安全擔憂
如果您是一家初創公司，人員少，IT 運維能力不足，要部署的系統很少，能夠花在 IT 系統上的資金有限，當然應該選擇公有雲的虛擬機部署，它能夠解決您的如下問題：
○ 基層 IT 資源的管理交給公有雲平台，公司自身運維人員僅需要基本的 Linux 能力；
○ 少量的部署系統，例如 10 台以下的虛擬機，往往替換一個 war，重啟 Tomcat 就能解決，如果稍微虛擬機多一點 10 到 20 台，Ansible 腳本可以很好地解決這個問題；
○ 公有雲按量按時收費，可以在花費很少的情況下啟動，並且在業務飛速擴展的時候，迅速申請大量虛擬機；
這里所說的信息安全擔憂，真的僅僅是心理的擔憂，公有雲往往有大量的安全機制來保證每個租戶的安全隔離，只要用好了這些機制，公有雲的安全性絕對大於一般公司自己搭建的數據中心，當客戶在說要安全的時候，客戶在想什么？ 這篇文章講到了絕對的端到端解決方案。
這里貼張圖說明公有雲的安全性：
公有雲為支撐自身高並發業務積累了更強的安全防護能力和更多的安全防護經驗：
○ 多線 BGP，外網線路冗余
○ 高吞吐量的 DDoS 外網防護
○ 更完善的防火牆，入侵檢測，WAF
○ 更完善的流量清洗規則
公有雲為支撐自身高並發業務推出了更安全、更高可靠、更高可用的 PaaS 服務：
數據庫：
○ 高可用：主備切換數據零丟失
○ 高可靠：同城雙活，異地備份
○ 安全性：訪問控制，IP 白名單
對象存儲：
○ 高可靠：超大容量，三份備份，異地同步
○ 安全性：訪問控制，防盜鏈
公有雲為支撐自身高並發業務推出更完善的監控運維的系統，流程，經驗：
完善的監控系統，保障大促期間系統故障的快速定位和排障
保障大促能夠極大的提升和訓練一支有經驗的運維團隊
大促的業務層面的數據對運維也是機密的，需要流程保障
道高一尺魔高一丈，公有雲為保證自身業務的安全性對雲平台不斷升級：
○ 越來越強的 DDoS 防護
○ 越來越完善的防火牆規則
○ 最新的雲平台安全功能和機制
○ 不斷更新的虛擬機和容器鏡像建設漏洞
○ 不斷更新的病毒庫
模式二：無 IaaS，裸用容器
適用場景：初創公司無 IaaS，有信息安全擔憂
但是即便如此，還是有初創公司或者初創項目，也許因為心理方面，也許因為合規方面，非常擔心信息安全問題，還是希望采取部署在自己機房的方式。
但由於是初創公司，在機房里面一般是不能部署 IaaS，因為 IaaS 平台的運維難度，優化難度更大，沒有一個 50 人的團隊根本玩不起來，所以一般在使用容器之前，采用的是物理機部署的方式，當物理機數目非常小，比如部署 5 到 10 個應用的時候手動部署或者簡單腳本部署就可以，但是一旦到了 20 個應用，手動部署和簡單腳本就非常麻煩了：
○ 運維人員比例低，而應用相對較多
○ 部署在同一個物理機上的應用多，配置沖突，端口沖突，互相連接，運維需要一個 excel 去管理，還容易出錯
○ 物理機容器被腳本和 Ansible 改的亂七八糟，難以保證環境一致性，重裝物理機更加麻煩
○ 不同的應用依賴不同的操作系統和底層包，千差萬別
這個時候，可以試一下裸用容器，即在原來的腳本，或者 Ansible 里面，將啟動進程，改為使用 Docker run，可以有以下的作用：
○ 配置，端口隔離，沖突減少
○ 基於容器部署，使得環境一致性，安裝和刪除干干凈凈
○ 不同的操作系統和底層包，都可以用容器鏡像搞定
在這個階段，最簡單的方式就是把容器當做虛擬機來使用，也即先啟動容器，然后在里面下載 war 包等，當然也可以更進一步，將 war 包和配置直接打在容器鏡像里面，這樣需要一個持續集成的流程了，不僅僅是運維的事情，開發也要參與其中。
在這個階段，網絡的模式可以使用橋接打平的方式。
這種方式好處是訪問 Docker 和訪問物理機一樣，可很方便地實現 Docker 里面和物理機里面的互通，兼容原來部署在物理機上的應用。
當然 Bridge 的性能一般，如果性能要求比較高，可使用 SR-IOV 網卡嵌入容器內。
模式三：有 IaaS，裸用容器
適用場景：創新項目，引入 DevOps 流程
有一些公司規模大一些，已經采購了 IaaS，只不過有一些創新的項目需要部署，這種狀態下，基本虛擬機已經能夠滿足需求，而且由於能夠運維 IaaS，IT 能力比較強，一般也采用了 Ansible 等部署工具。
這種情況下，使用容器的動力相對比較少，然而容器也是能夠帶來一定好處的，就是 DevOps。
創新項目迭代速度比較快，如果有比較多的創新項目，對運維的壓力也是非常大的，這里的裸用容器和模式二的裸用容器不同的是，不是拿容器當做虛擬機來用，而是將容器當做交付物來用。
雖然容器化對於運維的整個過程來講改進有限，但是關鍵就是要開發寫一個 Dockerfile，這一點非常重要，意味着運行環境的配置提前到開發，而非直接交到運維，也即上面說的，開發 5% 的工作量增加減少大量運維工作，容器環境原子性升級回滾使得停服時間變短，可以保持開發、測試、運維環境的一致性。
模式四：使用 Docker Swarm Mode
適用場景：發展中公司，中等規模集群
當集群規模超過 50 台時，裸用容器已經非常難受了，因為網絡、存儲、編排、服務發現等全部要靠自己的腳本或 Ansible 來搞定，是時候引入容器平台了。
當容器平台規模不是很大時，Docker Swarm Mode 還是比較好用的：
○ 集群的維護不需要 Zookeeper，不需要 Etcd，自己內置
○ 命令行和 Docker 是一樣的，用起來順手
○ 服務發現和 DNS 是內置的
○ Docker Overlay 網絡是內置的
總之 docker 幫你料理好了一切，你不用太關心細節，很容易就能夠將集群運行起來。
而且可以通過 docker 命令，像在一台機器上使用容器一樣使用集群上的容器，可以隨時將容器當虛擬機來使用，這樣對於中等規模集群，以及運維人員還是比較友好的。
當然內置的太多了也有缺點，就是不好定制化，不好 Debug，不好干預。當你發現有一部分性能不行時，你需要改整個代碼，全部重新編譯，當社區更新了，合並分支是很頭疼的事情。當出現問題時，由於 Manager 大包大攬干了很多活，不知道哪一步出錯了，反正就是沒有返回，停在那里，如果重啟整個 Manager，影響面又很大。
模式五：使用 Marathon 和 Mesos
使用場景：萬節點集群，多定制
當集群規模大一些，幾百個節點時，很多人就不願意使用 Docker Swarm Mode 了，很多的選擇是既沒有用 DC/OS，也沒有用 Kubernetes，而是僅僅用了 Marathon 和 Mesos。
因為 Mesos 是一個非常優秀的調度器，它的雙層調度機制可以使得集群規模大很多。
Mesos 的調度過程如圖所示：
Mesos 有 Framework、Master、Agent、Executor、Task 幾部分組成。這里面有兩層的 Scheduler，一層在 Master 里面，allocator 會將資源公平的分給每一個 Framework，二層在 Framework 里面，Framework 的 scheduler 將資源按規則分配給 Task。
其它框架的調度器是直接面對整個集群，Mesos 的優勢在於，第一層調度先將整個 Node 分配給一個 Framework，然后 Framework 的調度器面對的集群規模小很多，然后在里面進行二次調度，而且如果有多個 Framework，例如有多個 Marathon，則可以並行調度不沖突。
詳細的調度機制非常復雜，可以看 號稱了解 mesos 雙層調度的你，先來回答下面這五個問題！這篇文章。
而且 Mesos 的架構相對松耦合，有很多可以定制化的地方，從而運維人員可以根據自己的需要開發自己的模塊。詳細的定制方式看文章 定制化 Mesos 任務運行的幾種方法。
這也是很多優秀的公司使用 Marathon 和 Mesos 的原因。
例如愛奇藝、去哪兒、攜程、當當等都選擇了使用 Mesos，需要提一下的是，大家如果參加社區，能發現裸用 Marathon 和 Mesos 的很多，但是整個 DC/OS 都用得比較少，而用 Marathon 和 Mesos 往往不能解決一些問題，因而這些 IT 能力非常強的互聯網公司做了大量的自己的定制化，增加了 Marathon 和 Mesos 的外圍模塊。
模式六：使用開源 Kubernetes
使用場景：千節點集群，少定制
Kubernetes 模塊划分得更細，模塊比較多，比起裸 Marathon 和 Mesos 來講功能豐富，而且模塊之間完全的松耦合，可以非常方便地進行定制化。
而且 Kubernetes 的數據結構的設計層次比較細，非常符合微服務的設計思想。例如從容器->Pods->Deployment->Service，本來簡單運行一個容器，被封裝為這么多的層次，每個層次有自己的作用，每一層都可以拆分和組合，這樣帶來一個很大的缺點，就是學習門檻高，為了簡單運行一個容器，需要先學習一大堆的概念和編排規則。
但是當需要部署的業務越來越復雜時，場景越來越多時，你會發現 Kubernetes 這種細粒度設計的優雅，使得你能夠根據自己的需要靈活的組合，而不會因為某個組件被封裝好了，從而導致很難定制。例如對於 Service 來講，除了提供內部服務之間的發現和相互訪問外，還靈活設計了 headless service，這使得很多游戲需要有狀態的保持長連接有了很好的方式，另外訪問外部服務時，例如數據庫、緩存、headless service 相當於一個 DNS，使得配置外部服務簡單很多。很多配置復雜的大型應用，更復雜的不在於服務之間的相互配置，可以有 Spring Cloud 或者 Dubbo 去解決，復雜的反而是外部服務的配置，不同的環境依賴不同的外部應用，External Name 這個提供了很好的機制。
包括統一的監控 cadvisor，統一的配置 confgMap，都是構建一個微服務所必須的。
然而 Kubernetes 當前也有一個瓶頸——集群規模還不是多么大，官方說法是幾千個節點，所以超大規模的集群，還是需要有很強的 IT 能力進行定制化，這個在模式七中會說一下我們在網易雲上做的事情。但是對於中等規模的集群也足夠了。
而且 Kubernetes 社區的熱度，可以使得使用開源 Kubernetes 的公司能夠很快地找到幫助，等待到新功能的開發和 Bug 的解決。
模式七：深入掌握使用 Kubernetes
使用場景：萬節點集群，IT 能力強
隨着 Kubernetes 使用規模的越來越大，大型的公司可以對 Kubernetes 進行一定的定制化，從而可以實現萬節點甚至更大規模的支撐，當然需要 IT 能力比較強，網易在這方面有很多的實踐。
從 APIServer 看集群的規模問題
隨着集群規模的擴大，apiserver 的壓力越來越大。
因為所有的其他組件，例如 Controller、Scheduler、客戶端、Kubelet 等都需要監聽apiserver，來查看 etcd 里面的變化，從而執行一定的操作。
很多人都將容器和微服務聯系起來，從 Kubernetes 的設計可以看出，Kubernetes 的模塊設計時非常的微服務化，每個進程都僅僅干自己的事情，而通過 apiserver 的松耦合關聯起來。
而 apiserver 則很像微服務中的 api 網關，是一個無狀態的服務，可以很好地彈性伸縮。
為了應對 listwatch，apiserver 用了 watchcache 來緩解壓力，然而最終的瓶頸還是在 etcd 上。
最初用的是 etcd2，這時候 listwatch 每次只能接受一個事件，所以壓力很大。為了繼續使用 etcd2，則需要使用多個 etcd2 的集群來解決這個問題，通過不同的租戶分配到不同的 etcd2 集群來分擔壓力。
將來會遷移到 etcd3 有了事件的批量推送，但是從 etcd2 到 etcd3 需要一定的遷移工作。
通過優化 Scheduler 解決並行調度的問題
大的資源池的調度也是一個很大的問題，因為同樣一個資源只能被一個任務使用，如果並行調度，則存在兩個並行的調度器同時認為某個資源空閑，於是同時將兩個任務調度到同一台機器，結果出現競爭的情況。
為了租戶隔離，不同的租戶是不共享虛擬機的，這樣不同的租戶是可以參考 Mesos 機制進行並行調度的。因為不同的租戶即便進行並行調度，也不會出現沖突的現象，每個租戶不是在幾萬個節點中進行調度，而僅僅在屬於這個租戶的有限的節點中進行調度，大大提高了調度策略。
並且通過預過濾無空閑資源的 Node，調整 predicate 算法進行預過濾，進一步減少調度規模。
通過優化 Controller 加快新任務的調度速度
Kubernetes 采用的是微服務常使用的基於事件的編程模型。
當有增量事件產生時，則 controller 根據事件進行添加、刪除、更新等操作。
但基於事件模型的一個缺點是，總是通過 delta 進行事件觸發，過了一段時間，就不知道是否同步了，因而需要周期性地 Resync 一下，保證全量的同步之后，然后再進行增量的事件處理。
然而問題來了，當 Resync 時，正好遇到一個新容器的創建，則所有的事件在一個隊列里面，拖慢了新創建容器的速度。
通過保持多個隊列，並且隊列的優先級 ADD 優於 Update 優於 Delete 優於 Sync，保證相應的實時性。
模式八：深入掌握使用 DC/OS
使用場景：萬節點集群，IT 能力強
前面說過 Mesos 由於本身獨特的調度機制，從而支撐的集群規模比較大，但是大多數使用 Mesos 的公司都沒有使用 DC/OS，而是裸使用 Marathon 和 Mesos 外加自己定制開發的一些組件。
Mesos 可以支持當集群規模非常大，單個 Marathon 的性能不足以支撐時，可以使用自己的 Framework 機制，使得不同的租戶使用單獨的 Marathon 來解決問題。
后來 DC/OS 在最基礎的 Marathon 和 Mesos 之上添加了很多的組件，如圖所示，現在已經非常豐富，例如 DCOS 的客戶端 (kubectl)、API 網關 admin router (類似 apiserver)、服務發現 minuteman(類似 kube-proxy)、Pod 的支持、CNI 插件的支持、存儲插件的支持等，和 Kubernetes 已經非常像了。
很多公司裸用 Marathon 和 Mesos 而沒有進一步使用 DC/OS，可能是因為和核心組件 Mesos 已經經過大規模生產性支撐不同，這些外圍的組件也是新的，對其穩定性也是有一定的顧慮，所以需要比較長的學習曲線，並且對於這些新的組件有非常好的把控，才敢上生產。
所以從這個角度來講，雖然 Mesos 的穩定性和大規模無容置疑，但就整個 DC/OS 來講，和 Kubernetes 從功能和穩定性來講，在伯仲之間，都需要使用者有強大的 IT 能力，對於開源軟件的各個模塊非常熟悉，甚至能夠做一定的代碼修改和 Bug fix，才敢在大規模集群中使用。
模式九：部署大數據，Kubernetes vs. Mesos
Mesos 還有一個優勢，就是 Mesos 可以通過開發 Framework，構建大數據平台，例如 Spark 就有基於 Mesos 的部署方式。
基於 Mesos 的 Spark 有兩種方式，粗粒度和細粒度。
粗粒度模式（Coarse-grained Mode）：應用程序的各個任務正式運行之前，需要將運行環境中的資源全部申請好，且運行過程中要一直占用這些資源，即使不用，最后程序運行結束后，回收這些資源。組粒度的方式浪費資源。
細粒度模式（Fine-grained Mode）：按需分配，應用程序啟動時，先會啟動 executor，但每個 executor 占用資源僅僅是自己運行所需的資源，不需要考慮將來要運行的任務，之后，mesos 會為每個 executor 動態分配資源，每分配一些，便可以運行一個新任務，單個 Task 運行完之后可以馬上釋放對應的資源。細粒度的缺點是性能有問題。
其實細粒度模式才是真正能夠發揮 Mesos 動態資源調度最有效的方式，但是考慮到有大幅度的性能降低，https://issues.apache.org/jira/browse/SPARK-11857，很可惜這種方式在 Spark 2.0.0 被 deprecated 掉了。
如果使用 kubernetes 部署大數據，其實和部署一個普通的應用思路差不多，和 Mesos 不同，kubernetes 不會干預到大數據運行的上下文中，Kubernetes 啟動的容器僅僅作為資源預留方式存在，容器內的資源分配則大數據平台自己解決。這樣的利用率就降低了，相當於粗粒度模式。
基於容器部署大數據平台，也是建議部署計算部分，例如 Map-Reduce，或者 Spark，對於數據部分 HDFS，應當另行部署。
模式十：容器和虛擬化混合部署
使用場景：大型公司，逐步容器化
對於很多大公司但是非互聯網公司，使用容器還是需要小心對待的，因而需要逐步容器化，所以存在有 IaaS 平台，並且虛擬機和容器混合使用的狀態，這種狀態可能會持續相當長的時間。
在這種情況下，建議容器套在虛擬機里面使用。
使用 Flannel 和 Calico 都僅僅適用於裸機容器，而且僅僅用於容器之間的互通。
一旦有 IaaS 層，就會存在網絡二次虛擬化的問題。
虛擬機之間的互聯是需要通過一個虛擬網絡的，例如 vxlan 的實現，而使用 Flannel 或者 Calico 相當於在虛擬機網絡虛擬化的上面再做一次虛擬化，使得網絡性能大幅度降低。
而且如果使用 Flannel 或者 Calico，那容器內的應用和虛擬機上的應用相互通信時，則需要出容器平台，多使用 node port，通過 NAT 的方式訪問，或者通過外部負載均衡器的方式進行訪問。在現實應用中，不可能一下子將所有的應用全部容器化，只是部分應用容器化，部分應用部署在虛擬機里面是常有的現象。然而通過 NAT 或者外部負載均衡器的方式，對應用的相互調用有侵入，使得應用不能像原來一樣相互調用，尤其是當應用之間使用 Dubbo 或者 SpringCloud 這種服務發現機制時，尤其如此。
網易雲開發了自己的 NeteaseController，在監聽到有新的 Pod 創建時，調用 IaaS 的 API 創建 IaaS 層的虛擬網卡，然后在虛擬機內部，通過調用 Netease CNI 插件將虛擬網卡添加到容器里面。添加技術用的就是上一節提到的 setns 命令。
通過這個圖我們可以看出，容器的網卡是直接連接到虛擬私有網絡的 OVS 上的，和虛擬機是一個平的二層網絡，在 OVS 來看，容器和虛擬機是在同一個網絡里面的。
這樣一方面沒有了二次虛擬化，只有 OVS 一層虛擬化。另外容器和虛擬機網絡打平的好處是，當部分應用部署容器、虛擬機時，對應用沒有侵入，應用原來如何相互訪問，現在還是如何訪問，有利於應用逐步容器化。
OpenStack 里面有一個項目 Kuryr 可以很好地去做這件事情，完全使用開源的 OpenStack 和 Kubernetes 可以嘗試集成一下。
了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/