文章導覽
- 本文詳細解讀 Gartner 容器技術成熟度曲線(2023)中評估的 9 項重要技術,包括云原生架構(gòu)、Kubernetes、容器管理、容器原生存儲、KubeVirt、云原生基礎設施等。干貨滿滿,建議收藏!
- 文末附贈容器管理與?Kubernetes?持久化存儲技術評估與產(chǎn)品選型電子書,歡迎下載閱讀!
隨著越來越多的企業(yè)用戶開展 IT 基礎設施現(xiàn)代化轉(zhuǎn)型,容器技術正逐漸從“實驗室”走向生產(chǎn)環(huán)境。根據(jù) Gartner 的預測*,到 2027 年,全球超過 90% 的企業(yè)用戶將在生產(chǎn)環(huán)境中運行容器化應用,25% 的企業(yè)應用將在容器上運行。
現(xiàn)階段,有哪些容器相關技術已達到成熟,可以在生產(chǎn)環(huán)境中部署使用?又有哪些新興容器技術正在加速發(fā)展,值得用戶關注?本文,我們將重點解讀 Gartner 容器技術成熟度曲線(2023)中評估的 9 項重要技術,包括云原生架構(gòu)、Kubernetes、容器管理、Kubernetes 網(wǎng)絡、容器原生存儲、容器-虛擬機融合、Kubernetes 多集群管理、KubeVirt 和云原生基礎設施,幫助用戶了解這些技術的發(fā)展情況、市場現(xiàn)狀與實踐建議。
Gartner 技術成熟度曲線報告旨在分析不同技術領域中最受關注的技術與創(chuàng)新,定義技術所處的生命周期、企業(yè)價值、采納水平與未來增長速度。欲深入了解 Gartner 技術成熟度曲線,可閱讀往期分享詳細了解。
標藍技術為本文重點解讀技術
圖片來源:Hype Cycle for Container Technology, 2023
云原生架構(gòu)
技術早期成熟(Early Mainstream),預計 2-5 年達到市場成熟,覆蓋 20%-50% 目標用戶群體
云原生架構(gòu)是一組應用程序架構(gòu)原則和設計模式,能夠讓應用程序充分利用云計算提供的敏捷性、彈性擴展能力、可恢復性、靈活性等優(yōu)勢,同時具備延遲感知、儀表化、故障感知、事件驅(qū)動、安全性、并行處理、自動化和資源消耗感知(LIFESPAR)等能力。正因如此,許多企業(yè)在進行應用現(xiàn)代化轉(zhuǎn)型與 IT 基礎設施云化轉(zhuǎn)型時都會采用云原生架構(gòu),尤其是使用云、容器和無服務器基礎設施的用戶,云原生是一項必須遵從的原則,能夠確保應用程序能夠在動態(tài)環(huán)境下良好運行、高效利用資源,并優(yōu)雅地處理故障。
除了充分發(fā)揮云平臺的優(yōu)勢,云原生架構(gòu)對 DevOps 非常友好,開發(fā)人員能更高效地利用云的自服務與自動化能力,實現(xiàn)新產(chǎn)品的持續(xù)交付(CI/CD)。作為一種現(xiàn)代化原則,云原生架構(gòu)還能提升系統(tǒng)性能與業(yè)務連續(xù)性,并通過提高資源利用率降低成本。
不過,一些既有應用若想實現(xiàn)云原生轉(zhuǎn)型,需要進行較大的改動,同時云原生架構(gòu)也要求企業(yè)架構(gòu)工程師與開發(fā)人員投入一定的學習成本來掌握新技術與模式。
用戶建議
- 在構(gòu)建云原生應用程序時應遵循 LIFESPAR 架構(gòu)原則和 twelve-factor-app 規(guī)則(見參考文章),確保應用程序滿足基本的 DevOps 實踐要求。
- 對于新上線的應用程序,無論是否部署在云端,都基于云原生架構(gòu)的基本原則進行設計,保證能夠安全地在云平臺運行。
- 對傳統(tǒng)應用程序進行現(xiàn)代化改造時,應采用云原生架構(gòu)原則,保證其對動態(tài)變化基礎設施的適應能力。
- 根據(jù)您云原生架構(gòu)的成熟度與側(cè)重點選擇合適的應用程序平臺。例如,低代碼構(gòu)建的平臺可支持云化應用程序的快速開發(fā),但不完全符合 LIFESPAR 和 twelve-factor 原則;容器平臺需要云原生友好的架構(gòu);無服務器平臺則要求嚴格遵循 LIFESPAR 原則。
Kubernetes
技術早期成熟(Early Mainstream),預計 2 年內(nèi)達到市場成熟,覆蓋 20%-50% 目標用戶群體
Kubernetes 是一個開源的容器化工作負載編排和調(diào)度工具,由云原生計算基金會(CNCF)進行管理。作為目前容器編排與調(diào)度的既定標準,很多主流的容器管理供應商都提供基于 Kubernetes 的產(chǎn)品(90+ 經(jīng) CNCF 認證),很多開源與云原生技術生態(tài)也圍繞 Kubernetes 構(gòu)建,這也是這項技術重要的原因。
得益于 Kubernetes 敏捷與數(shù)字創(chuàng)新能力,企業(yè)用戶可以基于 Kubernetes 部署云原生或現(xiàn)代化應用, 從而更快地應對變化、提升用戶與員工體驗,同時避免廠商鎖定風險。具體而言,Kubernetes 可以幫助企業(yè)更好地管理多種基礎設施與服務器上的多個容器,具備多樣的技術生態(tài)(如基于容器的網(wǎng)絡與存儲、DevOps 工具鏈、可視化工具、安全工具等)以及由 CNCF 認證的產(chǎn)品、服務供應商與工程師。同時,由于主流云基礎設施與平臺服務商均提供基于 Kubernetes 的容器服務,用戶也可基于不同平臺與混合環(huán)境部署 Kubernetes,并利用多集群管理工具進行管理。同時,Kubernetes 對 AI/ML、無服務器服務、邊緣場景等新型用例的支持能力也越來越好。
不過同樣地,Kubernetes 要求用戶具備相關的知識與實踐經(jīng)驗,從開發(fā)者的角度看,Kubernetes 提供的功能較為原始和基礎,工具本身并不能直接用作云原生平臺。Kubernetes 的安全管理依舊比較復雜,用戶不僅需要確保容器運行時的安全,也需要保護容器鏡像與 CI/CD 流水線的安全。
用戶建議
- 基于 Kubernetes 開發(fā)新的云原生應用,并對傳統(tǒng)應用進行現(xiàn)代化改造,充分利用 Kubernetes 開放的生態(tài)系統(tǒng)和新的創(chuàng)新技術。
- 確?;?Kubernetes 構(gòu)建的平臺可以在混合環(huán)境或多云環(huán)境中實現(xiàn)統(tǒng)一管理,從而高效滿足不同應用團隊的不同需求。
- 通過增加在“自服務”能力上的投入,鼓勵開發(fā)人員采用 Kubernetes 技術。
- 確定企業(yè)是否需要招募與發(fā)展 Kubernetes 專業(yè)人員。評估基礎架構(gòu)與運維團隊在 Kubernetes 運維管理上的現(xiàn)有能力與技術差距。
推薦閱讀:接管 K8s 部署運維,基礎架構(gòu)團隊是否做好準備?| SmartX 趨勢分享
容器管理
技術早期成熟(Early Mainstream),預計 2-5 年達到市場成熟,覆蓋 20%-50% 目標用戶群體
根據(jù) Gartner 的定義,容器管理是能夠支持容器化工作負載的解決方案,交付方式包括云端、托管服務以及運行在本地、公共云和/或邊緣的容器軟件。相關技術包括編排和調(diào)度、服務發(fā)現(xiàn)和注冊、鏡像注冊表、路由和網(wǎng)絡、服務目錄、管理用戶界面以及 API。
容器管理工具能夠使得大規(guī)模容器鏡像的配置、運維和生命周期管理以自動化的方式進行,并通過集中式的管理和安全策略來管理容器實例和相關資源。因此,容器管理可為現(xiàn)代應用需求,包括平臺工程、云管理以及 CI/CD 流程,提供高敏捷性、彈性和創(chuàng)新支持。
根據(jù) Gartner 的業(yè)內(nèi)調(diào)查,由于越來越多的開發(fā)團隊大規(guī)模部署容器進行應用開發(fā),容器管理的需求也水漲船高。另外,對于需要近距離獲取算力和數(shù)據(jù)的邊緣應用(如數(shù)據(jù)通信服務、制造工廠等),以及 AI/ML 等需要靈活擴展能力的應用,基于容器環(huán)境進行部署的用例越來越多,也增加了容器管理的使用需求。
目前,容器管理市場正蓬勃發(fā)展,很多廠商的服務可提供混合環(huán)境或多云環(huán)境的支持能力。不過由于市場的多樣化,用戶需要甄別不同產(chǎn)品與服務,可能需要避免一些過于抽象的、無服務器的產(chǎn)品與服務。
用戶建議
- 判斷企業(yè)是否需要采用容器管理軟件,評估方面包括企業(yè)預計的軟件開發(fā)速度與不可變基礎設施建設目標、混合云需求,以及運營第三方容器管理軟件所需的工作量。
- 利用集成在云基礎設施即服務(IaaS)和平臺即服務(PaaS)提供商服務中的容器管理功能,來嘗試、適應容器環(huán)境的工作流程變化。
- 除非企業(yè)內(nèi)部具備足夠的專業(yè)人員與技術支持,否則應避免直接使用底層開源容器平臺(如 Kubernetes)。
推薦閱讀:選型 K8s 管理平臺需關注哪些核心能力?ChatGPT 和 Gartner 分別這樣說
Kubernetes 網(wǎng)絡
技術早期成熟(Early Mainstream),預計 2-5 年達到市場成熟,覆蓋 5%-20% 目標用戶群體
Kubernetes 網(wǎng)絡軟件主要解決三個需求:容器之間的通信、外部實體與服務間的通信(通常稱為南北向流量)以及 Pod 到服務間的通信(通常稱為東西向流量)。容器網(wǎng)絡接口(CNI)插件負責容器間的網(wǎng)絡通信和 Pod 到服務間的通信;Ingress 控制器/網(wǎng)關 API 處理南北向流量;而服務網(wǎng)格主要提供強化的東西向流量控制和安全能力。
Kubernetes 自身提供的網(wǎng)絡能力,難以滿足企業(yè)大規(guī)模部署的生產(chǎn)級工作負載需求,這就需要 CNI 和 Ingress 控制器提供安全、可擴展、支持大規(guī)模管理的網(wǎng)絡能力。一些 CNI 軟件還支持設置網(wǎng)絡策略,可高效地為整個 Kubernetes 集群提供分布式防火墻與多租戶支持。
對于部署在本地的 Kubernetes 集群,采用第三方 CNI 與 Ingress 控制產(chǎn)品是非常有必要的,不過一些商業(yè)平臺也會提供默認的 CNI 插件。另外值得注意的是,一些廠商難以隨 Kubernetes 版本更新而同步進行產(chǎn)品升級,同時使用 Kubernetes 網(wǎng)絡產(chǎn)品可能會導致 Pod 不再擁有固定的 IP 地址,打亂已有的網(wǎng)絡安全流程。
用戶建議
- 判斷企業(yè)是否需要網(wǎng)絡策略或容器間的加密網(wǎng)絡能力,如果需要,建議采用一款先進的 CNI 產(chǎn)品。
- 考慮 Kubernetes 網(wǎng)絡時,應避免獨立地做出決策,在采購、設計和部署容器網(wǎng)絡解決方案時,應確保網(wǎng)絡、云和開發(fā)團隊均參與到項目中。
- 避免在 Kubernetes 環(huán)境中手動進行網(wǎng)絡配置,應采用自動化或自服務方式配置網(wǎng)絡資源。
- 在部署過程中,優(yōu)先考慮將已部署的網(wǎng)絡虛擬化或數(shù)據(jù)中心網(wǎng)絡方案擴展到 Kubernetes 環(huán)境。
- 優(yōu)先選擇擴展現(xiàn)有負載均衡或 API 網(wǎng)關供應商的入口控制器。將即插即用的 Kubernetes 網(wǎng)絡集成需求納入網(wǎng)絡 RFP。
容器原生存儲
技術成長期(Adolescent),預計 2-5 年達到市場成熟,覆蓋 5%-20% 目標用戶群體
根據(jù) Gartner 給出的定義,容器原生存儲(CNS)專為支持容器業(yè)務而設計,側(cè)重于滿足獨特的云原生架構(gòu)、存儲顆粒度和性能方面的需求,并提供與容器管理系統(tǒng)的深度整合。CNS 符合微服務架構(gòu)原則并遵循容器原生數(shù)據(jù)服務的要求,即不受硬件限制、API 導向性和基于分布式軟件架構(gòu)。
容器原生存儲專為云原生應用提供持久化存儲能力,通?;诜植际降?、軟件定義的、統(tǒng)一的存儲資源池,提供容器級別的數(shù)據(jù)服務與數(shù)據(jù)管理功能。同時,容器原生存儲的整個堆棧能夠與 Kubernetes 進行編排,以管理容器生命周期整合,并為開發(fā)人員提供自服務能力。
容器原生存儲不僅可以支持有狀態(tài)的云原生應用程序,還能增強基礎架構(gòu)的靈活性和可用性。對 Kubernetes 等容器編排技術的廣泛采用,也使得容器原生存儲的需求大幅增長,用戶需要可以與 Kubernetes 深度整合的存儲方案來支持有狀態(tài)應用。
然而, 并非所有企業(yè)都會采用 CNS 解決方案,因為它主要適用于全新部署的云原生應用程序,或需要進行重構(gòu)的應用程序;且對于傳統(tǒng)企業(yè)來說,容器原生解決方案可能會在短期內(nèi)增加操作復雜性。另外,容器原生存儲方案也存在技術孤島的風險,一些用戶不敢在現(xiàn)階段大規(guī)模采用。
用戶建議
- 選擇符合微服務架構(gòu)原則并遵守容器原生數(shù)據(jù)服務要求的存儲解決方案,例如不受硬件限制、API 驅(qū)動、基于分布式架構(gòu),并能夠支持邊緣云、核心云或公有云部署。
- 存儲解決方案應與企業(yè)云戰(zhàn)略保持一致,確保 CNS 在所選擇的公有云和混合云場景中的適用性。
- 檢驗供應商在持續(xù)創(chuàng)新交付、高質(zhì)量客戶支持方面的能力,并確認供應商能提供一致的定價模式。
- 確保 CNS 解決方案已通過測試并適用于特定的 Kubernetes 平臺。
推薦閱讀:
- 一文看懂 K8s 持久化存儲、云原生存儲、容器原生存儲、K8s 原生存儲有何區(qū)別
- 干貨分享|K8s 持久化存儲怎么做?這本電子書帶你從入門到選型
容器-虛擬機融合
技術萌芽期(Emerging),預計 5-10 年達到市場成熟,覆蓋 5%-20% 目標用戶群體
容器與虛擬機(Container-VM)融合指的是虛擬化技術中的 hypervisor 和基于操作系統(tǒng)(OS)的虛擬化技術的融合。通過整合和優(yōu)化容器和虛擬機的最佳特性,容器-虛擬機融合提供了更好的工作負載隔離和更高的基礎設施利用率。底層技術包括與容器運行時集成的經(jīng)過優(yōu)化的 hypervisor。
容器滿足了現(xiàn)代基礎設施的敏捷需求,而虛擬機是數(shù)據(jù)中心基礎設施的基本要素,因此容器-虛擬機融合將帶來“兩全其美”的效果,為未來基礎設施建設提供了新的選擇。具體而言,容器-虛擬機融合使得用戶可以在增強基礎設施敏捷能力的同時提供安全保障。同時,對虛擬化環(huán)境的利用可降低未來 IT 基礎設施轉(zhuǎn)型壓力與成本投入,并幫助傳統(tǒng)應用快速實現(xiàn)現(xiàn)代化轉(zhuǎn)型。
不過,容器-虛擬機融合技術在目前的企業(yè)環(huán)境中并沒有被廣泛認可和使用,對于一些對安全和合規(guī)性要求嚴格的企業(yè),容器-虛擬機融合會帶來潛在的合規(guī)風險。而且已有的容器-虛擬機融合方案,大部分基于 Linux 系統(tǒng),會帶來一定的限制。
用戶建議
- 建議企業(yè)為容器-虛擬機融合做好計劃和準備,該技術可為企業(yè)提供可滿足開發(fā)人員需求的現(xiàn)代化、云化基礎設施,同時保證生產(chǎn)環(huán)境的安全和運維管理。
- 企業(yè)需要就虛擬化基礎設施在數(shù)據(jù)中心、分布式云、公有云和邊緣的作用達成共識,并認識到不少場景依舊可能需要使用各種虛擬化技術。
- 以漸進的方式實現(xiàn)容器-虛擬機融合,在支持未來的需求下,確保轉(zhuǎn)型不會妨礙或復雜化現(xiàn)有的服務級別的需求。
Kubernetes 多集群管理(Cluster Fleet Management)
技術萌芽期(Emerging),預計 2-5 年達到市場成熟,覆蓋 5%-20% 目標用戶群體
Kubernetes 多集群管理(Cluster Fleet Management)是一組新興的工具和流程,用于管理多個Kubernetes 集群的生命周期和狀態(tài)。Kubernetes 多集群管理的關鍵能力包括部署和升級編排軟件,以及在集群之間分發(fā)容器化應用和操作策略。這些解決方案可以支持單一和/或不同的 Kubernetes 發(fā)行版。
隨著 Kubernetes 使用場景的增長,基礎設施和運營團隊漸漸發(fā)現(xiàn),他們需要同時部署和管理位于不同區(qū)域(包括本地、云端和跨區(qū)域)的多個 Kubernetes 集群,甚至是對基于不同 Kubernetes 發(fā)行版的多個集群進行統(tǒng)一管理。Kubernetes 多集群管理工具可以更好地幫助用戶進行 Kubernetes 集群管理,尤其是針對混合環(huán)境、多租戶環(huán)境、災備場景和邊緣場景,這些工具可以減輕運維和管理的負擔。
目前一些公有云廠商會針對每個 Kubernetes 集群管理平面收取單獨的費用,并不利于多集群的管理;而使用商用 Kubernetes 多集群管理工具,可能會引入廠商鎖定的問題。另外,統(tǒng)一管理不同的 Kubernetes 發(fā)行版也比較復雜,這些都為 Kubernetes 多集群管理帶來障礙。
用戶建議
- 選擇一個管理平臺來控制多個 Kubernetes 集群的生命周期和運行,實現(xiàn)多個集群間自動化分發(fā) Kubernetes 資源定義、策略與身份。
- 確定是基于單一發(fā)行版部署 Kubernetes 集群,還是采用平臺工程方式,基于不同的 Kubernetes 發(fā)行版進行部署,并規(guī)范操作和應用部署工作流程。
- 盡可能地自動化集群生命周期管理,采用不可變方法定義抽象的集群類,以便按需啟動特定的集群實例。避免使用專用集群,目標是在需求出現(xiàn)時能夠在任何集群上部署應用程序。
KubeVirt
技術孵化期(Embryonic),預計 5-10 年達到市場成熟,覆蓋目標用戶群體少于 1%
KubeVirt 是一個開源項目,允許企業(yè)在 Kubernetes 集群內(nèi)創(chuàng)建和操作虛擬機,讓虛擬化和容器化應用程序能夠在同一個 Kubernetes 集群中并行運行。
企業(yè)的開發(fā)與運維團隊可以使用容器的管理 API 以同樣的方式管理虛擬機,通過虛擬化與容器環(huán)境的融合,既能滿足現(xiàn)代化應用的開發(fā)需求,也可保留虛擬化環(huán)境,逐漸向現(xiàn)代化基礎設施過渡。此外,對于需要在裸金屬架構(gòu)上部署 Kubernetes 的邊緣場景,以及對于尋求 VMware 虛擬化替代方案的用戶,KubeVirt 也提供了一種基礎架構(gòu)部署思路。
不過,作為一項新興技術,KubeVirt 在 2023 年夏天剛發(fā)布 1.0 版本,仍缺少一些企業(yè)生產(chǎn)環(huán)境的實踐驗證。另外,運維管理工具的缺失也為采用 KubeVirt 技術帶來了一些障礙。
用戶建議
- 基于機會成本評估 KubeVirt 的使用價值。在資源有限的情況下,企業(yè)應評估傳統(tǒng)基礎設施現(xiàn)代化轉(zhuǎn)型 vs. 新建現(xiàn)代化基礎設施的投資收益。
- 對于難以基于容器部署,但是可以通過 Kubernetes 云原生編排提高效益的工作負載,利用 KubeVirt 提供支持是個不錯的選擇。
- 與提供 KubeVirt 解決方案的供應商溝通,了解他們在該技術方面的發(fā)展計劃和路線圖,以及相關客戶成功案例。
- 確保您的戰(zhàn)略技術合作伙伴支持 KubeVirt。這包括獨立軟件供應商(ISV)對生產(chǎn)環(huán)境中運行的虛擬工作負載的認證和支持,以及支持 KubeVirt 工作負載的硬件和操作系統(tǒng)的兼容性和認證。
推薦閱讀:利用 IOMesh 為 KubeVirt 提供高效穩(wěn)定的存儲支持(附用戶實踐)
?
云原生基礎設施
技術成長期(Adolescent),預計 2-5 年達到市場成熟,覆蓋 1%-5% 目標用戶群體
云原生基礎設施是一種專為開發(fā)和/或交付基于云原生架構(gòu)的應用程序而優(yōu)化的基礎設施,具有可編程、彈性、不可變、模塊化、聲明式管理等特性,支持自服務。雖然云原生基礎設施有很多實現(xiàn)方式,但在實踐中,大規(guī)模的云原生基礎設施通?;谌萜骱?Kubernetes 部署。
相比傳統(tǒng) IT 基礎設施,云原生基礎設施具備更現(xiàn)代化的服務能力,包括服務發(fā)現(xiàn)、可編程、自動化、可觀測性、強大的網(wǎng)絡通信和安全性等,能更好地滿足現(xiàn)代化應用對運行速度、敏捷性、可擴展性的要求。同時,云原生基礎設施可以將云計算的成本優(yōu)勢擴展到本地部署的基礎設施,包括本地計算和存儲的按需交付(CBMs),以及在本地運行的公有云 Kubernetes 服務。此外,云原生基礎設施可以進一步實現(xiàn)應用與底層基礎設施的解耦,避免廠商鎖定的情況。
不過,云原生基礎設施還在發(fā)展階段,主流企業(yè)也處于早期技術采納階段,在企業(yè)管理(如 DevOps 實踐)、運維工具、平臺工程與 DevOps 技術能力等方面,仍需企業(yè)進行投入、增強實力。
用戶建議
- 全面規(guī)劃和實施云原生基礎設施,并優(yōu)先考慮新的運營和采購模型,來支持云原生架構(gòu)和技術。
- 根據(jù)開發(fā)人員的反饋,持續(xù)提升基礎設施云原生能力,并建設擁有專業(yè)技能的平臺工程團隊。
- 實現(xiàn)云原生基礎設施的自動化運維,最大限度地為上層應用提供敏捷能力。
- 評估新興的云原生基礎設施解決方案(包括無服務器計算和裸金屬環(huán)境),量化潛在的成本、性能和生產(chǎn)力優(yōu)勢。
為了充分滿足用戶對容器技術的使用需求,SmartX 也為用戶提供了容器管理、網(wǎng)絡與存儲產(chǎn)品,包括生產(chǎn)級容器管理與服務產(chǎn)品?SMTX Kubernetes 服務(簡稱 SKS)、軟件定義的網(wǎng)絡與安全產(chǎn)品組件?Everoute,和國內(nèi)首款 Kubernetes 原生持久化存儲?IOMesh。三種產(chǎn)品均可為 Kubernetes 環(huán)境提供原生支持,同時具備 Gartner Hype Cycle 中提到的新興技術優(yōu)勢:
針對 Kubernetes 運維管理與持久化存儲,我們還結(jié)合權威機構(gòu)分析報告與技術解讀文章,整理了兩本電子書《IT 基礎架構(gòu)團隊的 Kubernetes 管理:從入門到評估》和《Kubernetes 持久化存儲方案選擇:從入門到評估》,歡迎讀者下載閱讀!文章來源:http://www.zghlxwxcb.cn/news/detail-820396.html
閱讀原文:《一文解讀 Gartner 容器技術成熟度曲線中的 9 項重點技術 》文章來源地址http://www.zghlxwxcb.cn/news/detail-820396.html
到了這里,關于容器走進生產(chǎn)環(huán)境,哪些相關技術值得關注?解讀 Gartner 容器技術成熟度曲線的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章,希望大家以后多多支持TOY模板網(wǎng)!