背景
“雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。”
聊容器技術避不開雲原生，聊雲原生也避不開容器技術。容器技術和雲原生就是一對雙螺旋體，容器技術催生了雲原生思潮，雲原生生态推動了容器技術發展。從2013年docker（container）技術誕生，到2015年CNCF這個雲原生領域重量級聯盟便成立，這不是曆史的巧合而是曆史的必然。作為雲原生關鍵技術之一的容器，從2013年誕生以來一直是行業關注的焦點之一。借用一張業界廣泛引用的雲原生容器技術進階圖來了解一下容器技術和雲原生誕生的曆史背景。
先讓我們一起來看看容器技術發展的曆史紀年表，先直覺感受一下這片如火如荼的熱土吧！
1979年，Unix v7系統支援chroot，為應用建構一個獨立的虛拟檔案系統視圖。
1999年，FreeBSD 4.0支援jail，第一個商用化的OS虛拟化技術。
2004年，Solaris 10支援Solaris Zone，第二個商用化的OS虛拟化技術。
2005年，OpenVZ釋出，非常重要的Linux OS虛拟化技術先行者。
2004年 ~ 2007年，Google 内部大規模使用 Cgroups 等的OS虛拟化技術。
2006年，Google開源内部使用的process container技術，後續更名為cgroup。
2008年，Cgroups 進入了 Linux 核心主線。
2008年，LXC（Linux Container）項目具備了Linux容器的雛型。
2011年，CloudFoundry開發Warden系統，一個完整的容器管理系統雛型。
2013年，Google通過Let Me Contain That For You (LMCTFY) 開源内部容器系統。
2013年，Docker項目正式釋出，讓Linux容器技術逐漸席卷天下。
2014年，Kubernetes項目正式釋出，容器技術開始和編排系統起頭并進。
2015年，由Google，Redhat、Microsoft及一些大型雲廠商共同創立了CNCF，雲原生浪潮啟動。
2016年-2017年，容器生态開始子產品化、規範化。CNCF接受Containerd、rkt項目，OCI釋出1.0，CRI/CNI得到廣泛支援。
2017年-2018年，容器服務商業化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，華為CCI，Oracle Container Engine for Kubernetes；VMware，Redhat和Rancher開始提供基于Kubernetes的商業服務産品。
2017年-2019年，容器引擎技術飛速發展，新技術不斷湧現。2017年底Kata Containers社群成立，2018年5月Google開源gVisor代碼，2018年11月AWS開源firecracker，阿裡雲釋出安全沙箱1.0。
2020年-202x年，容器引擎技術更新，Kata Containers開始2.0架構，阿裡雲釋出沙箱容器2.0....
整理容器技術近20年的發展曆史，大緻可以将其分為四個曆史階段，下文将詳細介紹這四個曆史階段。
技術萌芽期
容器技術需要解決的核心問題之一運作時的環境隔離。容器的運作時環境隔離，目标是給容器構造一個無差别的運作時環境，用以在任意時間、任意位置運作容器鏡像。由于docker的布道，大家習慣性認為容器的運作時環境隔離就是OS虛拟化，或則容器等于namespace + cgroup + 安全防護機制。我不太贊同這種看法，這個隻是一段曆史時期、一種容器運作時的實作技術，還有很多種其它可能的技術方案來實作容器運作環境。是以，回到需求的本源：容器需要運作時隔離技術來保證容器的運作環境符合預期。習慣上，大家把這種實作容器隔離技術的元件叫做容器運作時。
從另外一個角度看，容器隔離技術解決的是資源供給問題。為啥需要容器隔離技術來解決資源供給問題呢？成也蕭何，敗也蕭何！摩爾定律實在太過強大，它讓我們有了越來越多的計算資源可以使用。10年前做小型機時，小型機的典型規格是32路8核CPU，現在一台4路PC伺服器計算能力都超過10年前的小型機伺服器。小型機的典型用法是把整機切分為多個分區使用。觀察當下雲服務硬體發展趨勢，越來越有熟悉的感覺，我們在把小型機相關技術“軍轉民”。現在我們一台PC伺服器擁有了非常強大的、能和十年前小型機媲美的計算能力，巧合的是當下PC伺服器的典型用法也和十年前的小型機用法類似，切割為1-8vCPU的虛拟機/容器使用。
為什麼人們總是習慣于把一個大的伺服器資源切分為小的分區使用而不是研發能夠充分發揮大型伺服器整機計算能力的軟體呢？個人認為背後有兩個制約因素：
待解決問題本身内在的并行度有限。随着多核多處理器系統的日益普及，IT行業從2004年開始進行串行程式設計到并行程式設計的更新改造。開始階段針對特定行業應用的并行化改造效果非常明顯，但是後來發現随着并行度提高改造成本越來越大、收益卻越來越低。受阿姆達爾定律制約，解決特定問題的并行度超過一定臨界點之後收益将逐漸變小。是以一味提高系統并行度并不是經濟的做法。
人類智力有限。受人類智力限制，系統越複雜、并行度越高，軟體越容易出故障，軟體維護代價成指數級增長。是以，從軟體工程看，大家也趨向于接口化、子產品化、單元化的軟體架構設計，盡量控制軟體的複雜度，降低工程成本。
從經驗看，1-8個CPU的并行度是軟體工程的舒适區，這個也是容器化、微服務等技術背後的驅動因素之一。
有點跑題了。。。總之，基于隔離的資源供給不是僞需求。對于軟體運作環境的隔離要求，從作業系統出現之初就有了。多任務分時作業系統和程序虛拟位址都是為了解決多個任務運作在同一台主機上的資源共享問題，讓每個程序都以為自己獨占主機。當然僅僅是程序隔離是遠遠不夠的。縱觀目前的資源隔離技術，我們大緻可以将資源隔離技術分成5類：
程序隔離。OS以程序作為Task運作過程的抽象，程序擁有獨立的位址空間和執行上下文，本質上OS對程序進行了CPU和記憶體虛拟化。但是程序之間還共享了檔案系統、網絡協定棧、IPC通信空間等多種資源，程序之間因為資源争搶導緻的幹擾很嚴重。這個層級的隔離适合在不同的主機上運作單個使用者的不同程式，由使用者通過系統管理手段來保證資源配置設定與安全防護等問題。
OS虛拟化。OS隔離，也就是大家常說的作業系統虛拟化（OS virtualization），是程序隔離的升華版。程序隔離是為每個程序實作了單獨的位址空間及CPU上下文，OS隔離則是利用作業系統分身術為每一組程序執行個體構造出一個獨立的OS環境，以進一步虛拟化檔案系統、網絡協定棧、IPC通信空間、程序ID、使用者ID等OS資源。OS隔離需要解決三個核心問題：獨立視圖、通路控制及安全防護。Chroot、Linux namespace機制為程序組實作獨立視圖，cgroup對程序組進行通路控制，而Capabilities、Apparmor、seccomp等機制則實作安全防護。當然，OS是一個非常複雜、動态變化的系統，OS分身術雖然讓程序組感覺有了獨立的OS，但是真實實作還是一個OS執行個體，是以整體防護能力還是堪憂。
硬體虛拟化。OS虛拟化是實作OS核心的分身術，而硬體虛拟化則是實作硬體裝置的分身術。硬體虛拟化技術的出現，讓同一個實體伺服器上能夠同時運作多個作業系統，每個作業系統都認為自己在管理一台完整的伺服器。不同作業系統之間是嚴格隔離的，Guest作業系統對硬體的通路都是受VMM或CPU的嚴格監管的。硬體虛拟化既有很好的安全性，也有很好的隔離性，缺點就是引入的硬體虛拟化層導緻了額外的性能開銷。
硬體分區。這個是傳統小型機體系采用的資源分隔技術，就是從硬體或固件層徹底把一台大型伺服器分隔為多個硬體單元，進而獲得最高等級的安全性和隔離性。但是小型機作為一個逐漸沒落的技術路線，其不足之處還是顯而易見的：資源分隔粒度不靈活、系統成本偏高、系統可擴充性受限。
語言運作時隔離。對于Java、nodejs等需要language runtime的managed language，我們還有一個選項，就是在language runtime裡實作隔離。針對函數計算等雲原生服務，理論上在語言運作時實作隔離機制是最優路徑。但是這條路線目前實作上還有不少現實的制約，是以目前多數函數計算還是采用的容器/VM技術來實作的隔離。
在OS虛拟化這條技術路線上，最大的技術貢獻來源于Google。2003-2006年，Google陸續釋出的“三駕馬車”，奠定了大資料計算的架構，随後進一步創造了“雲”的概念。也是從這時期開始，程序隔離技術進入了一個更進階的階段。在 Google 提出的雲計算架構下，被隔離的程序不僅僅是一個與外界隔絕但本身卻巍然不動的 Jail，它們更需要像一個個輕便的容器，除了能夠與外界隔離之外，還要能夠被控制與調配，進而實作分布式應用場景下的跨平台、高可用、可擴充等特性。2006年，Google推出Process Containers，用來對一組程序進行限制、記賬、隔離資源（CPU、記憶體、磁盤 I/O、網絡等）。由于技術更加成熟，Process Container 在 2006 年正式推出後，第二年就進入了 Linux 核心主幹，并正式更名為 Cgroups，标志着 Linux 陣營中“容器”的概念開始被重新審視和實作。在 2008 年，通過将 Cgroups 的資源管理能力和 Linux Namespace （命名空間）的視圖隔離能力組合在一起，一項完整的容器技術 LXC （Linux Container）出現在了 Linux 核心中，這就是如今被廣泛應用的容器技術的實作基礎。
總體看，在2013年docker被發明以前，Linux作業系統已經大體上解決了容器核心技術之一的運作環境隔離技術，或者說Linux OS虛拟化技術已經基本上成型了。雖然容器運作環境隔離技術已經基本就位，我們仍需等待另外一項關鍵技術才能迎來容器技術的騰飛時刻。
技術迸發期
2013年之前，雲計算行業一直在為雲原生的正确打開姿勢而操心。Platform as a Service（PaaS）看起來是個有前途的方向。2006年Fotango公司釋出的Zimi服務，可以說是PaaS行業的鼻祖，具有按使用付費、免運維（Serverless）、API化配置和服務等典型雲原生的特征；2008年Google推出GAE；2011年Pivotal釋出Cloud Foundry。這些早期的PaaS平台進行了非常有益的探索，推動了雲計算生态的健康發展，但是這些早期探索技術并沒有形成大的行業趨勢，而是局限在一些的特定的領域。直到Docker開源，大家才如夢方醒，原來不是方向不對，而是應用分發和傳遞的手段不行。
Docker真正核心的創新是容器鏡像（docker image），一種新型的應用打包、分發和運作機制。容器鏡像将應用運作環境，包括代碼、依賴庫、工具、資源檔案和元資訊等，打包成一種作業系統發行版無關的不可變更軟體包。
容器鏡像打包了整個容器運作依賴的環境，以避免依賴運作容器的伺服器的作業系統，進而實作“build once，run anywhere”。
容器鏡像一但建構完成，就變成read only，成為不可變基礎設施的一份子。
作業系統發行版無關，核心解決的是容器程序對作業系統包含的庫、工具、配置的依賴，但是容器鏡像無法解決容器程序對核心特性的特殊依賴。這個在實際使用容器的過程中也經常跳進這個大坑：
Docker的宣傳口号是“Build，Ship and Run Any App，Anywhere”。我們已經了解了docker通過container image解決“Run Anywhere”的機制，那麼“Run Any App”是如何實作的呢？其實也是依賴container image，使用者可以打包任何容器程序所依賴的環境，而不用改造應用來适配PaaS定義的運作環境。真是“Run Any App”一舉打破了PaaS行業面臨的困境，創造出了無限的可能性，大力推動了雲原生的發展。讓我們一起來向這個偉大的創意緻敬！
至此，容器技術體系已經解決了最核心的兩個問題：如何釋出軟體和如何運作軟體，騰飛時刻即将到來。2014年前司前老闆對我說“别成天搞Linux kernel了，要不你看看docker？” 經過短暫的調研，我給了前老闆一個簡單而清晰的回答，“無它，唯打包工具爾！”因為這個回答，雲原生為我打開的一扇大門就悄悄關上了。回想一下曆史，有時也挺懊悔的，因為自己太年輕而沒有看清楚容器技術 + 編排系統的威力，更沒有體會到雲原生即将到來的氣息！
Docker作為一個單機軟體打包、釋出、運作系統，其價值是非常巨大的；但是僅僅将docker技術局限在單機範圍不能發揮這個創新技術的最大價值，自然下一步業界希望基于docker技術建構一個雲化的叢集系統，來對業務容器進行編排管理。
聊到容器編排系統，我們需要從Google聊起。2008年，Google 基于 LXC 推出首款應用托管平台 GAE （Google App Engine），首次把開發平台當做一種服務來提供。GAE 是一種分布式平台服務，Google 通過虛拟化技術為使用者提供開發環境、伺服器平台、硬體資源等服務，使用者可以在平台基礎上定制開發自己的應用程式并通過 Google 的伺服器和網際網路資源進行分發。Google 在 GAE 中使用了一個能夠對 LXC 進行編排和排程的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 内部使用的大規模叢集管理系統，可以承載十萬級的任務、數千個不同的應用、同時管理數萬台機器。Borg 通過權限管理、資源共享、性能隔離等來達到高資源使用率。它能夠支援高可用應用，并通過排程政策減少出現故障的機率，提供了任務描述語言、實時任務監控、分析工具等。如果說一個個隔離的容器是集裝箱，那麼 Borg 可以說是最早的港口系統，而 LXC + Borg 就是最早的容器編排架構。
2013年docker推出之後迅速席卷全球，2014年Google基于内部使用的Borg系統建立了開源項目Kubernetes（簡稱K8S），用于解決大規模叢集的容器部署、運作、管理等問題。Kubernetes在容器的基礎上增加了一層的新的管理抽象Pod，以便更好地利用容器進行應用的功能子產品切分。得益于 Google 在大規模叢集基礎設施建設的強大積累，脫胎于 Borg 的 K8S 很快成為了行業的标準應用，堪稱容器編排的必備工具。
作為回應，Docker公司在2015年釋出的Docker 1.12版本中也加入了一個容器叢集管理系統Docker swarm，以及配套的Docker machine、Docker Compose等工具，力圖建構完善的容器編排系統，和Kubernetes展開正面競争。從此，容器江湖分為兩大陣營：Google派和Docker派；而容器編排系統則是Kubernetes，Docker Swarm和Apache Mesos三國并立。各大派系的競争愈演愈烈，逐漸延伸到行業标準的建立之争。讓我們一起來回憶一下這段風起雲湧的江湖曆史吧！
2013年Docker公司推出docker之後，緊接着CoreOS 應運而生。CoreOS 是一個基于 Linux 核心的輕量級作業系統，專為雲計算時代計算機叢集的基礎設施建設而設計，擁有自動化、易部署、安全可靠、規模化等特性。其在當時有一個非常顯眼的标簽：專為容器設計的作業系統。借着 Docker 的東風，CoreOS 迅速在雲計算領域蹿紅，一時間，Docker + CoreOS 成為業内容器部署的黃金搭檔。同時，CoreOS 也為 Docker 的推廣與社群建設做出了巨大的貢獻。然而，日漸壯大的 Docker 似乎有着更大的“野心”。不甘于隻做“一種簡單的基礎單元”的 Docker，自行開發了一系列相關的容器元件，同時收購了一些容器化技術的公司，開始打造屬于自己的容器生态平台。顯然，這對于 CoreOS 來說形成了直接的競争關系。2014 年末，CoreOS 推出了自己的容器引擎 Rocket （簡稱 rkt），試圖與 Docker 分庭抗禮。rkt 和 Docker 類似，都能幫助開發者打包應用和依賴包到可移植容器中，簡化搭環境等部署工作。rkt 和 Docker 不同的地方在于，rkt 沒有 Docker 那些為企業使用者提供的“友好功能”，比如雲服務加速工具、叢集系統等。反過來說，rkt 想做的，是一個更純粹的業界标準。
上面這段材料引至于“從虛拟化到雲原生——容器技術的發展史”，為什麼大段大段地引用這部分材料呢？這裡面最關鍵的脈絡是由于技術公司之間的商業競争，在競争合作之間尋找平衡進而導緻了标準規範的誕生，而标準規範的誕生是整個雲原生生态最重要的基石。
容器引擎（docker vs rocket）、容器編排（Docker swarm vs Kubernetes vs Apache Mesos）的互相競争的結果就是大家坐下來談接口标準。2015年6月，Docker帶頭成立OCI，旨在“制定并維護容器鏡像格式和容器運作時的正式規範（OCI Specifications）”，其核心産出是OCI Runtime Spec（容器運作時規範）、OCI Image Spec（鏡像格式規範）、OCI Distribution Spec（鏡像分發規範）。是以OCI組織解決的是容器的建構、分發和運作問題。一個月之後，Google帶頭成立了Cloud Native Computing Foundation（CNCF），旨在“建構雲原生計算 —— 一種圍繞着微服務、容器和應用動态排程的、以基礎設施為中心的架構，并促進其廣泛使用”。是以CNCF組織解決的是應用管理及容器編排問題。這兩個圍繞容器的基金會對雲原生生态的發展發揮了非常重要的作用，二者不是競争而是相輔相成，共同制定了一系列行業事實标準。這些行業事實标準的确立，各行業注入了無限活力，基于接口的标準的具體實作不斷湧現，呈現出一片百花齊放的景象。
其中，與容器相關的最為重要的幾個規範包括：CRI、CNI、CSI、OCI Distribution Spec、OCI Image Spec、OCI Runtime Spec和Shimv2。其中的CRI、OCI Image Spec、OCI Runtime和Shimv2規範和阿裡雲沙箱容器關系非常密切。
是以，非常感謝這個雲原生、容器技術迸發的黃金期，一群有創意的人走到一起共同創造了這幾個關鍵的規範，為各個廠商提供各具特色且遵循規範的技術實作提供了可能性。
商用探索期
經過5年的技術發展期，容器技術基本成熟，雲原生體系也具雛型。從2017年開始，各大雲廠商開始試水容器服務及進步的雲原生服務。從目前的商業形态看，容器相關的公共雲服務大緻可以劃分為三種形态：
通用容器編排服務。在容器編排系統三國殺結果出來以前，基于多方下注政策建構的容器編排服務系統。其中AWS是自研的編排系統，Azure的ACS同時支援Docker Swarm、DC/OS和Kubernetes，阿裡雲ACS則是支援Docker swarm和Kubernetes。Google和華為則是堅定支援Kubernetes而未推出支援其它容器編排系統的容器服務。随着Kubernetes一統容器編排江湖，這條路線的容器服務日漸式微，Azure更是在今年初直接終止了ACS服務。
Kubernetes容器編排服務。Google是理所當然最早試水Kubernetes容器編排服務的大廠，也較早開展了K8S容器編排服務。随着2017年各大廠在CNCF這張談判桌上達成了Kubernetes相容性認證流程，Kubernetes編排服務市場迎來一輪大爆發，到2018年各大雲廠商的K8S容器編排服務就完整就位了。
Serverless容器執行個體服務。從2017年開始，行業開始試水Serverless容器執行個體服務，把使用者從維護容器基礎設施的繁重任務中解放出來進而聚焦業務本身。Google Cloud Run核心目标是支援Knative，是以其使用形态上附加了不少限制條件。
從上圖可以看出，從2014年開始探索公共雲容器服務，特别是經過2017-2018年這兩年的搶跑期，容器服務的基本商業形态已經比較明晰了。發展态勢可以概括為：
行業對容器化的接受程度已經很高，容器化普及率也是逐年提升。
容器編排系統已經一戰定江山，K8S成為事實上的容器編排之王。
Serverless容器執行個體服務受到市場的歡迎，客戶群體日益擴大。
長期看托管容器編排服務和Serverless容器執行個體服務将長期共存，協同滿足客戶對服務成本和彈性能力的需求。
商用模式探索期間，核心目标是快速試錯引導和确認客戶需求，建構适用的産品形态。這個期間的産品技術架構的建構思路是利用現有成熟技術快速搭建商用形态，在試錯過程中不斷前行。
其中，容器編排托管服務節點級的典型架構是利用IaaS系統生成VM，然後在VM裡面部署kubelet、docker、containerd、runC等容器服務元件，也就是VM + 容器的技術架構。一個VM可以承載同一個使用者的多個容器/Pod執行個體。而Serverless容器執行個體服務的節點級架構更直接，在一個VM裡面隻部署一個容器/Pod執行個體，進而實作Serverless。這種短平快的打法快速推進了商用模型的探索，起到了非常重要的曆史作用，但是其在彈性能力、部署密度、資源成本方面的曆史局限性還是很大的。
商用拓展期
到2019年，容器服務的商業形态以及市場趨勢已經很明顯了，行業整體進入了商業拓展階段，對外宣傳吸引更多的客戶群體，對内苦練内功提升産品技術競争力，行業正在經曆從“有”到“優”的技術更新。行業正在經曆這個技術更新的曆史階段，還談不上結論，隻能一起來聊聊趨勢及預判。本系列專題的關注點是容器隔離技術，是以先不聊商業拓展和容器編排而聚焦于容器引擎技術發展趨勢。到現在為止，我們大體上可以把容器引擎技術劃分為兩代：
Container on VM。也就是按照分層設計思路，通過IaaS + PaaS的架構建構容器服務，這個是商用探索階段的典型架構。基于各大雲廠商成熟的IaaS基礎設施生産虛拟機，在虛拟機裡面部署容器服務元件。這種架構采用的是lift and shift政策，把容器服務的運維責任從使用者轉移到雲廠商。采用和使用者相同的軟體元件，隻是轉移運維責任，有利于引導客戶逐漸上雲、接受雲原生思維。但是這個時期雲廠商提供的服務是單純的運維托管，相對使用者自建容器服務并沒有太明顯的技術優勢，甚至受多租戶隔離的限制部分使用體驗還不如使用者自建容器服務。
Container with hardware virtualization。如果沿用Container on VM的分層設計架構，雲廠商很難建構獨有的技術優勢。對于Serverless容器執行個體服務，服務傳遞平面已經從IaaS的硬體接口上移到OS Syscall，是以不要遵循VM + 容器的分層設計思路。我們需要從需求本源出發，容器服務需要高性能、強隔離、夠安全和低成本的容器引擎。目前行業研發熱點之一就是如何建構這樣一個容器引擎，具體技術思路請留意後續系列文章。
小結
總結來看，容器服務生态大概經曆了四個階段，分别解決或試圖解決不同的問題：
技術萌芽期：解決了容器運作環境的隔離問題
技術迸發期：解決了軟體分發及容器編排問題
商用探索期：确認了容器的商用服務形态
商用拓展期：擴大适用場景和部署規模，通過技術創新提升産品競争力
閑言碎語
聊了這麼多曆史，讓我們再來閑聊一下docker這個公司和docker這門技術吧！
2019年11月13日，私有雲基礎設施公司Mirantis在其官方部落格宣布，收購Docker公司企業級業務，包括接管它的700多個客戶，這标志着Docker公司從2013年開始的商業化探索徹底失敗。在不了解容器發展曆史的人看來，這種結果很難了解，Docker是容器熱潮的開創者，容器則是這一輪雲計算技術演進的開啟者，為什麼明明站在風口上了，卻仍然飛不起來？
其實，Docker今天的命運，在4年前就決定了。2014年Kubernetes釋出後，迅速吸引了包括Redhat在内的一批重量級成員，并在一年之後迅速釋出Kubernetes 1.0以支撐正式商用。作為回應Docker公司主導成立了OCI，旨在為容器鏡像格式和運作時制定一個開放标準，進而繼續占據容器生态的話語權。但是2015年7月CNCF成立之後，迅速彎道超車開辟新的戰場，主攻容器編排與應用管理。随後2016年Kubernetes社群制定了容器運作時的接口規範CRI，隻要實作這個CRI規範的容器運作時就可以和K8S生态對接，從引發了容器引擎的研發熱潮。cri-containerd，cri-o，frakti等引擎不斷湧現，加上原有的rkt引擎，docker變成了容器引擎芸芸衆生中的一員。從哪兒來到哪兒去，docker又回到了最初的狀态，一個單機版軟體打包運作工具，基本上完美錯過了雲原生浪潮。
但是在相當長的時期内，docker這個用戶端容器管理工具（UI）還是會長期存在的，畢竟強大的使用者群體在哪兒。但是在雲服務廠商的技術棧中，docker的地位會越來越弱，逐漸被K8S專用的容器引擎替代。雖然現在docker的群衆基礎依然強大，但是星星之火已經點燃，趨勢已然顯現，剩下的隻是時間問題！