PouchContainer 現(xiàn)在服務于阿里巴巴集團和螞蟻金服集團的絕大部分 BU， 包括交易&中間件，B2B/CBU/ICBU，搜索廣告數(shù)據(jù)庫，還有收購或入股的一些公司，比如優(yōu)酷高德、UC等。其中體量***的是交易和電商平臺，在 2017 年雙 11 的時候我們支撐了破紀錄的峰值，背后的應用都是跑在 PouchContainer 里面，整體容器實例已經(jīng)到了***規(guī)模。使用了 PouchContainer 的應用涵蓋了各種各樣的場景。這些場景從運行模式來看，有標準的在線 App，還有像購物車、廣告、測試環(huán)境等比較特殊的場景。不同的場景對 PouchContainer 有不同的使用方式和需求。從編程語言看，實際運行著 Java、C/C++，Nodejs，GoLang 等語言編寫的應用。從技術棧的角度看，包含了電商、DB、流計算、大數(shù)據(jù)、專有云等場景，每個場景對于容器各方面要求，所用到的特性都不太一樣，PouchContainer 針對每個場景的需求都在產(chǎn)品上都做了支持。

PouchContainer 容器技術在阿里的演進過程伴隨著阿里技術架構本身的演進。阿里內(nèi)部技術架構經(jīng)歷了一個從集中式單體應用到分布式微服務化的演進。

淘寶最開始是一個巨石型的應用，一個應用里包含了商品、用戶、下單等等所有交易鏈路的功能。隨著功能越來越完善，維護起來也越來越困難。為了提高研發(fā)效率，從 2008 年開始我們逐漸把這個應用拆分成了多個分布式應用，商品的，交易的，用戶的，前臺的，后端的；通過 HSF 遠程調(diào)用框架，TDDL 分布式數(shù)據(jù)層和 Notify 分布式消息中間件串聯(lián)起來。其中每個服務都有多個實例，都可以獨立研發(fā)演進，并可以進一步繼續(xù)拆分。于是就逐漸形成了一個龐大的分布式服務集群。從巨石型應用到多個單一功能的輕量級服務型應用，總的應用實例數(shù)變多了，每個實例需要的系統(tǒng)資源變少了。于是從最初的每個實例直接使用物理機自然過渡到使用 Xen，KVM 等虛擬化技術。VM 使用了一段時間之后，發(fā)現(xiàn)整體物理機的利用率還是很低。當時一個 24 核的物理機只能虛出 4 臺 4 核的 VM，除了當時虛擬化本身的開銷不小外，每個應用實例在 VM 里仍然用不完分到的資源。于是就想能不能不用虛擬機，用更輕量的基于進程級別的資源切分使用方式。

這個時候阿里內(nèi)部的運維體系已經(jīng)比較龐大了，從應用的構建部署到分發(fā)，到一些運行期的監(jiān)控告警等管控系統(tǒng)，都依賴于一個應用實例跑在一個獨立機器里的假定。這個假定已經(jīng)不經(jīng)意間貫穿到了研發(fā)運維的各個環(huán)節(jié)里面，包括系統(tǒng)的設計，運維習慣等都嚴重依賴這個假定。我們不可能重新搭建集群，把存量的業(yè)務停掉再到新的集群里面用新的運維模式去跑起來，這個業(yè)務和運維上都是沒法接受的，不可能電商交易的研發(fā)停幾個月，系統(tǒng)停幾天來搞這個事情。所以我們首先要做到兼容，新的資源使用方式必須兼容原先的假定。我們經(jīng)過仔細分析了這個假定的內(nèi)涵，發(fā)現(xiàn)每個應用實例歸納下來無非有如下 4 點要求：

• 有獨立IP
• 能夠SSH登陸
• 有獨立的，隔離的文件系統(tǒng)
• 資源隔離，并且使用量和可見性隔離

首先是有獨立 IP，能夠 SSH 登錄。其次有獨立的文件系統(tǒng)，應用程序跑起來，希望程序看到的整個文件系統(tǒng)都是給他專用的，因為現(xiàn)有的代碼和配置中必然有很多路徑的硬編碼，需要滿足這個潛在要求。還有不管通過工具還是代碼，他只能看到分配給他自己的資源。比如 4 個 CPU，8G 的內(nèi)存，他能夠根據(jù)這些資源的用量做一些監(jiān)控，做一些對自己資源使用量的采集和告警。這四個特點總結下來就是新的資源使用方式要做到和物理機或者 VM 的使用體驗一致。能夠做到這樣的話原先跑在 VM 里的應用就可以很平滑的遷移過來，現(xiàn)有的應用系統(tǒng)和運維系統(tǒng)不需要做很大的改動。

我們?yōu)榱四苓_到這四點，最開始是多隆大神手工 Hack 系統(tǒng)調(diào)用，glibc 基礎庫等，實現(xiàn)了一些資源上的隔離。像有獨立的 IP 可登錄 ，就用虛擬網(wǎng)卡，在每個容器里面起一個 sshd 進程；資源的隔離和可見性上，就用 Cgroup 和 Namespace 等內(nèi)核特性；后來發(fā)現(xiàn)開源的 LXC 項目也在做同樣的事情，并且比手工 Hack 更通用化，更優(yōu)雅一些。于是我們集成 LXC，并且在內(nèi)核上加了定制的資源可見性隔離的 patch，讓用戶的實例只能看到分配給他的 CPU和內(nèi)存，另外還增加了基于目錄的磁盤空間隔離的 patch，這樣就形成了我們***代的容器產(chǎn)品。這個產(chǎn)品當時代號是 T4，寓意是第四代淘寶技術，淘寶 4.0；在 2011 年的時候 T4 容器技術灰度上線。T4 相比 VM，完全沒有虛擬化 Hypervisor 層的開銷，資源切分和分配上更加靈活，可以支持不同程度的資源超賣。這樣就很好的支持了業(yè)務爆發(fā)增長的需求，控制了物理機按業(yè)務增長比例膨脹的勢頭。另外因為 T4 完全兼容了之前研發(fā)和運維對物理機和 VM 的使用習慣，絕大多數(shù)應用都能夠做到透明的切換，應用無感知。因為有這些特性，在接下來的短短幾年時間里，T4 逐步接管了交易和電商主體的在線應用。

到 2015 年的時候 Docker 技術火起來了。我們寫程序的都知道有個著名的公式，程序=數(shù)據(jù)結構+算法。從程序交付使用變成一個軟件產(chǎn)品的角度來看，我們可以套用這個公式：

• 軟件= 文件（集）+ 進程（組）；

從靜態(tài)來看，軟件從構建分發(fā)到部署，最終形式是一個有依賴層次的文件集。從動態(tài)來看，這些文件集，包括二進制和配置，由操作系統(tǒng)加載到內(nèi)存后執(zhí)行，就是一個有交互關系的進程組。我們之前的 T4 容器在進程（組），或者說運行時上做的事情和 Docker 基本類似，比如說都使用了 Cgroup、Namespace、linux bridge 等技術。還有些是 T4 特有的，比如基于目錄的磁盤空間的隔離，資源可見性隔離，對老版本內(nèi)核的兼容等。我們從最早物理機演化到 VM，再到現(xiàn)在的容器，內(nèi)核的升級周期比較漫長，迭代很慢，15年的時候存量的機器上全部都是 2.6.32 內(nèi)核，T4是兼容 2.6.32 內(nèi)核的。 但是另一方面在文件（集）的處理上 Docker 做得更好，更加系統(tǒng)化。 T4 只做了很薄的一層鏡像，給相同的業(yè)務域做了一個基礎的運行和配置環(huán)境，這個鏡像沒有深入到每一個特定的應用。 而 Docker 是將每個應用的整個依賴棧打包到了鏡像中。因此在 2015 年我們引入了 Docker 的鏡像機制來完善自己的容器。

在將 Docker 鏡像整合進來之后，原來基于 T4 的研發(fā)運維體系受到了很大的沖擊。 首先交付方式變了，之前是 build 一個應用的代碼包，把代碼包交給我們的部署發(fā)布系統(tǒng)，后者創(chuàng)建一個空的容器，根據(jù)這個業(yè)務所在的很薄的模板把一個空的容器跑起來，再到容器里面安裝依賴的一些 IPM 包，設置一些配置，按每個應用定好的一個列表一個一個的安裝好，然后把應用包解壓啟動起來。這個應用依賴的軟件和配置列表我們內(nèi)部叫做應用的基線。引入鏡像之后，在將 Docker 鏡像整合進來之后，原有的交付方式發(fā)生了變化。之前是 build 一個應用的代碼包，把代碼包交給我們的部署發(fā)布系統(tǒng)，后者創(chuàng)建一個空的容器，根據(jù)這個業(yè)務對應的很薄的一個模板，把一個空的容器跑起來，再到容器里面安裝依賴的一些 RPM 包，設置一些配置，按每個應用定好的一個清單一個一個的安裝好，然后把應用包解壓到主目錄啟動起來。這個應用依賴的軟件和配置清單我們內(nèi)部叫做應用的基線。引入鏡像之后，我們應用的代碼包和依賴的所有的這些三方軟件、二方軟件都會打成一個鏡像。之前通過基線維護應用依賴環(huán)境，現(xiàn)在都放到每個應用自己的 Dockerfile 中了，整個研發(fā)構建和分發(fā)運維的過程大大簡化了。

做了這個事情之后，研發(fā)和運維之間的職責和邊界就發(fā)生了變化。之前研發(fā)只需要關注功能，性能，穩(wěn)定性，可擴展性，可測試性等等。引入了鏡像之后，因為要自己去寫 Dockerfile，要了解這個技術依賴和運行的環(huán)境倒底是什么，應用才能跑起來，原來這些都是相應運維人員負責的。研發(fā)人員自己梳理維護起來后，就會知道這些依賴是否合理，是否可以優(yōu)化等等。研發(fā)還需要額外關注應用的可運維性和運維成本，關注自己的應用是有狀態(tài)的還是無狀態(tài)的，有狀態(tài)的運維成本就比較高。這個職責的轉(zhuǎn)換，可以更好的讓研發(fā)具備全棧的能力，思考問題涵蓋運維領域后，對如何設計更好的系統(tǒng)會帶來更深刻的理解。所以引入 Docker 之后對研發(fā)也提出了新的要求。我們總結新的時期，新的運維模式下對研發(fā)能力要求的幾個要素，總結起來就是幾個原則：

為了更好的把自己的系統(tǒng)建設好，我們要倡導研發(fā)從***天建立系統(tǒng)的時候，就要考量最終的可運維性，比如參數(shù)是否可配置，是否可以隨時重啟。機器每天都有硬件故障產(chǎn)生，這些硬故障不可能每天都人工處理，必須要盡可能自動化處理，自動化處理時，雖然有些故障只影響了一部分實例，另一部分是好的，但是也可能需要一起處理，比如需要物理機上的業(yè)務全部遷移走來維修物理機的時候。所以不管當時容器里的業(yè)務是好的還是不好的，都要滿足隨時可重啟，可遷移的要求。原來是部分交付，現(xiàn)在要考慮你到底運行環(huán)境是什么樣的，什么樣的運行環(huán)境才能跑起來，盡量做標準化的操作。比如說啟動，Dockerfile 里面寫好啟動的路徑，不要再搞一些特殊的處理，如果有任何特殊的處理都沒法做統(tǒng)一的調(diào)度和運維。統(tǒng)一的業(yè)務遷移，機器騰挪也沒法做。我們的目標其實就是從一開始的比較粗放的運維，到不斷的開發(fā)自動化的工具和系統(tǒng)，形成一個體系，通過前期人工運維的過程把一些固定的故障處理的流程模式化，***提取出來一些可以自動處理故障，自動恢復的機制。我們的最終目標是無人職守。所有這些加起來其實就是我們引入鏡像化之后，并且要朝著無人值守的方向演進時，對研發(fā)和運維的新的要求。

上面是 PouchContainer 容器的 Roadmap， 2011 年的時候 T4上線 ，到 2015 年 3 月的T4 覆蓋了交易的大部分應用。這個時候開始引入了 Docker 鏡像機制，這里面做了很多兼容性的工作。比如說原來 T4 輕量化的模板轉(zhuǎn)化成對應的基礎鏡像，里面兼容了很多之前運維的習慣和運維的工具，如賬號推送，安全策略，系統(tǒng)檢測。我們在 2016 年初上線了***個鏡像化應用，到 5 月份的時候集團決定主站全部應用容器化。在做鏡像之前阿里是有一兩百人的團隊做每個應用的部署，運維，穩(wěn)定性控制，后來這個團隊都沒有了，全部轉(zhuǎn)成了 DevOps，轉(zhuǎn)向開發(fā)工具和運維平臺，通過代碼的方式，工具的方式解決運維的問題。之前專職做運維的同學***的負擔就是線上環(huán)境的變更，研發(fā)提交變更申請給運維同學，運維同學做線上操作，研發(fā)不知道代碼運行環(huán)境具體依賴了哪些基礎軟件。做了鏡像化的事情后，研發(fā)自己負責編寫 Dockerfile，運維就把環(huán)境變更的事情通過 Dockerfile 的機制移交給了研發(fā)。運維和研發(fā)之間的邊界就非常清楚了，這個邊界就是由 Dockerfile 來定義的。研發(fā)負責把他代碼依賴的環(huán)境在 Dockerfile 定義好，運維保證其構建分發(fā)時沒有問題。我們在 2016 年雙11的時候完成了交易核心應用的鏡像化 PouchContainer 化改造。在 2017 年雙11的時候交易全部應用完成了鏡像化改造。然后我們在 2017 年 11 月 19 日的時候宣布了 PouchContainer 的正式開源。

我們的內(nèi)部 PouchContainer 經(jīng)過大規(guī)模的運行，支持了各種各樣的業(yè)務場景，各種不同的技術棧，不同的運行形態(tài)，積累了非常多的經(jīng)驗。這些經(jīng)驗之前跟阿里內(nèi)部的環(huán)境耦合性比較大。比如說我們的網(wǎng)絡模型，我們其實是嵌入到了阿里內(nèi)部的網(wǎng)絡管控平臺，包括IP分配在內(nèi)部都有獨立的系統(tǒng)去完成。比如什么時候啟用 IP，什么時候下發(fā)路由等等，這些是有一個統(tǒng)一的 SDN 網(wǎng)絡管理系統(tǒng)來管理的。還有類似的內(nèi)部存儲系統(tǒng)，還有運維的一些指令推送系統(tǒng)。內(nèi)部系統(tǒng)耦合性比較大，沒法直接開源。所以我們***選擇的策略是先在外部孵化一個從零開始全新的項目，把內(nèi)部的特性一點點搬上去。這個過程中我們內(nèi)部的版本也會做重構，把內(nèi)部的依賴做一些插件化解耦合的方式，這樣***全新的項目在外部可以跑得很好；在內(nèi)部用一些耦合內(nèi)部環(huán)境的插件也可以跑起來，最終的目標是內(nèi)外用一套開源版本。

那么我們的 PouchContainer 容器相對于其他容器有什么差異呢？主要體現(xiàn)在隔離性、鏡像分發(fā)優(yōu)化、富容器模式、規(guī)?；瘧煤蛢?nèi)核兼容性幾個方面。傳統(tǒng)的容器隔離維度就是 namespace、cgroup；在資源可見性方面，我們前幾年是通過在內(nèi)核上打 patch，在容器內(nèi)看內(nèi)存和 CPU 利用率等數(shù)據(jù)時，把統(tǒng)計數(shù)值和當前容器的 Cgroup 和 Namespace 關聯(lián)起來，使容器能使用的資源和已使用的資源都是容器自己的。18年的時候我們引入了社區(qū)的lxcfs，這樣就不需要對特定內(nèi)核 patch 的依賴了。磁盤空間的限制也是在低版本內(nèi)核上加了補丁，支持了基于文件目錄的磁盤空間隔離，能夠把每個容器的 rootfs 限制住。在 4.9 以上的內(nèi)核上，我們是用 overlay2 文件系統(tǒng)來完成同樣功能的。我們也在做基于 hypervisor 的容器方案，提升容器的隔離性和安全性，我們在 PouchContainer 里面集成了 RunV，用于一些多租戶的場景。

阿里內(nèi)部的離在線混部之所以能推進，在同一個機器上既能跑在線的業(yè)務又能跑離線的一些任務，互相之間不會出現(xiàn)太大的干擾，其核心的技術就是 PouchContaienr 容器可以根據(jù)優(yōu)先級，把不同業(yè)務的資源使用隔離開來，保證在線業(yè)務優(yōu)先使用資源。這個資源包括很多的維度，比如 CPU、內(nèi)存，CPU cache、磁盤、網(wǎng)絡等等。

這是 PouchContainer 的鏡像分發(fā)設計。我們內(nèi)部有很多比較核心的應用，體量比較大，實例會分布在上萬臺物理機上。發(fā)布新版本的時候上萬臺機器同時拉鏡像，任何中心的鏡像倉庫都扛不住。因此我們設計了一套鏡像分發(fā)的二級架構，在每個地域建一個 mirror，在同一個地域內(nèi)拉鏡像的時候用 P2P 分發(fā)技術---我們內(nèi)部的產(chǎn)品名叫蜻蜓，已經(jīng)開源；需要拉鏡像的服務器之間可以分散互相拉文件片段，這樣就直接化解了中心鏡像倉庫的服務壓力和網(wǎng)絡壓力。后面其實還有更好的解決鏡像分發(fā)的思路，我們正在嘗試鏡像的遠程化，通過存儲計算分離技術，用遠程盤的方式掛載鏡像，直接跳過或者說異步化了鏡像分發(fā)這一步，目前正在內(nèi)部環(huán)境灰度運行中。

這是 PouchContainer 內(nèi)部版本的體系結構。在***層的宿主機層面，我們會做一些管理和運維，目的是為了確保容器運行依賴的基礎環(huán)境是健康的，包括宿主機的一些鏡像清理，包括安全控制、權限管理等。OS 的低版本內(nèi)核我們是適配到*** 2.6.32 內(nèi)核，包括容器里面的進程管理也做了很多的適配。資源隔離前面講過了，網(wǎng)絡模型我們內(nèi)部其實主體用的是 Bridge，但是其他各種各樣的場景也都支持。我們開發(fā)了很多插件，PouchContainer 開源后，我們才將這些插件逐步做了標準化，兼容適配了社區(qū)的 CNI 標準。最上層是一個富容器模式的支持，每個容器里面會啟動一些跟內(nèi)部的運維工具，運維系統(tǒng)息息相關的一些組件，包括一些發(fā)布模式的優(yōu)化?？梢钥吹轿覀儍?nèi)部體系結構是比較復雜的，尤其依賴內(nèi)部的其他系統(tǒng)比較多，在外部直接跑是跑不起來的，因此也沒法直接開源。

所以我們開源版本是重新開始搭建的，這樣會比較清爽一些。我們引入了contained，支持不同的 runtime 實現(xiàn)，包括我們自己包裝 lxc 開發(fā)的 RunLXC 運行時，可以用來支持老版本 2.6.32 內(nèi)核。開源版 PouchContainer 兼容所有 Docker 的接口，也支持 CRI 協(xié)議，這樣也就同時支持了比較主流的兩種集群管理系統(tǒng)。網(wǎng)絡方面我們內(nèi)部基于 libnetwork 做了增強，包括不同場景暴露出來的一些問題，一些穩(wěn)定性，規(guī)?；臅r候各種細節(jié)的一些優(yōu)化。存儲方面我們支持了多盤，內(nèi)存盤，遠程盤等各種不同形式的存儲。PouchContainer 可以無縫集成到上層編排工具中，包括 Kubelet 和 Swarm 等。我們內(nèi)部的 Sigma 調(diào)度系統(tǒng)，不同的版本Docker 協(xié)議和CRI協(xié)議都會使用。

這是 PouchContainer 的開源地址： https://github.com/alibaba/pouch

如何貢獻： https://github.com/alibaba/pou ... NG.md

最近 PouchContainer 開源版本 GA 已經(jīng)發(fā)布，PouchContainer 能夠在如此短的時間內(nèi) GA，離不開容器社區(qū)的支持，在超過 2300 個 commit 的背后，有 80 多位社區(qū)開發(fā)者的踴躍貢獻，其中不乏國內(nèi)一線互聯(lián)網(wǎng)公司、容器明星創(chuàng)業(yè)公司貢獻者的參與。

PouchContainer 開源版本發(fā)布 GA 之前，此開源容器引擎技術已在阿里巴巴數(shù)據(jù)中心得到大規(guī)模的驗證；GA 之后，相信其一系列的突出特性同樣可以服務于行業(yè)，作為一種開箱即用的系統(tǒng)軟件技術，幫助行業(yè)服務在推進云原生架構轉(zhuǎn)型上占得先機。

Q：你們是怎么樣做到把阿里巴巴集團包括高德還有菜鳥那些，都能把這個技術推過去，因為大公司在不同的部門跨部門甚至是跨子公司之間要想推行你們的某一個部門的研究成果是一件比較困難的事情。

A：這是一個好問題，我們其實也面臨過這個問題。我們的方法就是首先要和大家宣導這個理念，讓大家在認知上都接受鏡像化運維能帶來的優(yōu)勢，長遠發(fā)展的好處。雖然很難有直接立竿見影的收益，長遠來看一定能提高運維效率，降低資源使用的成本。實際上從這兩年來看，我們確實降低了不少運維成本。

Q：你好，我想問一下容器里面的那些持久化是怎么處理的？

A：容器我們持久化現(xiàn)在大體分兩類數(shù)據(jù)，一個是日志，一種是應用自己會寫一些數(shù)據(jù)，像搜索業(yè)務。要么就是放在本地盤，放在本地的話做遷移的時候要自己處理數(shù)據(jù)的遷移，每個不同的業(yè)務處理的都不太一樣。還有一種方式是用遠程，數(shù)據(jù)遠程化。我們有分布式存儲系統(tǒng)“盤古”，通過容器創(chuàng)建的時候在遠程存儲集群建一塊遠程盤，我們現(xiàn)在用的是塊設備，然后掛載到容器里面，容器用完或者是遷移的時候，數(shù)據(jù)是在遠端的，可以隨意遷移到另一個地方，再把這個數(shù)據(jù)盤掛載回來。

搜索也可以放遠端，對于阿里各種搜索場景，我理解如果replica數(shù)多的話，用遠端存儲是比較經(jīng)濟劃算的，如果replica數(shù)就1行，或2行，而且遠端性能又滿足不了部分場景的需求，短時間內(nèi)就不如本地多塊盤來進行混部?？傮w趨勢來說，如果沒有性能要求的話，都放遠端是趨勢。

Q：哪種方式會更多一些？

A：宿主機直接到容器里面，相對來說***的場景是在數(shù)據(jù)庫，數(shù)據(jù)庫現(xiàn)在大部分是在本地，但是有一部分是放在遠端的，正在演進的過程中，還沒有***完成存儲計算的分離。后面有一天可能就完全沒有本地數(shù)據(jù)了。

Q：這是云框架，一聽到云這個架構就感覺很大，是一個什么海量運維，海量數(shù)據(jù)，對于中小型公司規(guī)模可能沒那么大，對于要想用這套框架，實施的成本是多少，用戶量在多少以下適合或者不適合？

A：很難有明確的臨界點，說什么時候該用云化架構了。從中小型公司來說可以從***天就往這個方向，或者是朝這個模式去實現(xiàn)。比如說搭一個很小的資源池，通過彈性混合云的方式，在云上去擴容，這也是一種很好的方式。如果***天完全不考慮這些事情，怎么方便怎么搭建，也不考慮這些單點，容災這些彈性的事情，后面改造起來可能就會比較痛苦。

Q：這個部署的成本，兩個人或者三個人的研發(fā)團隊，用你這個東西周期有多長時間呢？它的難易度，因為要理解整個框架，你要部署這個東西要理解這個東西，我覺得學習的曲線還有部署的難度到底是什么樣的？

A：后面這套系統(tǒng)在做 Sigma 敏捷版就是解決中小企業(yè)的問題，兩三個開發(fā)者不可能開發(fā)出一套像現(xiàn)在這個規(guī)模的完整云化架構，***的是用云上支持這些場景的產(chǎn)品。云產(chǎn)品本身經(jīng)過很多用戶的考驗，有這么多云上運作的一些經(jīng)驗，一些技術上的沉淀，比自己開發(fā)要靠譜得多。

Q：我想問一下 PouchContainer 這個容器跟底層還會去封裝 Docker 之類的東西，我***次接觸這個，另外鏡像庫的話是能夠跟 Docker 兼容嗎？

A：首先鏡像庫跟 Docker 是完全兼容的，Docker 分了很多層，底層的 runV 和 containerd 都貢獻到了社區(qū)，是開源的，我們在 runV 和 containerd 的基礎上做了增強?？傮w來說是兼容兩個社區(qū)的兩種主流的技術路線，兩種集群管理系統(tǒng)，Kubernetes 和 Docker 公司 Swarm，這種兩種路徑都支持。