頁(yè)面規(guī)則的未來(lái)

頁(yè)面規(guī)則是我們最常用的產(chǎn)品之一。它被數(shù)百萬(wàn)用戶(hù)采用，用于配置從緩存到安全級(jí)別的所有內(nèi)容。它是Cloudflare的“If This Then That”邏輯。其中“If…”是一個(gè)URL，而“Then That”則將我們處理流量的方式更改為“區(qū)域”的特定部分。但這并非沒(méi)有局限性。

頁(yè)面規(guī)則只能在URL或URL模式上觸發(fā)。每個(gè)區(qū)域最多有125個(gè)頁(yè)面規(guī)則。頁(yè)面規(guī)則也很難調(diào)試。甚至“頁(yè)面”的概念現(xiàn)在聽(tīng)起來(lái)也比較過(guò)時(shí)。

我們將用四種新的專(zhuān)用產(chǎn)品替換頁(yè)面規(guī)則，從而提供更多的規(guī)則配額、更多的功能和更細(xì)的粒度。這些產(chǎn)品可立即用于測(cè)試。頁(yè)面規(guī)則并未下架，但我們預(yù)計(jì)能夠很快正式開(kāi)始報(bào)廢流程。

為什么要更改？

自推出以來(lái)的10年里，頁(yè)面規(guī)則已成為一款成熟的產(chǎn)品，并且被廣泛采用。僅在過(guò)去三個(gè)月中就部署了100萬(wàn)個(gè)頁(yè)面規(guī)則。

頁(yè)面規(guī)則用于調(diào)整文件應(yīng)緩存多長(zhǎng)時(shí)間，用于覆蓋某些URL的區(qū)域范圍設(shè)置，用于創(chuàng)建簡(jiǎn)單的URL重定向，用于選擇性地添加/刪除HTTP標(biāo)頭。頁(yè)面規(guī)則就是如同多刀工具一樣的產(chǎn)品。

Photo by Andrey Matveev on Unsplash

與多刀工具和其他通用產(chǎn)品一樣，頁(yè)面規(guī)則在許多方面都做得很好，但在任何方面都不是同類(lèi)產(chǎn)品中的佼佼者。這是普遍性的權(quán)衡。隨著我們公司不斷成長(zhǎng)，我們的客戶(hù)會(huì)理所當(dāng)然地提出更多要求。僅過(guò)濾URL已經(jīng)不夠了；用戶(hù)要求更多，而如今，我們也正在交付更多。

在過(guò)去的兩年里，我們一直致力于頁(yè)面規(guī)則的未來(lái)，并將數(shù)百條反饋提煉成共同的主題，例如：

1.我需要超過(guò)125個(gè)頁(yè)面規(guī)則

2.我需要能夠在URL以外的地方觸發(fā)頁(yè)面規(guī)則

3.我需要能夠在我的頁(yè)面規(guī)則中使用正則表達(dá)式

4.我很難理解不同的頁(yè)面規(guī)則之間是如何相互影響的

5.頁(yè)面規(guī)則難以調(diào)試

6.我想在頁(yè)面規(guī)則中執(zhí)行更多操作

分析這些主題后，我們得出結(jié)論，對(duì)頁(yè)面規(guī)則而言，最好的辦法是拆解它并創(chuàng)建新的離散產(chǎn)品，每個(gè)產(chǎn)品都可能是其相關(guān)領(lǐng)域的同類(lèi)產(chǎn)品中的佼佼者。這種拆解還將提供有關(guān)互操作的更優(yōu)清晰度（緩存vs配置vs...），并使調(diào)試更簡(jiǎn)單。

今天，我們宣布推出這些新產(chǎn)品：

1.Cache Rules：用于設(shè)置和調(diào)整“所有緩存”的專(zhuān)用產(chǎn)品。

2.Configuration Rules：用于設(shè)置及選擇性地啟用、禁用和覆蓋區(qū)域范圍設(shè)置的專(zhuān)用產(chǎn)品。

3.Dynamic Redirects：與“轉(zhuǎn)發(fā)URL”類(lèi)似，但最高為11。根據(jù)訪問(wèn)者的所在國(guó)家/地區(qū)、首選語(yǔ)言、設(shè)備類(lèi)型或者使用正則表達(dá)式（取決于方案級(jí)別）等進(jìn)行重定向。

4.Origin Rules：針對(duì)“該流量從Cloudflare離開(kāi)后去往哪里”的專(zhuān)用產(chǎn)品。我們不僅在這種新產(chǎn)品中添加了主機(jī)標(biāo)頭和解析覆蓋（僅限ENT），還通過(guò)使客戶(hù)能夠選擇性地覆蓋目標(biāo)端口，利用另一個(gè)常見(jiàn)的Workers用例創(chuàng)建產(chǎn)品。此外，我們還添加了覆蓋服務(wù)器名稱(chēng)指示（SNI）的功能。

所有這四種產(chǎn)品現(xiàn)在都可以通過(guò)儀表板、API和Terraform使用，并將與Transform Rules一起成為取代頁(yè)面規(guī)則的產(chǎn)品套件，最終實(shí)現(xiàn)發(fā)布頁(yè)面規(guī)則壽命終止公告。

對(duì)于這些產(chǎn)品發(fā)布，每一個(gè)都有專(zhuān)門(mén)的博客，其中詳細(xì)介紹了它們提供的功能和解決的問(wèn)題。

執(zhí)行順序

這個(gè)新產(chǎn)品套件的主要優(yōu)勢(shì)之一是清晰。

頁(yè)面規(guī)則是一個(gè)黑匣子，流量進(jìn)入，“事情發(fā)生”，流量出來(lái)。很難調(diào)試緩存、配置、標(biāo)頭修改等之間的相互作用，并且它可能因區(qū)域而異，因?yàn)樗耆怯脩?hù)定義的。

其每個(gè)“功能”具有離散、獨(dú)立的區(qū)域，從而更輕松地可視化HTTP請(qǐng)求的流程：

現(xiàn)在不再是單個(gè)頁(yè)面規(guī)則，我們可以看到，Origin Rules將最先運(yùn)行，然后是Cache Rules，然后是Configuration Rules，最后是Dynamic Redirects。這意味著我們將先修改主機(jī)標(biāo)頭，然后再調(diào)整緩存設(shè)置。我們將會(huì)先調(diào)整緩存參數(shù)，然后再修改為特定流量啟用哪些設(shè)置。

我們已將這些新產(chǎn)品集成到流量序列儀表板元素中。

（對(duì)于同時(shí)使用頁(yè)面規(guī)則和這套新產(chǎn)品的區(qū)域：新產(chǎn)品將優(yōu)先于頁(yè)面規(guī)則。這意味著如果發(fā)生沖突，頁(yè)面規(guī)則將被覆蓋）。

我需要超過(guò)125個(gè)頁(yè)面規(guī)則

頁(yè)面規(guī)則的限制之一是如何在我們的后端架構(gòu)上存儲(chǔ)和執(zhí)行每個(gè)頁(yè)面規(guī)則。我們最多只能為每個(gè)區(qū)域提供125個(gè)頁(yè)面規(guī)則，超過(guò)此數(shù)字，就會(huì)出現(xiàn)性能下降—HTTP請(qǐng)求的延遲時(shí)間開(kāi)始增加，因?yàn)樵u(píng)估它們與頁(yè)面規(guī)則需要的時(shí)間越來(lái)越長(zhǎng)。為了克服這一限制，用戶(hù)將簡(jiǎn)單的工作負(fù)載轉(zhuǎn)移到了Workers，或者將區(qū)域分成多個(gè)子域，每個(gè)子域都有125個(gè)頁(yè)面規(guī)則配額。這些都不是客戶(hù)的理想選擇。

為了克服這一限制，我們將所有替代產(chǎn)品構(gòu)建在閃電般快速的規(guī)則集引擎上，該引擎還運(yùn)行Transform Rules、Custom Rules（WAF）、Bulk Redirects和API Shield等產(chǎn)品。

這使我們能夠?yàn)榭蛻?hù)提供更多的配額，因?yàn)樵撘娴臉?gòu)建規(guī)模遠(yuǎn)遠(yuǎn)超過(guò)每種產(chǎn)品125個(gè)規(guī)則。下表總結(jié)了這些新產(chǎn)品的前后影響，顯示了每個(gè)計(jì)劃的默認(rèn)規(guī)則配額：

無(wú)法為這些新產(chǎn)品購(gòu)買(mǎi)額外的規(guī)則。

這意味著Enterprise計(jì)劃中的區(qū)域現(xiàn)在至少有500條規(guī)則可以使用，而之前它們通過(guò)頁(yè)面規(guī)則擁有125條規(guī)則。對(duì)于企業(yè)來(lái)說(shuō)，新產(chǎn)品的配額是可以協(xié)商的。Pro計(jì)劃區(qū)域從20個(gè)頁(yè)面規(guī)則變?yōu)?00個(gè)。結(jié)合規(guī)則集引擎提供的精細(xì)控制，這些更改讓客戶(hù)能夠以最細(xì)微的差別自定義其區(qū)域的流量。

在規(guī)則集引擎上構(gòu)建所有這些產(chǎn)品的另一個(gè)好處是可擴(kuò)展性。目前有超過(guò)30種產(chǎn)品在規(guī)則集引擎上構(gòu)建和運(yùn)行。上述每一種產(chǎn)品本質(zhì)上都是一個(gè)稱(chēng)為“階段”的邏輯桶，其中包含一個(gè)針對(duì)該產(chǎn)品的規(guī)則集。每個(gè)階段都僅限于特定的操作和字段，例如字段cf.bot_management.score在http_request_transform中不可用，因?yàn)槲覀冊(cè)趫?zhí)行URL重寫(xiě)時(shí)還沒(méi)有計(jì)算機(jī)器人分?jǐn)?shù)。此外，僅允許執(zhí)行重寫(xiě)操作。而在Origin Rules（http_request_origin）中，我們只允許操作route

當(dāng)我們?yōu)闃?gòu)建在規(guī)則集引擎之上的產(chǎn)品創(chuàng)建新功能時(shí)，我們很容易在以后將該新功能擴(kuò)展到其他產(chǎn)品。

例如，我們?cè)诮衲暝缧r(shí)候向Transform Rules添加了一個(gè)新的“字段”http.request.accepted_languages。此前這僅在Transform Rules中可用。但是，由于兩種產(chǎn)品都在規(guī)則集引擎上構(gòu)建，因此可以輕松為Dynamic Redirects啟用此功能。這將允許客戶(hù)根據(jù)訪問(wèn)者的語(yǔ)言偏好執(zhí)行URL重定向，從工程角度來(lái)看，我們的成本可以忽略不計(jì)，因?yàn)樵撟侄我呀?jīng)實(shí)現(xiàn)。

這也意味著，在將來(lái)，如果根據(jù)客戶(hù)請(qǐng)求為Cache Rules創(chuàng)建了一個(gè)新字段，例如http.request.super_cool_field，只需點(diǎn)擊一下，我們就可以為其他30種產(chǎn)品中的任何一種啟用此字段，而不必跨多個(gè)平臺(tái)重復(fù)工作。

簡(jiǎn)而言之，我們?cè)谝?guī)則集引擎之上構(gòu)建的產(chǎn)品越多，我們移動(dòng)的速度就越快，也就可以將更多的功能交到用戶(hù)手中。

單一用戶(hù)體驗(yàn)

最重要的好處是一致性。上述每一種產(chǎn)品都有一個(gè)一致且可預(yù)測(cè)的API。一致且可預(yù)測(cè)的Terraform配置，以及儀表板中一致且可預(yù)測(cè)的用戶(hù)體驗(yàn)。規(guī)則集引擎允許我們保持一切不變，除了“操作”。過(guò)濾保持不變，API保持不變，UI（大部分）保持不變，唯一的變化是“…then”，即規(guī)則的操作部分。

這可以確保一點(diǎn)，作為用戶(hù)，當(dāng)您在儀表板周?chē)鷨螕粼O(shè)置新區(qū)域時(shí)，您不必了解每個(gè)單獨(dú)的產(chǎn)品頁(yè)面以及如何導(dǎo)航它。您需要學(xué)習(xí)的唯一部分是該產(chǎn)品的獨(dú)特之處及其操作：

最后，當(dāng)我們添加新產(chǎn)品時(shí)，可以輕松擴(kuò)展Terraform提供程序以支持它。在這個(gè)項(xiàng)目中，這種一致的體驗(yàn)一直是我們的目標(biāo)，并將在未來(lái)繼續(xù)存在。

馬上試試吧

我們正在用一套新的產(chǎn)品取代頁(yè)面規(guī)則，每個(gè)產(chǎn)品都是同類(lèi)產(chǎn)品中的佼佼者，并將更多的能力交到我們用戶(hù)的手中。在每篇專(zhuān)門(mén)博客中閱讀有關(guān)新產(chǎn)品的更多信息。然后，親自嘗試一下吧！