負載均衡器或代理根據 URL 將流量路由到不同的伺服器
我有很多客戶擁有自己的域名伺服器，我想為他們提供所有相同的 DNS 詳細資訊，例如 Squarespace 或 Shopify 的做法（例如，始終相同的
@A 記錄和www.CNAME），然後管理他們的流量路由到哪個伺服器在我這邊。當我需要將大量網站遷移到新的基礎架構上時，這將大有幫助，我不想花數週時間與不同公司的不同 IT 部門交談，要求他們更新其域的 DNS 設置及其所有管理。
是否有可用於此目的的負載平衡器或代理？我很想知道什麼被認為是最佳實踐。你會推薦什麼？
我猜你指的是這個shopify DNS 設置。
將
A記錄指向 Shopify IP 地址23.227.38.65。CNAME將帶有名稱的記錄www指向shops.myshopify.com根域 (
@)如您所知，您不能在根 (
@) 域上擁有 CNAME，因此需要使用指向固定 IP 地址的 aA和記錄來處理根域。AAAA大公司在全球範圍內擴展的方式是使用“任播”，其中相同的 IP 地址通過 BGP 從多個不同的數據中心公佈。
您可以將任播視為由路由器處理的負載平衡，其中相同或不同數據中心中的多個伺服器可以接收和處理單個 IP 地址的流量。
如果您還不是擁有自己 IP 空間的 AS，那麼任播絕對超出您的範圍。
從這裡開始的簡單方法是不在根域上執行任何主機，而只是重定向到
www. 然後單個 nginx 重定向器框（或在 level4/tcp 負載平衡器後面的許多）可以處理大量的域重定向。如果由於大量請求而需要大量盒子，請對重定向器伺服器使用 tcp/layer4 負載平衡，以便您可以在負載均衡器後面的盒子上執行應用程序 (http) 和 ssl 終止，以獲得更高的可擴展性（單個負載均衡器可以處理更多流量）。
使用永久重定向（301）無限期地記憶體減少來自相同客戶端的重複流量。
最佳實踐在這裡。設置 DNS 後，使用letsencrypt/certbot 自動生成/更新重定向器域。 在重定向到另一個域 ( ) 之前，始終重定向到同一域上的 https (例如)。
http://example.com --> https://example.com``https://www.example.com全球資訊網
查看 shopify 的
shops.myshopify.com（wwwCNAME應該指向的位置），您可以看到它有一條A記錄，目前為23.227.38.74.使用全域 ping 工具，您可以看到這個 IP 從世界各地的許多地方都有幾毫秒的延遲。這意味著它肯定不是單個位置的單個伺服器（跨大西洋延遲通常在最好的情況下執行 60 毫秒……所以當你看到來自美國和歐盟的 4 毫秒 ping 相同 IP 時……你知道那些 ping 不是’ t去同一台伺服器）。您還可以通過從不同地理位置的不同伺服器執行到相同 IP 的跟踪路由來驗證這一點。
在響應該 IP 的每個端點上，他們可能有一個負載平衡器將請求路由到不同的硬體。
所以shopify CNAME背後，是單IP任播。為您的客戶提供 CNAME 的好處是您可以自由更改該名稱背後的 IP，而您的客戶無需更新 DNS。在那一點上…當您為客戶提供
A根 (@) 域重定向器的記錄時…您要確保這是一個 IP 地址，如果您遇到問題時可以控制並重新分配給不同的硬體伺服器/負載均衡器（例如 AWS 彈性 IP 類型的東西或如果您是 AS，則您自己的 IP 空間）。據我所知，當您的電腦在解析名稱時遵循 CNAME 鏈以告訴最終 DNS 伺服器原始域是什麼時，DNS 請求（以及 DNS 解析器記憶體的一部分）沒有給出任何“提示”你要求的。如果有，那麼您可以想像一個 DNS 伺服器具有條件規則，根據其背後的名稱返回相同名稱的不同 IP 地址。
因此，如果您不打算使用 shopify 方式（bgp/anycast）。最直接的做法是為您的客戶提供獨特的 CNAME。通過這種方式，您可以在 DNS 級別進行負載平衡（為每個唯一的客戶 CNAME 返回不同的 IP）。
您可以遵循一些約定，例如
customerdomain.tld.example.com根據您的客戶資產數據庫自動配置 DNS。對於根域 (
@)，您仍然可以使用單個重定向器 IP（單個 IP/負載平衡器後面的一個或多個框）管理所有域到www.customerdomain.tld的重定向，其中 CNAME 到customerdomain.tld.example.com.更新……也許我錯過了你的問題的重點。
當我需要將大量網站遷移到新的基礎架構上時，這將有很大幫助
正如我上面提到的，至少對於根/
@案例，您需要控制該 IP 並能夠將其分配給其他基礎設施……否則當該 IP 由於遷移而發生更改時，您的所有客戶都必須更新他們的 DNS。對於 www/ 的
CNAME情況，這不是問題，因為您只需在自己的 DNS 上更新 CNAME 後面的 IP。因此，我將只關注根域 (
@) 情況的選項，因為這是最成問題的（需要客戶在其服務的 IP 地址更改時更新 DNS）。選項…選項 0 - 不支持
@客戶的根/域無論您託管什麼，都將其託管在子域（
www或其他）上。如果客戶想要重定向，他們可以與他們的 IT 人員一起管理。這完全消除了客戶 DNS 指向固定 IP 地址的問題。您可以更新您的 CNAME(s) IP 地址，任何基礎設施移動或 IP 更改都變得簡單。
選項 1 - 可分配的 IP 地址
您可以使用可分配 IP 地址之類的東西（AWS 彈性 ip 類型的東西，最重要的 VPS 提供商提供類似的東西）。
這允許您部署新伺服器（在該提供商處），然後將 IP 切換到新伺服器。
問題是您有供應商/供應商鎖定，因為 IP 地址屬於供應商。因此，如果您想從 AWS 遷移到 Google-Cloud 或您自己的硬體，您不能隨身攜帶這些 IP……為您的客戶更新 DNS。此外，IP 可能是區域鎖定的，因此您無法輕鬆地將 IP 分配給位於不同數據中心的提供商處的另一台伺服器。
選項 2 - 成為 AS 並獲得自己的 IP 空間
如果您正在做認真的託管，那麼如果您的公司在北美和歐洲以外，您需要通過ARIN或RIPE或其他組織成為 AS（自治系統）只是時間問題。
然後，您需要獲取（或租用）您自己的 IP 地址塊。您通常可以免費獲得 ipv6。ipv4 已經用完，但至少 RIPE 可以讓您在一段
/24時間後恢復它們時進入等待列表（256 個地址）。否則，您必須從某人那裡購買地址空間（您可以加入一些市場）。當然，您需要與允許您攜帶自己的 IP 地址的提供商合作。
這裡有幾個實用的連結，它們會介紹任意播設置。但對於初學者來說，忽略任播位並專注於作為 AS 的設置、獲取 IP 空間和尋找合適的基礎設施合作夥伴。（因為執行 BGP/任播並非易事。）
- https://labs.ripe.net/author/samir_jafferali/build-your-own-anycast-network-in-nine-steps/
- https://ripe69.ripe.net/wp-content/uploads/presentations/36-Anycast-on-a-shoe-string-RIPE69.pdf
缺點：
設置和學習的時間投資（例如，如果您的上游提供商沒有為您處理，則為 BGP）。
財務投資（RIPE/ARIN 的會員費/IP 費用以及獲取/租賃 IPv4 塊的潛在巨額成本）。
僅限於與允許您自帶 IP 的 VPS 提供商合作
- 或者您必須租用機架空間並處理對等/路由/交換/BGP/等、硬體故障、SNMP 硬體監控等。
新的干擾，例如需要處理與您的 IP 空間相關的濫用投訴
在一定規模上絕對有意義，或者如果您已經具備管理它的技能和工具。
選項 3 - 非標準 DNS
一些託管 DNS 提供商添加
CNAME了對裸/根域的類似支持。如果您使用這些提供程序之一，或者如果您執行自己的 DNS 則自己實施……那麼這可以解決問題。
如果您依賴於此，那麼您將被供應商鎖定為支持此非標準功能的 DNS 提供商。或者您需要執行自己的 DNS 並自己實現。
選項 4 - CDN
根據您的應用程序，您可以在其前面放置另一個服務。即類似 CDN 的服務（stackpath、cloudflare、aws-cloudfront 等）。這些人將處理 DNS/任播和相關主題，您可以讓您的客戶指向 CDN 服務並在 CDN 後面執行您的服務。
更改後端服務成為 CDN（或類似）的配置更改，以告訴 CDN 應從其請求內容的端點的名稱/IP。
缺點：
- 如果您不需要它，則需要額外費用。
- 需要確保在 CDN 上配置記憶體與非記憶體（例如應用程序）端點以匹配您的應用程序的工作方式。
- 如果您的應用程序無法執行（CDN 是否中斷了請求或您的應用程序是否中斷了請求？），需要調試的附加層。
- 通常這意味著您客戶的 CNAME 記錄將指向 CDN 的域……而不是您的域。您的域在 CDN 應用程序的配置中作為上游伺服器。所以你有供應商鎖定……如果你想切換 CDN，你的所有客戶都需要更新他們的 DNS CNAME 以指向新的。您可以通過放置 2 層 CNAME（客戶 -> 您 -> CDN）來緩解這種情況，但從性能角度來看這並不是很好。
我會做什麼
沒有關於您的客戶群規模、技能（例如 BGP）的更多詳細資訊，無論您是執行自己的硬體還是租用廉價的 VPS…
我喜歡簡單，你以後可以把它變得更複雜。什麼是最簡單的事情可以降低我的成本，不需要很多時間，為我的客戶提供良好的使用者體驗，並最終讓我回到創收活動中（而不是花時間在技術後端上）有時間/財務成本，希望大規模降低總體成本）。我不是Google，所以我寧願增加我的收入而不是微優化我的底線……特別是如果沒有技術需求（還）。
我會做以下…
不支持客戶的裸/根域。想要重定向的客戶可以讓他們的 IT 人員自行設置。少一個嚴重的頭痛。
- 或者，如果您想支持這一點，那麼您設置一個您知道不會失去的重定向器 IP（例如 AWS 彈性 IP）並讓客戶設置
A和AAAA記錄。您的其餘服務不必託管在同一個地方（即，如果您需要擴展重定向，重定向器可以是帶有 ELB 的 AWS，並且客戶盒子可以在便宜的 VPS 上）。每個客戶都會根據他們的託管域或客戶 ID 獲得一個可預測的（對他們來說是唯一的）CNAME（
CUS1234.example.com如果您讓客戶能夠輕鬆更改他們託管的域，則更有意義）。我的 DNS 會根據我的客戶數據庫（客戶域 -> 客戶特定 CNAME -> 託管客戶應用程序的 IP 地址）自動更新。
我可以輕鬆監控該客戶的 DNS，並且我的 DNS 都指向正確的位置。
我可以從客戶端點分別監控每個客戶的 DNS 流量/濫用（因為它們具有唯一的名稱）。
客戶只需設置一次 DNS，無需更改，除非他們想更改託管域。
如果您有良好的備份/恢復/複製機制，與伺服器/vps/app 供應層上的某種形式的服務發現協同工作，那麼基礎架構遷移相對容易。
CUST1234.example.com A 10.0.0.1在遷移前的某個時間，在您的 DNS 記錄（即客戶的 CNAME 指向的名稱）上設置較低的 DNS TTL 。- 啟動新的基礎設施，包括從舊的基礎設施（數據庫、使用者上傳的內容等）複製數據。
- 切換您的客戶 DNS 記錄 (
A,AAAA) 以指向新 IP- 在 DNS TTL + 餘量過去後取下舊的基礎設施。
如果您的數據後端無法同時處理來自 2 個實時客戶端點的寫入，那麼您可能需要中斷遷移……因為舊 DNS 記憶體到期時會有一些重疊。
這種設置的優點是我可以在我想要的幾乎任何有信譽的 VPS 提供商上執行（我的自動配置並不挑剔）。我不需要投資成為 AS 並處理管理我自己的 IP 空間的額外成本（在一定規模上這樣做絕對有意義……但我不知道貴公司的情況） .
我可以做一些事情，比如基於 DNS 的地理負載平衡（根據請求伺服器的區域為同名返回不同的 IP）。這允許您在不同地區為客戶提供多個同名伺服器（因此他們在載入應用程序時不必處理跨美國或跨大西洋的延遲）。您可以為每個客戶提供此服務作為增值/追加銷售。
注意負載均衡…
我多次提到 tcp/layer4 負載均衡，沒有詳細說明。通常，您有兩種常見的負載平衡類型。layer4/transport/tcp 和 layer7/application/http(s)。
layer7/application/http 負載均衡器“說”http 並在將請求（通常是未加密的 http）代理到均衡器/代理後面的多個伺服器之一之前終止 ssl 連接。這很簡單，但可能會導致負載均衡器後面的伺服器不知道在編寫標頭、安全 cookie、重定向等時他們應該假裝在說 https。這也意味著您的負載均衡器必須做更多的工作每個請求（解析 http 並處理 SSL 成本）。這種額外的工作限制了負載均衡器的可擴展性，負載均衡器通常是單個節點/機器/vps。
layer4/tcp 負載均衡器不需要解析 http 請求或有 SSL 終止的成本。它對http一無所知。該請求被路由到處理 ssl 終止和處理 http 請求的多個伺服器之一。
如果您擔心 TLS 會話重用（或缺乏）影響性能，通常使用 redis 或 memcached 作為多個 Web 伺服器之間的共享 TLS 會話記憶體，因此您不必擔心負載均衡器會讓使用者“粘”到負載均衡器後面的特定框。 nginx似乎不支持機外 TLS 會話記憶體（記憶體僅在同一機器上的 nginx 工作人員之間共享）。haproxy似乎有一些東西，但我沒有嘗試過，也不知道它如何在 ssl 終止發生的 nginx 池前面的 haproxy/level4 中工作。
您可以使用 nginx 或 haproxy 作為 layer4/tcp 負載均衡器，兩者的設置都相當簡單。對於更高級的案例（可能還有更好的性能），您還可以查看 Linux 虛擬伺服器 (LVS)。
另一種分配負載的方法是為單個名稱返回多個 A 或 AAAA 記錄。理想情況下，DNS 客戶端會從返回的地址中隨機選擇，這樣您就可以在多個 IP 地址之間獲得某種負載分佈。如果您開始遇到負載均衡器層的擴展問題，這是一種增加更多擴展的低技術方法（只需針對相同或不同的應用程序伺服器池添加另一個負載均衡器）。但是，沒有什麼會迫使客戶端循環您的 IP 地址……所以這並不能讓您更好地控制哪些 IP 獲得負載……但總比沒有好。