我有很多客户拥有自己的域名服务器，我想为他们提供所有相同的 DNS 详细信息，例如 Squarespace 或 Shopify 的做法（例如，始终相同的@A 记录和www.CNAME），然后管理他们的流量路由到哪个服务器在我这边。
当我需要将大量网站迁移到新的基础架构上时，这将大有帮助，我不想花数周时间与不同公司的不同 IT 部门交谈，要求他们更新其域的 DNS 设置及其所有管理。
是否有可用于此目的的负载平衡器或代理？我很想知道什么被认为是最佳实践。你会推荐什么？
AskOverflow.Dev
我猜你指的是这个shopify DNS 设置。
根域 (
@)如您所知，您不能在根 (
@) 域上拥有 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.comhttps://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/任播并非易事。）
缺点：
在一定规模上绝对有意义，或者如果您已经具备管理它的技能和工具。
选项 3 - 非标准 DNS
一些托管 DNS 提供商添加
CNAME了对裸/根域的类似支持。如果您使用这些提供程序之一，或者如果您运行自己的 DNS 则自己实施......那么这可以解决问题。
看到这个答案
如果您依赖于此，那么您将被供应商锁定为支持此非标准功能的 DNS 提供商。或者您需要运行自己的 DNS 并自己实现。
选项 4 - CDN
根据您的应用程序，您可以在其前面放置另一个服务。即类似 CDN 的服务（stackpath、cloudflare、aws-cloudfront 等）。这些人将处理 DNS/任播和相关主题，您可以让您的客户指向 CDN 服务并在 CDN 后面运行您的服务。
更改后端服务成为 CDN（或类似）的配置更改，以告诉 CDN 应从其请求内容的端点的名称/IP。
缺点：
我会做什么
没有关于您的客户群规模、技能（例如 BGP）的更多详细信息，无论您是运行自己的硬件还是租用廉价的 VPS...
我喜欢简单，你以后可以把它变得更复杂。什么是最简单的事情可以降低我的成本，不需要很多时间，为我的客户提供良好的用户体验，并最终让我回到创收活动中（而不是花时间在技术后端上）有时间/财务成本，希望大规模降低总体成本）。我不是谷歌，所以我宁愿增加我的收入而不是微优化我的底线......特别是如果没有技术需求（还）。
我会做以下...
A和AAAA记录。您的其余服务不必托管在同一个地方（即，如果您需要扩展重定向，重定向器可以是带有 ELB 的 AWS，并且客户盒子可以在便宜的 VPS 上）。CUS1234.example.com如果您让客户能够轻松更改他们托管的域，则更有意义）。客户只需设置一次 DNS，无需更改，除非他们想更改托管域。
如果您有良好的备份/恢复/复制机制，与服务器/vps/app 供应层上的某种形式的服务发现协同工作，那么基础架构迁移相对容易。
CUST1234.example.com A 10.0.0.1在迁移前的某个时间，在您的 DNS 记录（即客户的 CNAME 指向的名称）上设置较低的 DNS TTL 。A,AAAA) 以指向新 IP如果您的数据后端无法同时处理来自 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 获得负载……但总比没有好。
@mattpr 给出的答案非常详细，非常周到。它有很多非常准确的有用信息。我不想从那个答案中拿走，它是多么神奇。
我的方法会简单得多。我会在[insert cloud vendor of choice]中设置一个代理主机，并使用 nginx 代理管理器（https://nginxproxymanager.com/）之类的东西。它允许代理和重定向到其他 URL。在 Docker 容器中设置很容易。它支持缓存、websockets 和 Let's Encrypt。
让您的客户将他们的 @ 指向您的主机 IP，然后为他们创建一条 A 记录，以将其 www CNAME 指向 (hosting.myawesomecompany.com)。然后为该客户设置代理配置，以将请求指向正确的服务器/基础设施。
确保 nginx 代理管理器保持更新，并保持 webui 对 IP ACL 或其他东西的安全。