關(guān)于作者：

楊傳輝，OceanBase CTO。2010 年作為創(chuàng)始成員之一加入 OceanBase 團(tuán)隊(duì)，主導(dǎo)了 OceanBase 歷次架構(gòu)設(shè)計(jì)和技術(shù)研發(fā)，從無(wú)到有實(shí)現(xiàn) OceanBase 在螞蟻集團(tuán)全面落地。同時(shí)，他也主導(dǎo)了兩次 OceanBase TPC-C 測(cè)試并打破世界紀(jì)錄，著有《大規(guī)模分布式存儲(chǔ)系統(tǒng)：原理與實(shí)踐》。目前，楊傳輝帶領(lǐng) OceanBase 技術(shù)團(tuán)隊(duì)致力于打造更加開(kāi)放、靈活、高效、易用的下一代企業(yè)級(jí)分布式數(shù)據(jù)庫(kù)。

我從 07 年開(kāi)始研究大規(guī)模分布式系統(tǒng)，剛開(kāi)始參照 Google 三駕馬車(chē)（GFS / MapReduce / Bigtable），10 年開(kāi)始加入當(dāng)時(shí)的淘寶做 OceanBase。

OceanBase 最初是一個(gè)分布式架構(gòu)，支持的 SQL 功能非常有限，后來(lái)逐步加入 SQL 功能并通用化。剛開(kāi)始接觸大規(guī)模分布式系統(tǒng)的時(shí)候，我覺(jué)得這個(gè)領(lǐng)域特別高大上，當(dāng)年的分布式系統(tǒng)有點(diǎn)像今天的 ChatGPT，涉及的技術(shù)很前沿，而且有些協(xié)議非常難，我記得當(dāng)時(shí)僅僅理解 Paxos 協(xié)議就花費(fèi)了一年多的時(shí)間，看了十幾篇相關(guān)論文且和小伙伴們做了大量的技術(shù)討論。

曾經(jīng)有一段時(shí)間，我覺(jué)得分布式是 IT 軟件技術(shù)皇冠上的明珠，所有系統(tǒng)只有做成分布式才顯檔次。但是，當(dāng)我們將 OceanBase 早期版本應(yīng)用到淘寶和支付寶時(shí)，用戶(hù)和 DBA 給我們提出的都是 SQL 兼容性和性能成本相關(guān)的需求，把我們和單機(jī)的 MySQL 數(shù)據(jù)庫(kù)做比較，只有完全兼容且性?xún)r(jià)比更高才會(huì)選擇 OceanBase。他們告訴我，OceanBase 的擴(kuò)展性和無(wú)損容災(zāi)確實(shí)很好，也認(rèn)同分布式這個(gè)方向，但是對(duì)不起，老板說(shuō)今年業(yè)務(wù)發(fā)展太快，不能投入額外人力做數(shù)據(jù)庫(kù)改造，也不能投入額外的數(shù)據(jù)庫(kù)服務(wù)器。

過(guò)去有一句土話(huà)叫“既要也要還要”，小孩才做選擇，用戶(hù)和 DBA 想要的就是一個(gè)不要做選擇的“成年人的數(shù)據(jù)庫(kù)“。我記得當(dāng)時(shí)還和 Google Spanner 的研發(fā)人員做過(guò)一次技術(shù)討論，我問(wèn)他們?yōu)槭裁?Google 內(nèi)部能夠接受 Spanner 很差的單機(jī)性能，他們告訴我 Google 內(nèi)部的程序員很強(qiáng)，大家都可以把應(yīng)用修改為異步程序。另外一點(diǎn)就是，Google 有 Jeff Dean，只要他想統(tǒng)一基礎(chǔ)架構(gòu)就可以自上而下推進(jìn)。我很羨慕 Google 內(nèi)部做基礎(chǔ)設(shè)施的研發(fā)人員，同時(shí)，我也意識(shí)到，這種模式是不可擴(kuò)展的。對(duì)于開(kāi)發(fā)者來(lái)講，一定要把單機(jī)的高性能低門(mén)檻融入到分布式的可擴(kuò)展高可用才能做出一個(gè)真正好用的分布式數(shù)據(jù)庫(kù)。

我們?cè)?2016 年發(fā)布了全分布式架構(gòu) OceanBase 1.0 版本，這個(gè)版本的所有節(jié)點(diǎn)都是可讀可寫(xiě)的，但是，有一個(gè)問(wèn)題，那就是每個(gè)節(jié)點(diǎn)用于分布式相關(guān)的 overhead 比較大，當(dāng)表格和分區(qū)較多時(shí)，即使系統(tǒng)空轉(zhuǎn)，也會(huì)消耗好幾個(gè) CPU 核用于分布式相關(guān)操作。這個(gè)問(wèn)題使得 OceanBase 1.x 系列的版本只能幫助較大規(guī)模的企業(yè)解決數(shù)據(jù)庫(kù)的問(wèn)題，很難在中小企業(yè)做規(guī)?；瘡?fù)制。

于是，我們?cè)?2018 年開(kāi)始討論如何降低分布式數(shù)據(jù)庫(kù)的門(mén)檻，讓分布式數(shù)據(jù)庫(kù)成為一個(gè)人人皆可觸達(dá)的東西。數(shù)據(jù)庫(kù)底層架構(gòu)的調(diào)整需要非常慎重，我們足足花費(fèi)了兩年多的時(shí)間完成了技術(shù)討論和總體架構(gòu)的設(shè)計(jì)，并在 2020 年年中左右開(kāi)始做詳細(xì)設(shè)計(jì)和代碼開(kāi)發(fā)，再經(jīng)過(guò)兩年多的時(shí)間才在 2022 年 8 月份發(fā)布了第一個(gè) OceanBase 4.0 版本，代號(hào)“小魚(yú)“。4.0 版本奠定了單機(jī)分布式一體化架構(gòu)的底座，但是還有很多的遺留問(wèn)題，在 3 月份開(kāi)發(fā)者大會(huì)發(fā)布的 4.1 版本中解決。

我們從 2021 年開(kāi)始對(duì)外鋪墊一體化架構(gòu)的概念，最早的一體化架構(gòu)叫做“集中式分布式一體化“，當(dāng)時(shí)我們認(rèn)為 DBA 更加熟悉集中式這個(gè)說(shuō)法。不過(guò)，市場(chǎng)品牌的負(fù)責(zé)人建議修改成 “單機(jī)分布式一體化”，這樣會(huì)更加形象直觀，能夠更好地表達(dá) OceanBase 的技術(shù)特點(diǎn)，開(kāi)發(fā)者也更容易理解。

架構(gòu)設(shè)計(jì)首先要做的就是可行性分析。做技術(shù)的同學(xué)肯定都很熟悉，架構(gòu)設(shè)計(jì)的核心在于取舍，為什么能夠做到，背后的原理是什么，舍棄了什么。我們?cè)谠O(shè)計(jì)一體化架構(gòu)時(shí)，也做了一個(gè)設(shè)計(jì)假設(shè)，那就是：對(duì)于一個(gè)分布式數(shù)據(jù)庫(kù)，雖然數(shù)據(jù)量很大，但是大部分操作仍然為單機(jī)操作（>80%），少部分操作才是跨機(jī)操作（<20%）。

OceanBase 早期在阿里系內(nèi)部推廣時(shí)，我自己就是內(nèi)部的 BD/SA，我會(huì)主動(dòng)去和每個(gè)業(yè)務(wù)的開(kāi)發(fā)人員交流，最后發(fā)現(xiàn)，雖然阿里系的業(yè)務(wù)很復(fù)雜，有電商，金融，物流，本地生活，文娛，地圖，醫(yī)療健康，但是，所有的互聯(lián)網(wǎng) to C 的在線(xiàn)業(yè)務(wù)基本都能夠按照用戶(hù)號(hào)(user_id)做 sharding 來(lái)實(shí)現(xiàn)分布式。按照 user_id 做完 sharding 之后，絕大部分操作都是單用戶(hù)內(nèi)部的操作，只有非常少數(shù)的跨用戶(hù)操作。

金融行業(yè)也是類(lèi)似的，我們都用過(guò)網(wǎng)銀系統(tǒng)，大部分時(shí)間都是在讀寫(xiě)自己的賬戶(hù)，少部分時(shí)間才是做轉(zhuǎn)賬這樣的跨賬戶(hù)操作。于是，系統(tǒng)的優(yōu)化目標(biāo)就變成：首先確保 80% 的單機(jī)操作沒(méi)有任何分布式相關(guān)的 overhead，這部分操作能夠和單機(jī)數(shù)據(jù)庫(kù)站在同一個(gè)起點(diǎn)上 PK 性能，接下來(lái)才是優(yōu)化另外 20% 跨機(jī)操作的性能，盡可能追求極致。

單機(jī)操作的分布式相關(guān) overhead 主要來(lái)自于兩個(gè)方面：一個(gè)是高可用帶來(lái)的，一個(gè)是可擴(kuò)展性帶來(lái)的。2013 年的時(shí)候當(dāng)時(shí)的支付寶 Oracle DBA 告訴我一個(gè)經(jīng)驗(yàn)數(shù)據(jù)，當(dāng) Oracle 打開(kāi)強(qiáng)同步的時(shí)候，性能降低至少 30% 以上。OceanBase 為了實(shí)現(xiàn)無(wú)損容災(zāi)，底層采用了基于 Paxos 的強(qiáng)同步方案，如果不在架構(gòu)上有所變化，肯定做不到單機(jī)高性能。

我們的做法是把數(shù)據(jù)庫(kù)中的 redo 日志提交給異步化，這樣就避免了數(shù)據(jù)庫(kù)內(nèi)部的工作線(xiàn)程等待日志提交返回結(jié)果，即使網(wǎng)絡(luò)和磁盤(pán)比較差，強(qiáng)同步帶來(lái)的開(kāi)銷(xiāo)也比較小。我們用 sysbench 對(duì) OceanBase 三臺(tái)機(jī)器強(qiáng)同步做了性能評(píng)測(cè)，結(jié)果表明 Paxos 強(qiáng)同步對(duì)于 OceanBase 的性能損失只有 8% 左右。這個(gè)損失是完全可以接受的，可以通過(guò)其它模塊的優(yōu)化給彌補(bǔ)回來(lái)。可擴(kuò)展性帶來(lái)的性能損耗主要是數(shù)據(jù)分片導(dǎo)致的，每個(gè)數(shù)據(jù)分片都需要寫(xiě)單獨(dú)的redo日志，可以簡(jiǎn)單地把每個(gè)數(shù)據(jù)分片想象成一個(gè) mini 數(shù)據(jù)庫(kù)，分片越多，每臺(tái)機(jī)器上分片管理相關(guān)的分布式 overhead 就越大。

4.0 單機(jī)分布式一體化架構(gòu)的創(chuàng)新就在于動(dòng)態(tài)日志流。每臺(tái)機(jī)器上的每個(gè)租戶(hù)只有一個(gè)日志流，這個(gè)租戶(hù)上的所有數(shù)據(jù)分區(qū)都動(dòng)態(tài)綁定在該日志流之上，從而避免了大量日志流導(dǎo)致的 overhead。另外，分區(qū)到日志流是動(dòng)態(tài)綁定的，當(dāng)系統(tǒng)增加新的服務(wù)器時(shí)，可以把分區(qū)從源端的日志流動(dòng)態(tài)解綁并重新綁定到目的端的日志流，從而實(shí)現(xiàn)分區(qū)動(dòng)態(tài)遷移。

很多人可能會(huì)想，數(shù)據(jù)庫(kù)發(fā)展了這么多年，為什么 OceanBase 想到了這么做，其他人都沒(méi)有想到？這里面其實(shí)也沒(méi)有什么魔法，我認(rèn)為關(guān)鍵點(diǎn)在于全球分布式數(shù)據(jù)庫(kù)很少有像 OceanBase，必須扛住支付寶雙十一這樣的極限業(yè)務(wù)場(chǎng)景，并且多年被業(yè)務(wù)方”既要也要還要”給逼出來(lái)的。

業(yè)界對(duì)于可擴(kuò)展性也有不同的做法：經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)干脆就不支持可擴(kuò)展，想要分布式的時(shí)候讓?xiě)?yīng)用做改造；NewSQL 系統(tǒng)的思路是把可擴(kuò)展性下沉到存儲(chǔ)層，將系統(tǒng)劃分為 SQL 層和存儲(chǔ)層，SQL 層做功能，存儲(chǔ)層做可擴(kuò)展性，這種實(shí)現(xiàn)方式更加簡(jiǎn)單，但會(huì)帶來(lái)一個(gè)問(wèn)題，那就是每個(gè) SQL 請(qǐng)求都需要一次額外的遠(yuǎn)程訪(fǎng)問(wèn)，即使是訪(fǎng)問(wèn)自己賬戶(hù)也是一樣；OceanBase 的做法是先實(shí)現(xiàn)全分布式架構(gòu) 1.x/2.x/3.x，再逐步演進(jìn)到單機(jī)分布式一體化架構(gòu) 4.x。

單機(jī)分布式一體化架構(gòu)看起來(lái)什么都行，既能做單機(jī)，又能分布式，現(xiàn)階段的側(cè)重點(diǎn)到底是什么？我認(rèn)為一方面，單機(jī)分布式一體化架構(gòu)是一種技術(shù)的升維，對(duì)于用戶(hù)和開(kāi)發(fā)者比之前更加友好，會(huì)逐步成為主流選擇。另一方面，新技術(shù)肯定有一段成熟期，尤其是用戶(hù)體驗(yàn)和生態(tài)一開(kāi)始不如單機(jī)數(shù)據(jù)庫(kù)，需要一段時(shí)間來(lái)打磨。短期來(lái)看，單機(jī)分布式一體化架構(gòu)對(duì)于開(kāi)發(fā)者的價(jià)值在于如下幾個(gè)方面：

第一，極大地降低分布式數(shù)據(jù)庫(kù)的門(mén)檻。原先的 NewSQL 單機(jī)性能太差，業(yè)界主流的 NewSQL 系統(tǒng)，比如 CockroachDB 和 YugabyteDB 的單機(jī) sysbench 性能只有 MySQL 的 1/5 ~ 1/10。隨著單機(jī)分布式一體化數(shù)據(jù)庫(kù)逐步成熟，這類(lèi) NewSQL 會(huì)被逐步取代，我也確實(shí)看到很多用戶(hù)把原先使用的 NewSQL 系統(tǒng)換成? OceanBase 來(lái)實(shí)現(xiàn)降本增效。

第二，解決用戶(hù)從小到大擴(kuò)展的需求。我在和很多中小企業(yè)溝通的過(guò)程中發(fā)現(xiàn)，大多數(shù)中小企業(yè)都是很有追求的，雖然目前階段他們的數(shù)據(jù)量不大，單機(jī)數(shù)據(jù)庫(kù)也能支撐，但是他們也對(duì)未來(lái)幾年的業(yè)務(wù)發(fā)展充滿(mǎn)期待，不希望等到業(yè)務(wù)發(fā)展之后再修改應(yīng)用更換數(shù)據(jù)庫(kù)，他們?cè)敢庖婚_(kāi)始就選擇單機(jī)分布式一體化數(shù)據(jù)庫(kù)。

單機(jī)分布式一體化數(shù)據(jù)庫(kù)最終會(huì)不會(huì)取代單機(jī)數(shù)據(jù)庫(kù)？我認(rèn)為從技術(shù)趨勢(shì)上來(lái)看會(huì)逐步替代，但是整個(gè)過(guò)程比較長(zhǎng)，需要很長(zhǎng)一段時(shí)間。

單機(jī)分布式一體化架構(gòu)的核心技術(shù)是動(dòng)態(tài)日志流。為了真正實(shí)現(xiàn)一體化，需要解決如下幾個(gè)關(guān)鍵的技術(shù)問(wèn)題：

• 應(yīng)用透明：從單機(jī)到多機(jī)不需要應(yīng)用做改造，需要客戶(hù)端支持動(dòng)態(tài)路由技術(shù)，當(dāng)后端數(shù)據(jù)庫(kù)發(fā)生分區(qū)遷移時(shí)，能夠動(dòng)態(tài)路由到目的服務(wù)器上。另外，不管是單機(jī)還是分布式，需要支持全部的 SQL 功能。

• 單機(jī)操作：單機(jī)只有一個(gè) redo 日志，單機(jī)事務(wù)寫(xiě) redo 日志的方式與經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)比較像。OceanBase 還做了一項(xiàng)技術(shù)創(chuàng)新，經(jīng)典的單機(jī)數(shù)據(jù)庫(kù)采用的是B+樹(shù)存儲(chǔ)引擎，OceanBase 的做法是將 B+ 樹(shù)數(shù)據(jù)分塊的思路融入到 LSM 樹(shù)存儲(chǔ)引擎，一方面能夠像 LSM 樹(shù)一樣具備高壓縮能力，并把熱點(diǎn)數(shù)據(jù)放在內(nèi)存中提供服務(wù)，另一方面通過(guò)類(lèi)似 B+ 樹(shù)的數(shù)據(jù)分塊思路來(lái)減少 LSM 樹(shù)的寫(xiě)入放大。最終使得 OceanBase 4.1 即使在三臺(tái)機(jī)器做強(qiáng)同步的情況之下無(wú)論是單機(jī)的性能還是存儲(chǔ)成本都好于 MySQL 8.0。?

• 跨機(jī)操作：跨機(jī)操作通過(guò)底層的分布式架構(gòu)提供，上層的 SQL 功能不受影響。如果事務(wù)只涉及一臺(tái)機(jī)器，走單機(jī)事務(wù)；如果涉及多臺(tái)機(jī)器，通過(guò)兩階段提交實(shí)現(xiàn)分布式事務(wù)。另外，通過(guò)分布式、并行、異步化等技術(shù)手段盡可能地優(yōu)化性能。

• 遷移代價(jià)：遷移操作后臺(tái)進(jìn)行，實(shí)際運(yùn)行時(shí)一般會(huì)對(duì)遷移限速。假設(shè)遷移最大限速 200MB/s，占用萬(wàn)兆網(wǎng)卡 20% 左右的帶寬，遷移操作只是拷貝數(shù)據(jù)，CPU 占用比較少，只要不是在雙十一零點(diǎn)這樣的極端場(chǎng)景，后臺(tái)遷移都不會(huì)影響前臺(tái)的在線(xiàn)交易請(qǐng)求。假設(shè)數(shù)據(jù)量為 1TB，遷移時(shí)間為 1TB / 200MB/s = 5000s，大約 1 個(gè)半小時(shí)。

今年 3 月份我們?cè)陂_(kāi)發(fā)者大會(huì)分享了 OceanBase 的性能數(shù)據(jù)，過(guò)去也在 TPC-C 測(cè)試展示了 OceanBase 的擴(kuò)展能力：

• 單機(jī)性能：32C 場(chǎng)景，OceanBase 4.1 在 sysbench 所有場(chǎng)景(point select/read only/write only/read write/insert/update)都好于 MySQL 8.0，在最為綜合的 readwrite 場(chǎng)景 OceanBase 4.1 比 MySQL 8.0 高 39%。

• 公有云性?xún)r(jià)比：采用 4C16G CPU，MySQL 部署主備兩臺(tái)機(jī)器，OceanBase 部署三臺(tái)機(jī)器，兩臺(tái)為全功能副本，一臺(tái)為日志副本。無(wú)論存儲(chǔ)多大，從 100GB，300GB，500GB 到 1TB，OceanBase 4.1 在阿里云和 AWS 的性?xún)r(jià)比都好于MySQL 8.0，且存儲(chǔ)容量越大，OceanBase的優(yōu)勢(shì)越明顯。整體上看，同樣的性能，相比云上的 MySQL，OceanBase可以幫助用戶(hù)節(jié)省 18.57% 到 42.05% 整體擁有成本，且 OceanBase 還有更好的三副本無(wú)損容災(zāi)能力。

• TPC-C 擴(kuò)展性：OceanBase 參加過(guò)兩次 TPC-C 測(cè)試，最后一次測(cè)試中采用了超過(guò) 1500 臺(tái)機(jī)器，TPC-C 的 workload 里面有 10%~15% 分布式事務(wù)，本地事務(wù) 85%-90%，與真實(shí)場(chǎng)景比較接近。通過(guò) TPC-C 官網(wǎng)公布的報(bào)告可以看到，OceanBase 的性能基本能夠做到隨著服務(wù)器的增加而線(xiàn)性增長(zhǎng)。

當(dāng)然，單機(jī)分布式一體化架構(gòu)也不是完美的，有一些問(wèn)題仍然值得探討，也希望未來(lái)和開(kāi)發(fā)者用戶(hù)做更深入的探討：

一、分布式到單機(jī) vs 單機(jī)到分布式

到底是選擇分布式到單機(jī)（先做分布式再做單機(jī)），還是單機(jī)到分布式（先做單機(jī)再做分布式）的技術(shù)路線(xiàn)？我認(rèn)為只有分布式到單機(jī)才是可行的。因?yàn)榉植际降募夹g(shù)難度比單機(jī)要高一個(gè)數(shù)量級(jí)，再加上單機(jī)的場(chǎng)景是主流場(chǎng)景。從 ROI 的角度看，不太可能出現(xiàn)一個(gè)主流場(chǎng)景的單機(jī)數(shù)據(jù)庫(kù)，在已經(jīng)有大量技術(shù)債的前提之下，舍棄部分主流場(chǎng)景的支持，花費(fèi)更高一個(gè)量級(jí)的代價(jià)去支持一個(gè)規(guī)模更小的高端場(chǎng)景。這也是為什么所有的商業(yè)案例中，只有先做高端，再做低端的降維做法才能成功。

技術(shù)創(chuàng)新也往往在外部才會(huì)發(fā)生，比如電動(dòng)車(chē)領(lǐng)域的 Tesla，分布式技術(shù)有點(diǎn)像電動(dòng)車(chē)的電池，并不是燃油汽車(chē)廠商在內(nèi)部實(shí)現(xiàn)了電動(dòng)化的變革，而是一個(gè)外部的 Tesla 先做好高端的 Model X/Model S，再逐步通過(guò)大眾車(chē) Model 3 去占領(lǐng)主流市場(chǎng)。

二、全分布式場(chǎng)景

單機(jī)分布式一體化架構(gòu)有一個(gè)假設(shè)，那就是：在分布式數(shù)據(jù)庫(kù)中，大部分請(qǐng)求仍然是單機(jī)讀寫(xiě)，少部分請(qǐng)求才是跨機(jī)讀寫(xiě)。如果這個(gè)假設(shè)不成立，也就是大部分請(qǐng)求都是跨機(jī)讀寫(xiě)，那么，分布式數(shù)據(jù)庫(kù)性能的擴(kuò)展比會(huì)大幅下降。怎么看待這個(gè)問(wèn)題？我認(rèn)為可以進(jìn)一步把全分布式的場(chǎng)景分為兩類(lèi)：一類(lèi)是 OLAP 場(chǎng)景，OLAP 場(chǎng)景單個(gè)用戶(hù)的數(shù)據(jù)量都很大，且維度會(huì)比較復(fù)雜，這個(gè)場(chǎng)景確實(shí)很難做到本地化。

但是，這個(gè)場(chǎng)景的并發(fā)量很小，優(yōu)化的關(guān)鍵點(diǎn)在于盡可能地把所有機(jī)器的資源通過(guò)并行化、向量化等手段盡可能地利用起來(lái)。每次運(yùn)行的 SQL 都比較大，一次額外的網(wǎng)絡(luò)請(qǐng)求開(kāi)銷(xiāo)在整個(gè) SQL 語(yǔ)句執(zhí)行過(guò)程中占比很少。另外一類(lèi)是 OLTP 場(chǎng)景，假設(shè)某個(gè) OLTP 業(yè)務(wù)全部都是跨用戶(hù)轉(zhuǎn)賬操作，那么，如果數(shù)據(jù)量比較小，單機(jī)分布式一體化架構(gòu)可以只部署單機(jī)，沒(méi)有額外的分布式開(kāi)銷(xiāo)；如果數(shù)據(jù)量比較大，必須采用多機(jī)部署，那么，性能的擴(kuò)展比雖然會(huì)大幅下降，但是，這是業(yè)務(wù)無(wú)法避免的，這種場(chǎng)景下單機(jī)分布式一體化數(shù)據(jù)庫(kù)相比其它的 shared nothing 數(shù)據(jù)庫(kù)在架構(gòu)上也沒(méi)有劣勢(shì)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-687701.html

到了這里，關(guān)于談?wù)剬?duì)OceanBase單機(jī)分布式一體化的思考的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！